Boost logo

Boost :

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


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk