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-09 01:49:09

Le 09/03/12 00:50, jtl a écrit :
> 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?
>>
> 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.

Vicente