math: Add float32 versions of functions (cosf, sinf, fminf, ...)

[nico]

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Use float32s for all your variables
2. Try to compute a cosine

What is the expected output? What do you see instead?

I expected to be able to write

  myfloat32 = math.Cosf(myotherfloat32)

Instead I have to write

  myfloat32 = float32(math.Cos(float64(myotherfloat32)))

This feels clunky and seems to contradict go's "no stuttering" principle.

Which revision are you using?  (hg identify)

6d2593965162 tip

[rsc]

Comment 1:

I think making the math library have two of everything stutters worse.
And why Cosf?  Wouldn't that be the version that takes just a "float", not a "float32"?
For better or worse, we've standardized on using float64 as the interface
to the math library.  If you call cos on float32 so often, you can always
write your own little wrapper in your package
func cos(f float32) float32 { return float32(math.Cos(float64(f))) }

Owner changed to r...@golang.org.

Status changed to WorkingAsIntended.

[nico]

Comment 2:

That's what I'm doing…but it does a bunch of float conversions which aren't really
necessary on x86…in theory, 
the math library could convert float32 directly to the fpu's float80.
Oh well, I guess computer graphics isn't the intended use case of go's standard library.
Not a huge deal, one can 
always write their own math32 library with efficient assembly if this turns out to be a
bottleneck.
(Why Cosf? Because `man cosf`.)

[rsc]

Comment 3:

Mailing lists are better for conversations; feel free to bring up
on golang-nuts if you think they should be there.  It seems very
x86-specific.