Re: PR83750: CSE erf/erfc pair

[Paul Koning <paulkoning at comcast dot net>]

> On Nov 5, 2018, at 1:48 PM, Michael Matz <matz@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