split single and double precision blas into separate packages

[dane-unltd]

split the blas package into single and double precision. pave the way for blas wrapper.

[kortschak]

What's the rationale for this?

[dane-unltd]

The double precision part is/will be the most widely used and it is kind of standard for go (see e.g. the math, math/cmplx packages). It is unlikely that someone will use both single and double precision, but even then there is no drawback of having two packages. The blas32 package together with the reference implementation could also quite easily be auto-generated from the standard double precision package. Additionally, the docs are smaller, especially if we want to add additional things to the blas package (#3).

[kortschak]

Should this involve a rename of blas -> blas64? Also it sort of argues that the complex routines should also be split out. Is that worth considering - this results in a large multiplicity of packages.

Generating a blas32 reference mechanically is not too hard, but not zero effort since there are extra single precision routines.

[dane-unltd]

I would leave the double precision package name with blas but we can also change it if someone thinks that that would be confusing. Right now there is no interdependency between the complex and the real part so it could possibly be split. But I also think this might be too much. It would make naming and directory layout a bit tricky. And at least where I come from, complex numbers are actually more common.

[kortschak]

I'd like to wait for other input as I have no real opinion on this. @btracey?

[btracey]

It seems the main argument for is keeping the docs small. It seems to me like it should be one package. At far as I can tell, people talk about “blas” as one entity. This suggests it should be one package. The package docs as they look now are very straightforward. Float64, Complex128, etc. With the suggested additions of convenience wrappers (using the Matrix and Vector types in your other pull requests) this adds two types per numeric type, and it adds one function per blas function. While this is a lot, it’s on par with the way blas is represented by other packages. The way the package is structured now (and will be with your additions), the main blas package is “What is the blas”. It lists the functions that the blas is, and provides interfaces that help group the calls together. The subpackages are “how is the blas implemented”, i.e. different ways to call blas functions. This seems like a pretty logical organization to me.

One possible idea is to put the Matrix/Vector types into their own package, and keep the high level blas definitions in gonum/blas. This would give us

blas blas/cblas blas/referenceblas blas/goblas blas/blas64 blas/cplx128 (names can be changed)

The direct implementations of the blas routines would be how they are now. The convenience wrappers (with Matrix and Vector types) would be in blas64. Additionally, the “Register” function would be in blas64 (and corresponding register function in cplx128). This keeps the main blas documentation clean, and also allows a default implementation without adding a circular import problem. From a user’s perspective, calling blas64.Ddot(myvector) is still pretty nice.

Thoughts?

On Jan 30, 2014, at 12:49 AM, kortschak notifications@github.com wrote:

I'd like to wait for other input as I have no real opinion on this. @btracey?

— Reply to this email directly or view it on GitHub.

[dane-unltd]

Yes I think we can do that. what about naming the wrapper packages blasd, blasz, blass, blasc? We could also remove the first letters from the blas functions in the wrappers (the numerical type moved to the package name) blasd.Axpy(...), blasz.Axpy(...) etc.

@kortschak If Dan agrees on the structure we can close this pull request and continue the discussion on the package names etc. on #3.

[kortschak]

Thinking. Yes, probably it's OK to drop the initial letter; we've made a fair amount of deviation from the standard by now anyway.

[kortschak]

On splitting, how about we merge in what is proposed and see how the thing looks. Then, if it's too large, we can split it.

[dane-unltd]

seems not to be an issue at the moment. closing for now.