octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: round-off error in std::pow(std::complex<T>, double) in C++11


From: Jordi Gutiérrez Hermoso
Subject: Re: round-off error in std::pow(std::complex<T>, double) in C++11
Date: Wed, 23 Jan 2013 16:24:25 -0500

On 23 January 2013 10:21, Marc Glisse <address@hidden> wrote:
> Here is what [cmplx.over] says:
>
> "Function template pow shall have additional overloads sufficient to ensure,
> for a call with at least one argument of type complex<T>:
> 1. If either argument has type complex<long double> or type long double,
> then both arguments are effectively cast to complex<long double>.
> 2. Otherwise, if either argument has type complex<double>, double, or an
> integer type, then both arguments are effectively cast to complex<double>.
> 3. Otherwise, if either argument has type complex<float> or float, then both
> arguments are effectively cast to complex<float>."
>
> So it looks like we are forced to convert 2 to a complex<double> and then
> call pow on that.

I am not very good at reading standardese, but what does "effectively
cast" mean here? Would it be sufficient to truncate the integral type
to float or double precision if necessary and then proceed with the
calculations with the integral type?

> Maybe the libm function doesn't round well then?

If you have floats or doubles as your type, I don't think you can
avoid the rounding error. Maybe it can be fixed in one direction when
the double is apparently an integer, but I am not sure this wouldn't
break the rounding in other cases.

> It should be possible to have a pow(complex<T>,int) overload
> (as-if), the question is what else is needed so it doesn't break
> stuff? (maybe nothing)

It seems to me that having the int overload, truncating its precision
if necessary, and then performing computations with integers (e.g. by
binary exponentiation), should not break anything else.

> The change in the standard comes from the fact that the listed
> overloads were ambiguous for many calls.

Yes, I'm aware:

    http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844

- Jordi G. H.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]