matlisp-users

[Matlisp-users] Matrix column access

[Jan R. <ja...@ry...>]

Is there a way to efficiently operate on matrix columns and/or rows? I
often need to extract a column (or a row) and do operations on it,
sometimes storing it right back.

I expected to be able to use matrix-ref with a single number for this,
but couldn't find a simple way. Perusing the copious documentation
pointed me to the sequence parameter to matrix ref, so I came up with
this:

(defmacro extract-column (matrix column)
  `(matrix-ref ,matrix (seq 0 1 (1- (first (size ,matrix)))) ,column))

(defmacro extract-row (matrix row)
  `(matrix-ref ,matrix ,row (seq 0 1 (1- (second (size ,matrix))))))

This works (also for (setf (extract-column...))), but is very
inefficient, as it conses a *lot*. This is something I do very, very
often in my code, so the performance impact is huge.

Surely there must be a better way? From what I remember, matlisp stores
matrices in a column-major order, so at least columns could be processed
quickly...

--J.

PS: amusingly enough, it seems that using ATLAS actually slowed down my
program, by about 3%. Rather surprising.

Re: [Matlisp-users] Matrix column access

[Nicolas N. <Nic...@iw...>]

Jan Rychter <ja...@ry...> writes:

> Is there a way to efficiently operate on matrix columns and/or rows? I
> often need to extract a column (or a row) and do operations on it,
> sometimes storing it right back.

Probably, the easiest way for you to go is to call the BLAS routine DCOPY
(or similar) with suitable parameters:

MATLISP(9): (apropos "dcopy")
BLAS::FORTRAN-DCOPY [function] (N DX INCX DY ...)
DCOPY               [function] (N DX INCX DY ...)


If you want generic functions working on every matlisp matrix, you will
probably have to write a suitable set of functions yourself.  In my app
Femlisp (which contains a part written in CL giving basic matlisp
functionality) I have written (generic) functions

  minject ((x standard-matrix) (y standard-matrix) row-off col-off)

injecting x into y, and

  mextract ((x standard-matrix) (y standard-matrix) row-off col-off)

extracting y from x.

Yours, Nicolas.

P.S: Timings:

APPLICATION> (time (let ((A (eye 1000)) (x (zeros 1000 1)))
	       (loop repeat 1000 do (mextract A x 0 5))))
; cpu time (non-gc) 50 msec user, 0 msec system
; cpu time (gc)     10 msec user, 0 msec system
; cpu time (total)  60 msec user, 0 msec system
; real time  54 msec
; space allocation:
;  18,218 cons cells, 8,026,592 other bytes, 0 static bytes
NIL

compared with:

MATLISP(11): (time (let ((a (eye 1000)))
(loop repeat 1000 do (extract-column a 5))))
; cpu time (non-gc) 1,580 msec user, 0 msec system
; cpu time (gc)     90 msec user, 0 msec system
; cpu time (total)  1,670 msec user, 0 msec system
; real time  1,675 msec
; space allocation:
;  1,292,128 cons cells, 41,409,488 other bytes, 0 static bytes
NIL

[Matlisp-users] Re: Matrix column access

[Jan R. <ja...@ry...>]

Nicolas Neuss:
> Jan Rychter <ja...@ry...> writes:
> > Is there a way to efficiently operate on matrix columns and/or rows? I
> > often need to extract a column (or a row) and do operations on it,
> > sometimes storing it right back.
> 
> Probably, the easiest way for you to go is to call the BLAS routine DCOPY
> (or similar) with suitable parameters:
> 
> MATLISP(9): (apropos "dcopy")
> BLAS::FORTRAN-DCOPY [function] (N DX INCX DY ...)
> DCOPY               [function] (N DX INCX DY ...)
> 
> 
> If you want generic functions working on every matlisp matrix, you will
> probably have to write a suitable set of functions yourself.  In my app
> Femlisp (which contains a part written in CL giving basic matlisp
> functionality) I have written (generic) functions
> 
>   minject ((x standard-matrix) (y standard-matrix) row-off col-off)
> 
> injecting x into y, and
> 
>   mextract ((x standard-matrix) (y standard-matrix) row-off col-off)
> 
> extracting y from x.
> 
> Yours, Nicolas.
> 
> P.S: Timings:
> 
> APPLICATION> (time (let ((A (eye 1000)) (x (zeros 1000 1)))
> 	       (loop repeat 1000 do (mextract A x 0 5))))
> ; cpu time (non-gc) 50 msec user, 0 msec system
> ; cpu time (gc)     10 msec user, 0 msec system
> ; cpu time (total)  60 msec user, 0 msec system
> ; real time  54 msec
> ; space allocation:
> ;  18,218 cons cells, 8,026,592 other bytes, 0 static bytes
> NIL
> 
> compared with:
> 
> MATLISP(11): (time (let ((a (eye 1000)))
> (loop repeat 1000 do (extract-column a 5))))
> ; cpu time (non-gc) 1,580 msec user, 0 msec system
> ; cpu time (gc)     90 msec user, 0 msec system
> ; cpu time (total)  1,670 msec user, 0 msec system
> ; real time  1,675 msec
> ; space allocation:
> ;  1,292,128 cons cells, 41,409,488 other bytes, 0 static bytes
> NIL

