> On Nov 5, 2018, at 1:48 PM, Michael Matz <m...@suse.de> wrote:
>
> Hi,
>
> On Mon, 5 Nov 2018, Jeff Law wrote:
>
>>>> Don't we have a flag specific to honoring nans? Would that be better
>>>> to use than flag_unsafe_math_optimizations? As Uli mentioned,
>>>> there's
>>>
>>> That's only relevant for the comparison optimization, of course.
>>>
>>> Converting erfc to 1-erf is dubious, since the whole point of erfc is
>>> for cases where 1-erf is inaccurate. (Conversion in the other
>>> direction also needs flag_unsafe_math_optimizations.)
>>>
>> Understood. Thanks for clarifying. It seems like
>> unsafe-math-optimization is a better fit than the nan specific flag.
>
> But still we should consider general usefullness, even with unsafe-math.
> In this case we would remove a usage of a slow function that the user
> specifically used to deal with inaccuracies with an equally slow function
> (plus a little arithmetic that is shadows by the functions slowness) that
> now exacly produces the inaccuracies the user wanted to avoid. I.e. the
> speed gain is zero. The "canonicalization gain" referred to in the PR
> might be real, but it comes at the cost of introducing definite
> catastrophic cancellation.
>
> IMHO that's not a sensible transformation to do, under any flags.
That seems right. The same goes for log vs. logp1, and exp vs. expm1.
paul