This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Jan 25, 2013 at 12:54 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Fri, 25 Jan 2013, Paolo Carlini wrote:
>
>> On 01/25/2013 05:18 PM, Paolo Carlini wrote:
>>>
>>> On 01/25/2013 04:44 PM, Paolo Carlini wrote:
>>>>
>>>> .. oops, I just noticed what Marc suggested in the PR about changing
>>>> pow(const complex<>&, const _Tp&) to *actually* forward to the complex
>>>> builtins when not fast math. That seems a good idea
>>>
>>> I have to add to this, however, that unless I did something badly wrong
>>> in a quick prototype, simply forwarding to the (complex, complex) builtin
>>> would *not* fix the round-off issue for this specific example. In other
>>> terms it seems that to actually get 0 we really have to handle separately
>>> (small) integer exponents, as Marc mentioned in the PR. Then again, is this
>>> overall a libstdc++ issue or it would make sense to have the (..., int)
>>> overloads restored at the *ISO* level?
>
>
> There are 2 possible things we can want for pow(z, 4): be fast, or be the
> correctly rounded value. I would (over-)interpret the presence of an int
> overload in the standard as a hint that we want the first, and its absence
> (or the C++11 wording) as a hint in favor of the second.

Why can't we be both fast and correct when the second
argument is an integer?


>
>
>> ... or, alternately, just forward to the builtins (at least when not fast
>> math) and have the builtins handle in an optimized way an exponent which is
>> a small integer.
>
>
> Implementing this optimization in the compiler when the exponent is a
> compile-time constant seems like a good and simple idea in any case :-)

Yes. :-)

>
>
>> I'm not at all convinced that when the Standard removes the (..., int)
>> overloads we want to red-add the overloads back in the library as an
>> implementation detail.
>
>
> The standard didn't remove it, it added hundreds of others so the int
> overload is now one among many covered by generic text.

The standard replaced code with prose/comments -- e.g. the
contrary of what we would like to do.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]