Thanks, this is indeed much, much better. Have you considered
contributing some of your code back to matlisp? I looked at it, and
there is a lot of nice functionality in your fl.matlisp package (apart
from minject and mextract I also liked the BLAS-based vector
operations). I think this code could be very useful to many people. But
it seems it is dependent on some other utitilies, and I'd prefer not to
pull in the entire Femlisp code...

As it is, I'll probably reinvent the wheel and write my own functions
using DCOPY, as you suggested.

--J.

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

[Nicolas N. <Nic...@iw...>]

Jan Rychter <ja...@ry...> writes:

> Thanks, this is indeed much, much better. Have you considered
> contributing some of your code back to matlisp? I looked at it, and
> there is a lot of nice functionality in your fl.matlisp package (apart
> from minject and mextract I also liked the BLAS-based vector
> operations).

Yes, I did consider a unification.  I have tried to keep classes and
methods very close, so that this should even be relatively easy.

On the other hand, the libraries have different purposes.  The FL.MATLISP
tries to provide only basic operations avoiding all hassle with external
libraries, while Matlisp strives to achieve all the functionality (and
performance) of LAPACK.

> I think this code could be very useful to many people. But it seems it is
> dependent on some other utitilies, and I'd prefer not to pull in the
> entire Femlisp code...

The dependencies are relatively small.  I have once asked here, if there
was interest for a standalone version of FL.MATLISP, but there seemed to be
no real need.  Therefore, this will have to wait until someone needs it
more urgently.  This standalone would then be a natural candidate to
combine with Matlisp.

> As it is, I'll probably reinvent the wheel and write my own functions
> using DCOPY, as you suggested.

I'm quite sure this is the choice fitting the Matlisp way best.  If you
indeed want to make it into a generic function, it would be nice if you
could use my MEXTRACT/MINJECT syntax.  Probably, the Matlisp authors would
also welcome such a contribution.

Nicolas.

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

[Raymond T. <ray...@er...>]

>>>>> "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.

Ray

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

[Nicolas N. <Nic...@iw...>]

Raymond Toy <ray...@er...> writes:

>>>>>> "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.

Hello Ray,

> 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.

Yes, I would be willing to donate it.  The question is, if the benefit is
in a suitable relation to the work to do.  In my eyes, a reasonable work
program for improving Matlisp would be the following:

1. One should use the FL.MATLISP matrix structures (automatically
   generated) for Matlisp.  Printing and read-macro [] should be taken from
   Matlisp.

2. One should automate Matlisp's BLAS interface.  Something like (get-blas
   'daxpy) should make the Fortran daxpy routine available.

3. Also Matlisp's methods for BLAS and LAPACK generic functions which
   interface the Fortran routines should be automatically generated
   whenever possible, maybe following the route I took in Femlisp.  It
   would be nice if one could also extract documentation.
   Anyway, this is the hard part.  I am not sure if it is doable without
   a lot of work.

4. Extensions like matrix slices, etc, allowing easy translation of Matlab
   code should be provided.

This program is nontrivial, and at the moment I cannot afford to work on
it, since I am searching for a job.

> 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.
>
> Ray

It looks as if there are only very few people actually using Matlisp.
Considering this, there may be other places where spending CL programmer
time is more fruitful at the moment.

Yours, Nicolas.

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

[Raymond T. <ray...@er...>]

>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:

    Nicolas> Hello Ray,

Hello!

    >> 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.

    Nicolas> Yes, I would be willing to donate it.  The question is, if the benefit is
    Nicolas> in a suitable relation to the work to do.  In my eyes, a reasonable work
    Nicolas> program for improving Matlisp would be the following:

Cool.

    Nicolas> 1. One should use the FL.MATLISP matrix structures (automatically
    Nicolas>    generated) for Matlisp.  Printing and read-macro [] should be taken from
    Nicolas>    Matlisp.

