Existence of single precision blas?

[mathDR]

Hi, is the reason there aren't single precision (float32) implementations due to time constraints (i.e. you haven't had the chance to implement them) or for some other reason?

Is it the case that literally changing all calls of float64 to float32 would "create" single precision versions?

[btracey]

There are two main reasons. The first, as you suggest, is time. The second is that we don't plan on having a float32 matrix package. There are specific cases where float32 is useful, but in general float64 is much superior for numeric computation.

It is likely that the translation would be mostly straightforward. There are two obvious caveats: the level-1 method set is not identical in the two cases, and the float64 version uses the math package which has float64 arguments. Of course, the testing routines also have to be converted.

Please note that wrappers to C for float32 versions work (to the best of my knowledge, I haven't used them).

[mathDR]

Ah yes, great point about the math package only being double precision. I will close this issue then, as single precision most likely isn't required.

[fhs]

I would like to see float32 support as well. I don't understand how "level-1 method set is not identical". Can you elaborate? I think most people wouldn't want to use blas directly, but would want a matrix/mat32 package.

Instead of closing issues like this, maybe they should be kept open using a "longterm" label?

[kortschak]

@fhs, compare https://godoc.org/github.com/gonum/blas#Float32Level1 and https://godoc.org/github.com/gonum/blas#Float64Level1. There are a few higher precision float32 routines that are not (obviously) present in Float64.

[fhs]

Thanks. I understand now.

[kortschak]

This would also be an area where code gen would be appropriate - probably more so - except for Sdsdot and Dsdot which can either be (in the first instance wrapping of Ddot) or need their own code.