This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ wrapping


Gerard Jungman writes:
 > The idea that code generation is the answer... well, I don't know.
 > It makes sense for a limited problem, like generating a BLAS, or
 > even a LAPACK. ATLAS is clearly a good thing. But this is really an
 > implementation issue. In the end, I don't care how you created an
 > underlying linear algebra implementation. I just want it to work.

True, code generation is a separate issue from function calls.  It's
one of my bugbears because it is very painful to me that LAPACK,
ATLAS, FFTW, etc are ad-hoc.  Ideally I should be able to generate
LAPACK from a top-level description of the algorithms, which get
transformed into blocked/tuned implementation automatically.

 > Templates may not solve the problem of generating a special-cased
 > LAPACK in the most appealing way (in fact, I think code generation
 > makes more sense in this case), but that is not really the question
 > at hand, which is how to provide a clean interface to parametrized
 > algorithms, including the case when one or more parameters is
 > a function object.

Something that needs to be considered is whether it is possible to
unify forward and reverse communication, by specifying the
communication between the function and the algorithm in a more
abstract way (which can then be compiled in a forward or reverse
mode).  The problem of calling an arbitrary user-defined function does
not occur in reverse communication.  Probably the interaction between
a user-defined function and iterative algorithms is more naturally
expressed using co-routines.

-- 
Brian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]