What are FL.MATLISP matrix structures?

    Nicolas> 2. One should automate Matlisp's BLAS interface.  Something like (get-blas
    Nicolas>    'daxpy) should make the Fortran daxpy routine available.

I don't follow what you mean by this.  They're always available in
Matlisp.

    Nicolas> 3. Also Matlisp's methods for BLAS and LAPACK generic functions which
    Nicolas>    interface the Fortran routines should be automatically generated
    Nicolas>    whenever possible, maybe following the route I took in Femlisp.  It

Yes, that's possible.  I think there was confusion on what to expose
and how.  Was there supposed to be a very low-level interface to
LAPACK/BLAS, or should the interface be a bit higher-level and more
lisp?  Or what?  I think we ended up with a somewhat incoherent mix,
mostly driven by what users (mostly Tunc) wanted.

    Nicolas>    would be nice if one could also extract documentation.

That's a bit harder because the docs are just comments in the LAPACK
routines themselves.

    Nicolas> 4. Extensions like matrix slices, etc, allowing easy translation of Matlab
    Nicolas>    code should be provided.

I think Simon Alexander has a very fast Lisp matrix slicing package.  Don't
know if it would work with Matlisp or not.

    Nicolas> This program is nontrivial, and at the moment I cannot afford to work on
    Nicolas> it, since I am searching for a job.

Good luck in your job search!

Ray

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

[Nicolas N. <Nic...@iw...>]

Raymond Toy <ray...@er...> writes:

>     Nicolas> 1. One should use the FL.MATLISP matrix structures (automatically
>     Nicolas>    generated) for Matlisp.  Printing and read-macro [] should be taken from
>     Nicolas>    Matlisp.
>
> What are FL.MATLISP matrix structures?

FL.MATLISP is the name of the corresponding package in Femlisp.  I do
generate the classes for the types automatically:

