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