|
|
Ublas : |
Subject: Re: [ublas] [bindings][lapack] Interface design
From: jesseperla_at_[hidden]
Date: 2008-12-04 22:41:22
> I think what you're proposing is not lapack-specific, but addresses the
> bindings in general. I think you would like to have bindings that play
well
> with the semantics of eg uBLAS?
Yes, that is true. My brain doesn't separate out these two as well as it
probably should... But my guess is that many people will be in the same
boat. They start using ublas, then when they realize that it doesn't
calculate eigenvalues or have a linear solver they call the bindings with
lapack.
> I would like to propose that we postpone this piece, because I think what
we
> should do (as bindings) if we want to do this well, is not only to write
> glue for uBLAS or similar, but also to dispatch calls to more than just
the
> LAPACK backend :-). (eg, ATLAS also knows some LAPACK).
Yes. I apologise for proposing syntatic gravy here. If we can
call "lapack::eigen( A, lambda );" and have it deduce the storage structure
of A from ublas traits, and to fill lambda with eigenvalues because it is a
vector, then we are 95% of the way there for the matlab porters I am
pretending to represent. And if we can have nearly full coverage of the
LAPACK functions through lower level calls like lapack::geev with a good
way to check usage through the source files, then we are 99% of the way
there. And at that point, further semantics could be implemented in GLAS...
One last comment for writing the script: If we are fudging with the
semantics of calling LAPACK at all, deducing parameters, etc. can we
generate simple doxygen embedded while we do it in the script? This might
make it relatively easy generate a document for calling conventions, etc.