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.

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`.)

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.