Fall-throughs for complex BLAS/LAPACK routines

[poulson]

It seems a bit strange to me that, while functions such as gemm! and herk! are templated over the datatype, it does not seem to currently be possible to use them in a way which is agnostic to whether or not the datatype is complex.

For example, a gemm invocation meant to take the adjoint of an argument would require a transposition flag of 'T' in the real case and 'C' in the complex case, whereas I would suggest having 'C' route to 'T' when the datatype is real (this is what I have done in Elemental, http://github.com/elemental/Elemental). Likewise, it would be useful for herk to fall through to syrk for real datatypes, etc.

[simonster]

If we make A_mul_B! and friends accept α and β, I don't think it should be necessary to call gemm! or herk! directly. That approach would also let us call generic methods for matrices of BigFloats etc. that aren't supported by BLAS. See some previous discussion in #160.

[poulson]

@simonster While I would be all for a simplified interface, this issue should still apply to more general routines (e.g., Hermitian eigensolvers).

[tkelman]

I think the intent right now is for anything using the blas/lapack names to be direct, thin wrappers corresponding very closely to the low-level API's.

I don't see anything wrong with defining he*! fallbacks for real types. I'm less sure about translating 'C' flags to 'T' for real arguments. We could maybe split the gemm wrapper loop in base/linalg/blas.jl for real types vs complex types and add something like transA == 'C' && transA = 'T'; transB == 'C' && transB = 'T' for the real cases. I would almost expect blas to already be doing that but I'd have to check.

[andreasnoack]

Actually, I don't think there is an issue with the Hermitian eigensolvers as we have also named the complex versions syev(d/r)!, so you could argue that we are a a bit inconsistent here.

However, as @simonster said, the idea has been that the BLAS/LAPACK wrapper are only thin wrappers with a minimum of checking of the arguments and allocation such that you can use the original documentation for them. Then on top of that, to have a layer for generic programming where the types can change without the need for changing the function.

I'm working on implementing the α and β versions and hopefully I can soon open a pull request. We'd need more wrappers for the generic layer, e.g. something like rankUpdate and it would also be great to have an option in eigfact(A::Hermitian) such that we can choose if we want the QR, DnC or RRR version.

[andreasnoack]

I think we should close with a won't fix here. The templating shouldn't be handled at the level of the BLAS/LAPACK wrappers.