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

Subject: Re: [boost] Review request: extended complex number library
From: jtl (jtlapreste_at_[hidden])
Date: 2012-03-08 18:50:17

Le 08/03/2012 19:40, Vicente J. Botet Escriba a écrit :
> Le 07/03/12 23:36, Mathias Gaunard a écrit :
>> On 03/07/2012 11:20 PM, Christopher Jefferson wrote:
>>>
>>> On 7 Mar 2012, at 22:12, Mathias Gaunard wrote:
>>>
>>>> On 03/06/2012 07:49 PM, Vicente J. Botet Escriba wrote:
>>>>
>>>>> you are right. The goal been to provide a faster library implies that
>>>>> the Boost library should use the standard library when the 
>>>>> standard is
>>>>> more efficient, and we could expect that the standard is faster 
>>>>> for the
>>>>> scope it covers.
>>>>
>>>> What about correctness?
>>>>
>>>> Most implementations of standard library functions on complex 
>>>> numbers are not correct from a numerical point of view.
>>>
>>> Really? Can you give some examples? Have you reported these issues 
>>> to the various compiler designers?
>>
>> Verbatim from the libstdc++ headers
>>
>>   // 26.2.5/13
>>   // XXX: This is a grammar school implementation.
>>   template<typename _Tp>
>>     template<typename _Up>
>>     complex<_Tp>&
>>     complex<_Tp>::operator*=(const complex<_Up>& __z)
>>     {
>>       const _Tp __r = _M_real * __z.real() - _M_imag * __z.imag();
>>       _M_imag = _M_real * __z.imag() + _M_imag * __z.real();
>>       _M_real = __r;
>>       return *this;
>>     }
>>
>> This is incorrect for infinite types and causes undue overflow or 
>> underflow.
>>
> 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?
>
> Best,
> Vicente
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
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

Best,
      jt lapresté