Re: [boost] Review request: extended complex number library

Subject: Re: [boost] Review request: extended complex number library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-03-10 11:49:08

Le 09/03/12 17:54, Matthieu Schaller a écrit :
>
>>>> IIUC the standard cover just complex on builtin types, isn't it? 
>>>> See the C99 or C11 standards, annex G.
>>>>> It also comes with a possible implementation.
>>>>>
>>>>>
>>>> I don't which can be the correct implementation for C++ complex on 
>>>> builtin types without using arbitrary precision.
>>>> I have no access to this standard. Please could you add it here?
>>>>
>>> look for instance n1124.pdf which is a C99 draft.
>>>
>>> The aim is not to have full precision but to minimize 
>>> overflows/underflows and to
>>> get good behviour with inf and nan.
>>> For example
>>> 1) (0+0i)*(inf+0i) must return nan+0i, not nan+nani
>>> 2) if modulus(a)² overflow this must not necesseraly implies
>>> that 1/a which is mathematically conj(a)/modulus(a)² underflows
>>>
>>
>> Thanks. I see now what you mean. I agree, correctness is important.
>>
>
> The question is thus do we (you) rather want a library that reproduces 
> the std::complex (i.e. the gcc and icc ones at least) class both in 
> terms of performance and accuracy or do we want a library that is more 
> accurate when de-normalized numbers are involved but that would be 
> slower than the standard one ?
>
> I am not sure people would easily give up the speed of the standard 
> one just to be able to handle numbers that should anyway never enter 
> everyday calculations. What is your opinion ?
>
You can always provide two variants of the arithmetic operations: one 
working with finite numbers (not inf or nan) that is fast and the other 
that allows inf or nan as operands that is slower. The question is which 
variant is chosen for the C++ arithmetic operators?  I suspect that the 
default choice must follow the standard.

An alternative is to have a specific type for finite numbers (which 
ensures that the the value is not nan nor inf). The library could 
specialize the behavior of the needed operations for this specific type.

The main problem of course is readability

z = x + y;

becomes

z = finite(x) + finite(y);

The user is saying here that she know the variables x and y contains a 
finite number, so that the + implementation can take care of this 
information. I don't like it too much, but it allows the user to get the 
best performance when she knows the possible contents.

Just my 2cts,
Vicente