|
|
Ublas : |
Subject: Re: [ublas] Snapshot 20081116
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-11-24 08:40:17
Rutger ter Borg wrote:
> Thanks for the script, I was able to run it, and get an example of how
> a result should look like. I have a couple of questions regarding this
> script,
>
> * for which set of functions is it supposed to work?
> all lapack driver subroutines?
The idea is that the number of files in lapack-3.1.1/SRC is finite (even
if it frustratingly large). So it should be possible to classify the
files into sufficient fine subclasses (by heuristics + exception lists),
and do the appropriate thing for each subclass.
I see three basic classes:
- the files that we are not interested in (for example all d*.f and z*.f
files)
- the lapack files that we are interested in
- the blas files that we are interested in
In additional to that, there will always be some members of the
following class
- files that we cannot parse correctly
For the lapack files, I see a further subdivision with respect to their
"workspace" requirements, because I would also like to generate the
workspace handling boilerplate code automatically.
> * what would you ideally like to see as a result? i.e., what the
script
> produces right now, or more?
For the lapack files with "workspace", I would also like to see the
struct with the operator() overload doing the workspace handling. (The
actual numbers in the asserts and the allocations could be omitted,
since it is not much work to enter them by hand.) Theses are templates
instead of inline functions, because float/double is replaced by R and
complex_f/complex_d is replaced by T. Apart from that, only the
workspace argument is worked on, the other arguments are passed
unmodified to the corresponding inline overload. (I also think it's
sufficient to generate the code for real and complex separately without
taking the "twin" into account. The merging of the two into a single
file should be easily doable by hand.)
Apart from that, I have to admit that I had postponed thinking about
what I want to get until I have enough time to implement it. I also
thought that such a script might be useful for projects that don't want
to adapt the numeric bindings library, for whatever reasons (minimizing
dependencies, bindings against a programming language different from
C++, ...). For the numeric bindings library, it might also be useful to
generate the header of the file including license statement, include
guard and required includes. The same goes for closing parenthesis and
the #endif statement at the end of file. What I definitely don't want to
generate automatically is the actual bindings interface to the outside
C++ world.
My plan with the script was to first get it working with "python
lapack_extractor.py c*.f" and "python lapack_extractor.py s*.f" called
inside the lapack-3.1.1/SRC directory, and then think about how to
"refactor" the script.
Regards,
Thomas