correctly handle calling lapack routines with the correct API

[cartazio]

using

http://www.netlib.org/lapack/lapwrapc/

or clapack

or lapacke

[markmfredrickson]

It's not ready for a pull request yet, but I wanted to give a heads up that I'm working on expanding LAPACK functionality. To make things easier on myself, I've started with some of the simpler computational functions and let the underlying library worry about work space allocation. I'm planning to provide the _work versions as I build it out.

[cartazio]

Sweet! Be prepared for me getting very opinionated about the api :)

I do think that all things being equal, the only exported functions should
be the versions that expose the conditioning estimated to the user, even if
we do provide a simpler version in the style of the simple lapack
routines. But if you're willing to iterate with me on that, excellent! :)

A bunch of blas level 123 routines by a great gsoc student will be merged
in pretty soon , but that doesn't intersect with your work probably.

Again, be warned, the Api code review will be fierce :)

On Wednesday, August 19, 2015, Mark Fredrickson [email protected]
wrote:

It's not ready for a pull request yet, but I wanted to give a heads up
that I'm working on expanding LAPACK functionality
https://github.com/markmfredrickson/hblas/tree/MOAR-LAPACK. To make
things easier on myself, I've started with some of the simpler
computational functions and let the underlying library worry about work
space allocation. I'm planning to provide the _work versions as I build it
out.

—
Reply to this email directly or view it on GitHub
#11 (comment).

[markmfredrickson]

Great. I don't have strong opinions on the API, but I do have a few use cases that require exposing what the LAPACK guide calls "computational routines", not just the higher level "driver routines." E.g., iterative routines that can use the same QR decomposition over and over.

[cartazio]

awesome. Please feel welcome to ask questions on this ticket as you work on it.

NB: i may push back on the use of lapacke, if only because afaict, the OS X accelerate framework doesn't expose lapacke style symbols, and I very much want to try to keep things "zero config" on applicable platforms

[cartazio]

(even though the lapacke api wrappers are much nicer :'( )

[cartazio]

or we could emulate what open blas does and just include a copy of lapacke directly ... .... (that might lead to rabbit holes if its not done carefully though)
https://github.com/xianyi/OpenBLAS/tree/develop/lapack-netlib/lapacke/src

[cartazio]

or just selectively use the c source of lapacke to engineer the corresponding low level haskell analogue wrapper

[markmfredrickson]

It seems silly to me to have explicit types in the function names (e.g. sgetrf and. dgetrf for Float and Double). Here's an implementation that uses a typeclass to wrap up some related operations.. It doesn't cut down on the back end boiler plate, but it does simplify the API for users.

I'm getting some linker errors for the Complex Float and Complex Double instances, so they are disabled. As written, the compiler wanted me to turn on FlexibleInstances as well, though it wasn't clear to me why.