(defun standard-matrix (type)
  "Defines the programmatic class @class{standard-matrix} for element type
@arg{type} as extensions of the programmatic class @class{store-vector}."
  (assert (subtypep type 'number))
  (fl.amop:find-programmatic-class
   (list 'standard-matrix (store-vector type))
   (intern (format nil "~A" (list 'STANDARD-MATRIX type)) "FL.MATLISP")))

This makes it possible to have also matrices of single-floats, etc.

>     Nicolas> 2. One should automate Matlisp's BLAS interface.  Something like (get-blas
>     Nicolas>    'daxpy) should make the Fortran daxpy routine available.
>
> I don't follow what you mean by this.  They're always available in
> Matlisp.

But not every routine as much as I remember.  And for complete generality,
also the single-float versions should be available.  I think that it should
be possible to automate the process of making such a routine available.

>     Nicolas> 3. Also Matlisp's methods for BLAS and LAPACK generic functions which
>     Nicolas>    interface the Fortran routines should be automatically generated
>     Nicolas>    whenever possible, maybe following the route I took in Femlisp.  It
>
> Yes, that's possible.  I think there was confusion on what to expose
> and how.  Was there supposed to be a very low-level interface to
> LAPACK/BLAS, or should the interface be a bit higher-level and more
> lisp?  Or what?  I think we ended up with a somewhat incoherent mix,
> mostly driven by what users (mostly Tunc) wanted.

I think you did that quite well.  At least I like your generic function
interface.  What I don't like is the duplication of code for the different
matrix classes.

> Good luck in your job search!
> Ray

Thank you,

Nicolas.

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

[Raymond T. <ray...@er...>]

>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:

    Nicolas> This makes it possible to have also matrices of single-floats, etc.

Oh, matlisp consciously supports only double-floats, but single-floats
would be possible.  Some kind of macro like you have would help.

    Nicolas> 2. One should automate Matlisp's BLAS interface.  Something like (get-blas
    Nicolas> 'daxpy) should make the Fortran daxpy routine available.
    >> 
    >> I don't follow what you mean by this.  They're always available in
    >> Matlisp.

    Nicolas> But not every routine as much as I remember.  And for
    Nicolas> complete generality, also the single-float versions
    Nicolas> should be available.  I think that it should be possible
    Nicolas> to automate the process of making such a routine
    Nicolas> available.

I think all the BLAS routines are there.  (Well, maybe not the level-3
blas routines).  

Not quite sure what you mean by automating the process of making the
routines available.  Someone has to figure out the function signature
to tell Lisp how to call it.  And some of the functions take
characters or strings, and that is very dependent on the Fortran
compiler.  Same with returning complex values.

I did toy around with the idea of letting f2cl grovel over the
functions and extracting the interfaces, but I didn't get very far
with that.

    Nicolas> interface.  What I don't like is the duplication of code
    Nicolas> for the different matrix classes.

Yes, that's not good.  It's been cleaned up some, but I think there's
still quite a bit of duplication.

Ray

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

[Cyrus H. <ch-...@bo...>]

Nicolas and Ray,

I hope this isn't to off-topic, but I thought I'd jump in to the  
middle of this conversation and point out my matrix library, clem.  
It's available at http://cyrusharmon.org/cl/static/releases/ 
clem-0.1.5-20051204.tar.gz .

It's not the greatest, but it does have CLOS support for a standard- 
matrix-class and facilities for designing "typed" matrices and fast  
generic functions for those matrices. Currently it supports the  
obvious types, number, real, complex, float, double-float, single- 
float, ub{8,16,32}, sb{8,16,32}, and bit. On SBCL at least, much of  
the matrix arithmetic doesn't cons. The operations supported are  
rather limited, but it does do affine transformation, discrete  
convolution, multiplication, etc...

It takes a while to compile and there's probably better ways to make  
this stuff go faster (define-compiler-macro maybe? more inline  
functions?) but it's better than nothing and is handy for me as I  
need big bit matrices and using a double-float for matlisp is kind of  
a waste here.

I've also done a little bit of work to go back and forth to matlisp.  
I was rather disappointed that the state of matrix math packages on  
common-lisp was that I had to write my own. I would gladly abandon  
this project for an alternative, but I haven't found that yet. In the  
meantime, feedback on it is greatly appreciated.

Thanks,

Cyrus

On Dec 6, 2005, at 1:34 PM, Raymond Toy wrote:

>>>>>> "Nicolas" == Nicolas Neuss <Nicolas.Neuss@iwr.uni- 
>>>>>> heidelberg.de> writes:
>
>     Nicolas> This makes it possible to have also matrices of single- 
> floats, etc.
>
> Oh, matlisp consciously supports only double-floats, but single-floats
> would be possible.  Some kind of macro like you have would help.
>
>     Nicolas> 2. One should automate Matlisp's BLAS interface.   
> Something like (get-blas
>     Nicolas> 'daxpy) should make the Fortran daxpy routine available.
>>>
>>> I don't follow what you mean by this.  They're always available in
>>> Matlisp.
>
>     Nicolas> But not every routine as much as I remember.  And for
>     Nicolas> complete generality, also the single-float versions
>     Nicolas> should be available.  I think that it should be possible
>     Nicolas> to automate the process of making such a routine
>     Nicolas> available.
>
> I think all the BLAS routines are there.  (Well, maybe not the level-3
> blas routines).
>
> Not quite sure what you mean by automating the process of making the
> routines available.  Someone has to figure out the function signature
> to tell Lisp how to call it.  And some of the functions take
> characters or strings, and that is very dependent on the Fortran
> compiler.  Same with returning complex values.
>
> I did toy around with the idea of letting f2cl grovel over the
> functions and extracting the interfaces, but I didn't get very far
> with that.
>
>     Nicolas> interface.  What I don't like is the duplication of code
>     Nicolas> for the different matrix classes.
>
> Yes, that's not good.  It's been cleaned up some, but I think there's
> still quite a bit of duplication.
>
> Ray
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users

[Matlisp-users] Re: Matrix column access

[Jan R. <ja...@ry...>]

>>>>> "Cyrus" == Cyrus Harmon <ch-...@bo...>:
[...]
 Cyrus> I've also done a little bit of work to go back and forth to
 Cyrus> matlisp.  I was rather disappointed that the state of matrix
 Cyrus> math packages on common-lisp was that I had to write my own. I
 Cyrus> would gladly abandon this project for an alternative, but I
 Cyrus> haven't found that yet. In the meantime, feedback on it is
 Cyrus> greatly appreciated.

Well, from this interesting discussion it looks like there are at least
several people interested in a matrix math package. Interested enough to
write their own code, which means a lot.

How about reviving Matlisp and making it a common base? While I like
CLEM's functionality, I think using BLAS and LAPACK is pretty much a
requirement, because of efficiency and a well-tested code base. So
Matlisp it will be, at least for me. AJ Rossini's hints about his work
on a statistics package sound very promising as well. But I'd much
rather see things converge than end up with a number of incompatible
math libraries.

--J.

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

[A.J. R. <bli...@gm...>]

PiBXZWxsLCBmcm9tIHRoaXMgaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBpdCBsb29rcyBsaWtlIHRo
ZXJlIGFyZSBhdCBsZWFzdAo+IHNldmVyYWwgcGVvcGxlIGludGVyZXN0ZWQgaW4gYSBtYXRyaXgg
bWF0aCBwYWNrYWdlLiBJbnRlcmVzdGVkIGVub3VnaCB0bwo+IHdyaXRlIHRoZWlyIG93biBjb2Rl
LCB3aGljaCBtZWFucyBhIGxvdC4KCj4gQnV0IEknZCBtdWNoCj4gcmF0aGVyIHNlZSB0aGluZ3Mg
Y29udmVyZ2UgdGhhbiBlbmQgdXAgd2l0aCBhIG51bWJlciBvZiBpbmNvbXBhdGlibGUKPiBtYXRo
IGxpYnJhcmllcy4KCkdvb2QgaW5zaWdodCwgYW5kIGFncmVlIHN0cm9uZ2x5IHdpdGggdGhlIGxh
dHRlciBzZW50aW1lbnQuICBJJ20KZGVmaW5pdGVseSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgbW9z
dGx5IHdpdGggbWF0bGlzcCBpZiBwb3NzaWJsZSBhbmQKaW1wcm92aW5nIGl0LiAgTGVzcyBzbyB3
aXRoIG90aGVyIHBhY2thZ2VzIChubyBvZmZlbnNlLCBDeXJ1cyEpLgoKKG9mIGNvdXJzZSwgSSdt
IGFsc28gc2hvb3RpbmcgZm9yIGdlbmVyYWwgd29ybGQgZG9taW5hdGlvbiwgYXMgd2VsbCwKd2hp
Y2ggbWVhbnMgaW5jbHVkaW5nIGFzIG11Y2ggYXMgcG9zc2libGUgaW4gYSBzaW5nbGUsIGNyb3Nz
LUNMLApwYWNrYWdlIHRoYXQgSSBjYW4gdXNlIGZvciBmYWNpbGl0YXRpbmcgTGlzcFN0YXQsIGJh
c2VkIG9uIENvbW1vbkxpc3AKKGFjcm9zcyBpbXBsZW1lbnRhdGlvbnMpLCBhcyBhIHN1cGVyaW9y
IHJlcGxhY2VtZW50IGZvciBSKS4KCmJlc3QsCi10b255CgpibGluZGdsb2JlQGdtYWlsLmNvbQpN
dXR0ZW56LCBTd2l0emVybGFuZC4KIkNvbW1pdCBlYXJseSxjb21taXQgb2Z0ZW4sIGFuZCBjb21t
aXQgaW4gYSByZXBvc2l0b3J5IGZyb20gd2hpY2ggd2UgY2FuIGVhc2lseQpyb2xsLWJhY2sgeW91
ciBtaXN0YWtlcyIgKEFKUiwgNEphbjA1KS4K

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

[Steven H. R. <st...@sh...>]

U3BlYWtpbmcgb2YgdmFyaW91cyBtYXRyaXggcGFja2FnZXMsIGhhcyBhbnlvbmUgb24gdGhp
cyBsaXN0IGxvb2tlZCBhdCBOTGlzcCANCihodHRwOi8vd3d3LmNwb20ub3JnL25saXNwLyk/
DQoNCkEuSi4gUm9zc2luaSB3cm90ZToNCj4+V2VsbCwgZnJvbSB0aGlzIGludGVyZXN0aW5n
IGRpc2N1c3Npb24gaXQgbG9va3MgbGlrZSB0aGVyZSBhcmUgYXQgbGVhc3QNCj4+c2V2ZXJh
bCBwZW9wbGUgaW50ZXJlc3RlZCBpbiBhIG1hdHJpeCBtYXRoIHBhY2thZ2UuIEludGVyZXN0
ZWQgZW5vdWdoIHRvDQo+PndyaXRlIHRoZWlyIG93biBjb2RlLCB3aGljaCBtZWFucyBhIGxv
dC4NCj4gDQo+IA0KPj5CdXQgSSdkIG11Y2gNCj4+cmF0aGVyIHNlZSB0aGluZ3MgY29udmVy
Z2UgdGhhbiBlbmQgdXAgd2l0aCBhIG51bWJlciBvZiBpbmNvbXBhdGlibGUNCj4+bWF0aCBs
aWJyYXJpZXMuDQo+IA0KPiANCj4gR29vZCBpbnNpZ2h0LCBhbmQgYWdyZWUgc3Ryb25nbHkg
d2l0aCB0aGUgbGF0dGVyIHNlbnRpbWVudC4gIEknbQ0KPiBkZWZpbml0ZWx5IGludGVyZXN0
ZWQgaW4gd29ya2luZyBtb3N0bHkgd2l0aCBtYXRsaXNwIGlmIHBvc3NpYmxlIGFuZA0KPiBp
bXByb3ZpbmcgaXQuICBMZXNzIHNvIHdpdGggb3RoZXIgcGFja2FnZXMgKG5vIG9mZmVuc2Us
IEN5cnVzISkuDQo+IA0KPiAob2YgY291cnNlLCBJJ20gYWxzbyBzaG9vdGluZyBmb3IgZ2Vu
ZXJhbCB3b3JsZCBkb21pbmF0aW9uLCBhcyB3ZWxsLA0KPiB3aGljaCBtZWFucyBpbmNsdWRp
bmcgYXMgbXVjaCBhcyBwb3NzaWJsZSBpbiBhIHNpbmdsZSwgY3Jvc3MtQ0wsDQo+IHBhY2th
Z2UgdGhhdCBJIGNhbiB1c2UgZm9yIGZhY2lsaXRhdGluZyBMaXNwU3RhdCwgYmFzZWQgb24g
Q29tbW9uTGlzcA0KPiAoYWNyb3NzIGltcGxlbWVudGF0aW9ucyksIGFzIGEgc3VwZXJpb3Ig
cmVwbGFjZW1lbnQgZm9yIFIpLg0KPiANCj4gYmVzdCwNCj4gLXRvbnkNCj4gDQo+IGJsaW5k
Z2xvYmVAZ21haWwuY29tDQo+IE11dHRlbnosIFN3aXR6ZXJsYW5kLg0KPiAiQ29tbWl0IGVh
cmx5LGNvbW1pdCBvZnRlbiwgYW5kIGNvbW1pdCBpbiBhIHJlcG9zaXRvcnkgZnJvbSB3aGlj
aCB3ZSBjYW4gZWFzaWx5DQo+IHJvbGwtYmFjayB5b3VyIG1pc3Rha2VzIiAoQUpSLCA0SmFu
MDUpLg0KPiDvv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73ThisSF++/vd616ZqKWO+/ve+/ve+/vSfvv73vv73v
v71177+977+9Su+/vW7vv71CJ3Pvv73vv73Ki++/ve+/ve+/vW3vv73vv70u77+9GWjvv73v
v71677+96K6a77+9blfvv73vv73vv73Downloadt77+977+977+977+9AkBex5rvv73vv71e
77+9CO+/vXrvv71a77+9Zu+/vXrvv70eau+/vSHvv714Mu+/ve+/ve+/vQfvv73vv70a77+9
77+9yass77+977+977+9C2F7B++/ve+/vTPvv70077+977+9DQo+ICPvv71Q77+977+977+9
77+9ae+/ve+/ve+/vXbvv73vv73vv73vv71y77+977+977+977+977+977+9fu+/vWpZaHPv
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v
v73vv73vv73vv70a77+9WO+/ve+/ve+/vXrvv70maili77+9CWLvv73vv70a77+9WO+/ve+/
ve+/vXrvv73vv73vv70rLe+/ve+/vSjvv73vv70efu+/ve+/vXvvv73ethtt77+977+977+9
77+9WO+/ve+/ve+/ve+/ve+/ve+/vXnvv70r77+977+977+9eu+/ve+/ve+/vWzvv71Y77+9
77+9Kd+j77+9WO+/ve+/ve+/vQ0KPiANCj4gDQoNCi0tIA0KU3RldmVuIEguIFJvZ2Vycywg
UGguRC4sIHN0ZXZlQHNocm9nZXJzLmNvbQ0KV2VibG9nOiBodHRwOi8vc2hyb2dlcnMuY29t
L3dlYmxvZw0KIkhlIHdobyByZWZ1c2VzIHRvIGRvIGFyaXRobWV0aWMgaXMgZG9vbWVkIHRv
IHRhbGsgbm9uc2Vuc2UuIg0KLS0gSm9obiBNY0NhcnRoeQ0KDQo=

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

[Nicolas N. <Nic...@iw...>]

Cyrus Harmon <ch-...@bo...> writes:

> Nicolas and Ray,
>
> I hope this isn't to off-topic, but I thought I'd jump in to the  
> middle of this conversation and point out my matrix library, clem.  
> It's available at http://cyrusharmon.org/cl/static/releases/ 
> clem-0.1.5-20051204.tar.gz .
> ...
> It takes a while to compile and there's probably better ways to make  
> this stuff go faster (define-compiler-macro maybe? more inline  
> functions?) ...

> I've also done a little bit of work to go back and forth to matlisp.  
> I was rather disappointed that the state of matrix math packages on  
> common-lisp was that I had to write my own. I would gladly abandon  
> this project for an alternative, but I haven't found that yet. In the  
> meantime, feedback on it is greatly appreciated.

In FL.MATLISP (which is my notation for "Femlisp's Matlisp replacement"),
matrix class generation and method compilation happens only when necessary,
so it compiles fast.  You should be able to do the same.

In general, I do agree with Jan Rychter that the Matlisp interface should
be kept as much as possible (and I tried to do this with FL.MATLISP).

It could be interesting to compare the performance of FL.MATLISP with your
library.  If I remember well, I did not see large differences in comparison
with C (lower than a factor 2 for larger matrices).

Yours, Nicolas.

[Matlisp-users] Re: Matrix column access

[Jan R. <ja...@ry...>]

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...

-- 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.

-- minor stuff, like min/max.

--J.

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

[Raymond T. <ray...@er...>]

>>>>> "Jan" == Jan Rychter <ja...@ry...> writes:

    Jan> I started using matlisp very recently and the things that were missing
    Jan> were:

    Jan> -- why wasn't pinv (pseudoinverse) incorporated? I had to put it in
    Jan>    myself, and the patches were posted to the list some months ago...

Mostly because no one wanted it early on, and later because I was
lazy.

It also doesn't help my motivation when someone (not you!) asks for
some functionality, and I ask a question about it, and never hear from
him again.

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

What other kind of data manipulation tools are you looking for?

    Jan> -- minor stuff, like min/max.

This kind of stuff isn't there mostly because of my laziness, and
because of the lack of requests for such functionality.  Plus, what is
min/max supposed to do on a matrix?  Return the min/max element of the
matrix?

Ray

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

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

[Jan R. <ja...@ry...>]

>>>>> "Michael" == Michael A Koerber <ma...@ll...>:
 Michael> Jan Rychter,
 >> -- why wasn't pinv (pseudoinverse) incorporated? I had to put it in
 >> myself, and the patches were posted to the list some months ago...

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

Your stuff has the advantage of actually working, which places it way
above other solutions.o

Could we please incorporate it into the Matlisp CVS?

--J.

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

[Raymond T. <ray...@er...>]

>>>>> "Jan" == Jan Rychter <ja...@ry...> writes:

>>>>> "Michael" == Michael A Koerber <ma...@ll...>:
    Michael> Jan Rychter,
    >>> -- why wasn't pinv (pseudoinverse) incorporated? I had to put it in
    >>> myself, and the patches were posted to the list some months ago...

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

    Jan> Your stuff has the advantage of actually working, which places it way
    Jan> above other solutions.o

    Jan> Could we please incorporate it into the Matlisp CVS?

If Michael says the "right way" is DGELSD/ZGELSD, I would prefer to do
that.  I'll look into providing the hook to these functions.  I'll
need some help on what people want pinv to look like.  Presumably, it
will look like whatever Michael has done.

Ray

[Matlisp-users] Re: Matrix column access

[Jan R. <ja...@ry...>]

>>>>> "Raymond" == Raymond Toy <ray...@er...>:
>>>>> "Jan" == Jan Rychter <ja...@ry...> writes:
 Jan> I started using matlisp very recently and the things that were
 Jan> missing were:

 Jan> -- why wasn't pinv (pseudoinverse) incorporated? I had to put it
 Jan>    in myself, and the patches were posted to the list some months ago...

 Raymond> Mostly because no one wanted it early on, and later because I
 Raymond> was lazy.

Fair enough!

 Raymond> It also doesn't help my motivation when someone (not you!) 
 Raymond> asks for some functionality, and I ask a question about it,
 Raymond> and never hear from him again.

Well, we'll try to be better this time :-)

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

 Raymond> What other kind of data manipulation tools are you looking
 Raymond> for?

Basically, something corresponding to my extract-row and extract-column
macros.

An important point in my case is that I'd like to have extra-efficient
versions of those for some operations. Ideally I'd like to be able to do
an (m- (extract-column m i) b) without actually copying the elements of
that column.

 Jan> -- minor stuff, like min/max.
 Raymond> This kind of stuff isn't there mostly because of my laziness,
 Raymond> and because of the lack of requests for such functionality.
 Raymond> Plus, what is min/max supposed to do on a matrix?  Return the
 Raymond> min/max element of the matrix?

I use these mostly on vectors, on matrices I'd like to have a row-major
and a column-major min/max, each returning a vector. Perhaps a min/max
on the entire matrix is useful for people as well, I don't know.

--J.

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

[Robbie S. <bob...@gm...>]

On 12/6/05, Raymond Toy <ray...@er...> wrote:
>
> I think Simon Alexander has a very fast Lisp matrix slicing package.  Don=
't
> know if it would work with Matlisp or not.

Is this available somewhere?  I'd like to take a look at it.  I
started writing something similar  a year ago, but never got it
finished.

A basic google search didn't turn it up...

Thanks,
Robbie

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

[Raymond T. <ray...@er...>]

>>>>> "Robbie" == Robbie Sedgewick <bob...@gm...> writes:

    Robbie> On 12/6/05, Raymond Toy <ray...@er...> wrote:
    >> 
    >> I think Simon Alexander has a very fast Lisp matrix slicing package.  Don't
    >> know if it would work with Matlisp or not.

    Robbie> Is this available somewhere?  I'd like to take a look at it.  I
    Robbie> started writing something similar  a year ago, but never got it
    Robbie> finished.

I don't know.  I'll have to ask him.

Ray

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

[Nicolas N. <Nic...@iw...>]

Raymond Toy <ray...@er...> writes:

> I think all the BLAS routines are there.  (Well, maybe not the level-3
> blas routines).

I guess one of those is what I once would have needed and did not find.

> Not quite sure what you mean by automating the process of making the
> routines available.  Someone has to figure out the function signature
> to tell Lisp how to call it.  And some of the functions take
> characters or strings, and that is very dependent on the Fortran
> compiler.  Same with returning complex values.

Does this mean that interfacing to Fortran libraries is ill-defined?  Maybe
one should use the C-interface of BLAS/LAPACK then?

Nicolas.

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

[Raymond T. <ray...@er...>]

>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:

    Nicolas> Raymond Toy <ray...@er...> writes:
    >> Not quite sure what you mean by automating the process of making the
    >> routines available.  Someone has to figure out the function signature
    >> to tell Lisp how to call it.  And some of the functions take
    >> characters or strings, and that is very dependent on the Fortran
    >> compiler.  Same with returning complex values.

    Nicolas> Does this mean that interfacing to Fortran libraries is ill-defined?  Maybe
    Nicolas> one should use the C-interface of BLAS/LAPACK then?

Perhaps.  Replacing them all would be quite a bit of work, though.  Is
the C interface just that and you still have to use Fortran for 
BLAS/LAPACK, so you get another layer?

I think the standard used by Matlisp is the standard for the old
portable f77 compiler, which is used by g77 and Sun f77, so it's not
so bad.  I suspect that I'm the only one who uses something other than
g77, and I don't do that very often either.

For the record, Fortran strings are represented as basically C
strings, and the length of the string is appended to the list of
parameters.  Functions returning complex values actually insert a new
parameter into the arg list and this parameter is a pointer to where
the complex value should be stored.  This is probably how the C
interface works.

Ray

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

[Nicolas N. <Nic...@iw...>]

Raymond Toy <ray...@er...> writes:

>>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
>
>     Nicolas> Raymond Toy <ray...@er...> writes:
>     >> Not quite sure what you mean by automating the process of making the
>     >> routines available.  Someone has to figure out the function signature
>     >> to tell Lisp how to call it.  And some of the functions take
>     >> characters or strings, and that is very dependent on the Fortran
>     >> compiler.  Same with returning complex values.
>
>     Nicolas> Does this mean that interfacing to Fortran libraries is ill-defined?  Maybe
>     Nicolas> one should use the C-interface of BLAS/LAPACK then?
>
> Perhaps.  Replacing them all would be quite a bit of work, though.  Is
> the C interface just that and you still have to use Fortran for 
> BLAS/LAPACK, so you get another layer?

If one uses clapack, it uses f2c (http://www.netlib.org/clapack/readme).
But I don't know how performance does compare.

> I think the standard used by Matlisp is the standard for the old
> portable f77 compiler, which is used by g77 and Sun f77, so it's not
> so bad.  I suspect that I'm the only one who uses something other than
> g77, and I don't do that very often either.
>
> For the record, Fortran strings are represented as basically C
> strings, and the length of the string is appended to the list of
> parameters.  Functions returning complex values actually insert a new
> parameter into the arg list and this parameter is a pointer to where
> the complex value should be stored.  This is probably how the C
> interface works.
>
> Ray

Ouch, this looks much nastier than I thought.  I googled, and did not find
even a complete C interface to the Fortran BLAS/LAPACK libraries.  In this
case, trying to do an automatic CL interface is probably not very
reasonable.

Thanks for the information,

Nicolas.