Also, generics will not be a solution here, as the whole point is to have highly optimized code specifically calling e.g., 32bit MMX functions etc.

Why couldn't the compiler generate highly optimized code for specific instances of the generic API?

Yeah, I fail to see why this isn't viable.

func Cos[T constraints.Float](v T) T {
    switch any{v}.(type) { // or `switch type T` if parametric type switch is adopted
    case float32: return cosf32(v)
    case float64: return cosf64(v)
    }
}

Since these would be "well-known" functions, the compiler could potentially elide any overhead incurred by switching.

I'm not sure @smasher164 and @bcmills are saying the same thing:

@bcmills is perhaps suggesting that you could write the functions themselves generically, and if the compiler was really good, it would generate sufficiently optimized code relative to the current hand-optimized versions, for both 64 and 32 bit? But it looks like a number of functions in the existing math library are implemented in assembly so this isn't the current strategy even for float64?

@smasher164 is suggesting that you have exported wrapper functions that call the private optimized assembly functions.

In the latter case, given that the 32bit versions of all these functions would need to be implemented anyway, an intermediate step would be to create the transitional math32 library in golang.org/x/ and get that all debugged etc, and then when generics are available, just merge it in with the wrappers?

I'm not sure @smasher164 and @bcmills are saying the same thing

I did not interpret @bcmills's comment that way, mainly because it is nontrivial to write these functions generically. I interpreted it as "assuming you have some generic signature func Cos[T constraints.Float](v T) T, the compiler can do things like special-case inputs, and optimize function dispatch."

create the transitional math32 library

Yeah I think the real discussion here would be centered around the cost of implementation/maintenance. I've wondered for a while if we'd be able to leverage work done in metalibm to generate these procedures.

For graphics it was common a while ago to use tables instead of
invoking a function every time you needed a Sin/Cos anyway,
so having 32-bit versions would still not be the optimal answer.

I know less about machine learning but even there my understanding
is a lot of the time there are representations other than float32.

It's just unclear that there is enough widespread benefit for the standard library.

There are no compiler intrinsics used for Sin, Cos today.
It seems like the right next step would be to create a
go get'able library and see how widely it is used.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc even basic methods like Min / Max are widely used but seem to benefit from hand-coded assembly in the existing math lib to deal with the various special cases in terms of NaN / Inf. Sin / Cos are extensively used in graphics but most people would not take the extra step of implementing a lookup table, which has lots of tradeoffs and complexity. Having optimized float32 math would likely be an important addition to the Go infrastructure to support a broad range of applications at a high level of performance.

Ultimately the only answer for a very broad range of applications is to support third-party packages well. That seems entirely possible here. math32 need not be in the standard library.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

I guess the most compelling counter-argument would be that there are few things more basic and central to any programming environment than standard math functions. It seems unfortunate that such a core aspect of functionality, for one of the two types of floating point numbers, which affords significant performance advantages, would not be supported by the language's standard library.

For example, there is an existing math32 library: https://github.com/chewxy/math32 -- it is not frequently updated and a user recently reported significant performance issues.

What are the implications of this decision for the idea discussed above for generic wrappers?

Making the existing math package functions generic would be a breaking change, so we are not considering that.

No change in consensus, so declined.
— rsc for the proposal review group