[PATCH] Define 3-argument overloads of std::hypot for C++17 (P0030R1)

Jonathan Wakely jwakely@redhat.com
Wed Sep 28 11:55:00 GMT 2016


On 28/09/16 13:31 +0200, Marc Glisse wrote:
>On Wed, 28 Sep 2016, Jonathan Wakely wrote:
>
>>On 27/09/16 23:28 +0000, Joseph Myers wrote:
>>>On Tue, 27 Sep 2016, Jonathan Wakely wrote:
>>>
>>>>This adds the new 3D std::hypot() functions. This implementation seems
>>>>to be faster than the naïve sqrt(x*x + y*y + z*z) implementation, or
>>>>hypot(hypot(x, y), z), and should be a bit more accurate at very large
>>>>or very small values due to reducing the arguments by the largest one.
>>>>Improvements welcome though, as this is not my forte.
>>>
>>>Should I take it from this implementation that C++ is not concerned by
>>>certain considerations that would arise for C: spurious underflow
>>>exceptions from the scaling when some arguments much larger than others;
>>>spurious "invalid" exceptions from the comparisons when any argument is
>>>(quiet) NaN; handling of mixed (quiet) NaN and Inf arguments (where ISO C
>>>Annex F has Inf returned, not NaN)?
>>
>>The entire spec from the C++ draft is:  Returns: √ x^2 + y^2 + z^2
>>
>>It doesn't mention "without undue overflow or underflow" as the C
>>standard does for hypot(x, y). Handling those conditions would of
>>course be nice, but I'm not capable of doing so, and I'd rather have a
>>poor implementation than none.
>
>p0030r0 had "In addition to the two-argument versions of certain math
>functions in <cmath> and its float and long double overloads, C++ adds
>three-argument versions of these functions that follow similar semantics
>as their two-argument counterparts."
>
>One could interpret that as an intent to follow the C semantics. On the
>other hand, the paper mentions speed and convenience as the main selling
>points. Maybe LWG could clarify the intent?

I expect the answer will be that it's QoI.



More information about the Gcc-patches mailing list