>>>>> "Robert" == Robert Dodier <robert.dodier at gmail.com> writes:
Robert> On 1/1/07, Raymond Toy <toy.raymond at gmail.com> wrote:
>> But the interface is still undecided. There are quite a few options to
>> dgeev and dgesvd and I'm not sure how to expose all of them. Perhaps it
>> doesn't matter and the interface should be simple.
Robert> Maybe it is appropriate to have simplified interface at the Maxima level,
Robert> since one can always drop into Lisp to get all the bells and whistles.
Robert> Or make some of the arguments optional or keyword arguments
Robert> (by this I just mean recognize foo=bar in the arguments).
The interface right now is fairly simple.
dgeev(matrix, right-eig, left-eig)
dgesvd(matrix, u-p, v-p)
Where right-eig, left-eig, u-p, and v-p are optional args. In
particular, dgesvd supports quite a few more options which aren't
currently exposed. But perhaps that's good enough for now.
>> I'm also not sure about the copying of the Lisp array data to maxima
>> matrix type.
Robert> Not sure what you mean here. I'm pretty sure that the Maxima function
Robert> should take a Maxima matrix as an argument, and return a Maxima matrix.
Ok. I was just wondering if the functions should return the Lisp
arrays themselves instead of copying them to a Maxima matrix object.
As a first cut, this is ok.
The question now is if you still want lapack in src and not share. By
putting them in src, the routines are always available. However, it
adds quite a bit more time to compile it up (only a problem for
developers), but it also adds quite a bit of memory usage to maxima,
even for people who would never use these routines. (I'll try to
measure how much more memory soon.)
If they were in share, we wouldn't have this problem, except that
users will now take a hit to compile the lapack routines the first
time. But no memory bloat, and no additional compile time for
developers.
I can go either way on this. I would just like some opinions on the
right approach.
Ray