gonum/netlib

lapack/lapacke: change BLAS-related types to byte

Closed this issue · 6 comments

vladimir-ch commented

In #38 we changed LAPACK-related types to byte because

  • the code generation cannot decide to what type it is should map a comp or job parameter based solely on its name and any other scheme is not practical
  • lapacke is a very low-level package and we don't have to or even should not provide any support in form of types and constants from the lapack package.

I think we should do the same for BLAS-related types and constants like blas.Side, blas.Transpose, blas.Uplo. The first point does not apply here but the second point is strong enough to justify the change of these types to byte.

kortschak commented

This seems eminently reasonable.

vladimir-ch commented

Oh, this is not so straightforward. I cannot just convert the arguments to byte, LAPACK(E) uses characters like 'U', 'L', 'N', 'T', 'C' while CBLAS (and our blas) uses some predefined integers in their respective interfaces.

We have to translate from CBLAS integers to LAPACK(E) characters somewhere but this cannot happen in lapacke any more because the functions will take the raw byte values. We can do this translation in lapack/netlib, or we can add lapack.Uplo, lapack.Diag, lapack.Transpose. In the latter case we could move blas.All constant to lapack.All because it does not really belong to blas, it's not used there at all. Or we can change the blas constants to characters and do the translation in blas/netlib because that's where it logically belongs but then we have to decide what to do with blas.All. I vote for this last approach. Thoughts?

kortschak commented

Do you mean (change the blas constants to characters and do the translation) in {gonum,netlib}/blas? I agree with this, but it will also happen in {gonum,netlib}/lapack for some functions. I think just hoisting one level (from a quick look, it appears that this is little change requires in {gonum,netlib}/blas since the architecture there is simpler than with lapack (we have one fewer levels of indirection to the actual work). Have I missed something?

vladimir-ch commented

With the "last approach" I mean to change the blas types to byte and the constants to characters in gonum/blas and do the translation to cblas integers in netlib/blas/netlib. At the same time change netlib/lapack/lapacke to take raw bytes that are assumed to be BLAS characters, not cblas integers. I think that no other changes are necessary.

kortschak commented

OK, so we make our code match the Fortran and do conversions for the cblas calls. That seems reasonable.

vladimir-ch commented

I think it is because Fortran BLAS and LAPACK, and C Lapacke all use characters, cblas is the only outlier.
I will take a look at it, I already have the changes for lapacke.