sinpi and cospi return incorrect results when using `--math-mode=fast`

[AboAmmar]

Julia 1.0:

I observed that when starting up Julia with the --math-mode=fast option, I get incorrect results for sinpi and cospi functions.

With the default math mode:

julia> a = rand(5)
5-element Array{Float64,1}:
 0.5897641978923696
 0.2459464145866952
 0.06373272357797632
 0.26244049804714087
 0.7254898186800567

julia> cospi.(a)
5-element Array{Float64,1}:
 -0.27827964958957724
  0.7160540045153001
  0.9800223981473272
  0.6789380012385138
 -0.650617399829044

julia> sinpi.(a)
5-element Array{Float64,1}:
 0.9605000971495538
 0.6980448858186719
 0.19888715174581242
 0.7341956077737403
 0.7594056880480248

while with --math-mode=fast option:

julia> cospi.(a)
5-element Array{Float64,1}:
 1.0
 1.0
 1.0
 1.0
 1.0

julia> sinpi.(a)
5-element Array{Float64,1}:
 0.0
 0.0
 0.0
 0.0
 0.0

[vtjnash]

Yes, that’s what it means to run in fast math mode. If you wanted correct answers, you should pass the ieee flag.

[StefanKarpinski]

Fast math mode should be off by no more than a few ulps; this not even close to correct:

# normal: `julia`

julia> sin(0.25pi)
0.7071067811865475

julia> sinpi(0.25)
0.7071067811865476

# fast math: `julia --math-mode=fast`

julia> sin(0.25pi)
0.7071067811865475

julia> sinpi(0.25)
0.0

[StefanKarpinski]

I suspect that this is a consequence of fast math mode performing some optimization which the implementation of sinpi and cospi relies on not happening—i.e. they are relying on correct IEEE behavior. So technically, this is what you're asking for but it seems like the better behavior here would be to replace sinpi(x) with sin(pi*x) in fast math mode instead of doing range reduction.

[tomaklutfu]

If you look at llvm ir of cospi(...::Float64) in fast mode it just returns 1.00 and it goes away if --inline=no flag is used together.

[yuyichao]

julia/base/special/trig.jl

Line 826 in 6b2d211

rx = abs(ax-((ax+s)-s))

is 0 under fast math. That's pretty much the expected result...

[Keno]

... In which we discover why global fast math flags are a horrible idea. I guess we could have a @nonfastmath macro to say "no really, I need IEEE behavior here".

[vtjnash]

Fast math mode should be off by no more than a few ulps;

That's a cute idea, but not what the flag means.

[StefanKarpinski]

... In which we discover why global fast math flags are a horrible idea.

💯%. However, we have it so should make this less broken.

This patch makes @fastmath sinpi(x) call sin(pi*x) instead of calling the sinpi implementation. However, it doesn't fix the behavior with the global --math-mode=fast flag on. Does that flag have a different effect than wrapping everything in @fastmath?

[StefanKarpinski]

Stop closing the issue, @vtjnash.

[vtjnash]

dup #24568
dup #21375
ref #25028