Re: [Matlisp-users] Re: Matrix column access

[Michael A. K. <ma...@ll...>]

Jan Rychter,
> Raymond Toy:
> 
>>>>>>>"Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
>>
>>    Nicolas> Yes, I did consider a unification.  I have tried to keep classes and
>>    Nicolas> methods very close, so that this should even be relatively easy.
>>
>>    Nicolas> On the other hand, the libraries have different purposes.  The FL.MATLISP
>>    Nicolas> tries to provide only basic operations avoiding all hassle with external
>>    Nicolas> libraries, while Matlisp strives to achieve all the functionality (and
>>    Nicolas> performance) of LAPACK.
>>
>>I would be happy to incorporate any or all of these things into
>>matlisp, if you are willing to donate them and if they seem
>>appropriate.
>>
>>Since I don't use matlisp at all and since Tunc doesn't seem to be
>>using matlisp anymore either, what happens in matlisp really, really
>>depends on the users now.  I'm willing to add functionality, but the
>>users need to describe what they want.
> 
> 
> I started using matlisp very recently and the things that were missing
> were:
> 
> -- why wasn't pinv (pseudoinverse) incorporated? I had to put it in
>    myself, and the patches were posted to the list some months ago...

This may be the PINV stuff I had posted some time back.  If so, it is a
matlab-compatible-hack of previously existing matlisp functions.  The "right-way"
would be to create a wrapper about one of the LAPACK routines
DGELSD.F/ZGELSD.F (I think).  I never got around to this.

> 
> -- not enough efficient data manipulation tools: the macros I posted for
>    operating on rows and columns are an example. I really really need
>    those to do anything serious.

I have noted this too.  However, I argue to myself that Matlisp shouldn't be
needlessly cluttered with lots of data manipulation tools.  Some more
"globally useful" ones would be nice, but identifying which ones is more of
a problem.  I tried this once...e.g.,

mike
---------------------
Dr Michael A. Koerber
x3250