# Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps.

## matlisp-users

 [Matlisp-users] Matrix column access From: Jan Rychter - 2005-12-05 12:21:36 ```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 From: Nicolas Neuss - 2005-12-05 13:44:22 ```Jan Rychter 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 From: Jan Rychter - 2005-12-05 15:13:11 ```Nicolas Neuss: > Jan Rychter 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 From: Nicolas Neuss - 2005-12-05 17:02:06 ```Jan Rychter 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 From: Raymond Toy - 2005-12-05 18:08:35 ```>>>>> "Nicolas" == Nicolas Neuss 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 From: Nicolas Neuss - 2005-12-06 11:13:36 ```Raymond Toy writes: >>>>>> "Nicolas" == Nicolas Neuss 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 From: Raymond Toy - 2005-12-06 15:27:18 ```>>>>> "Nicolas" == Nicolas Neuss 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 From: Nicolas Neuss - 2005-12-06 21:02:22 ```Raymond Toy 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 From: Raymond Toy - 2005-12-06 21:34:19 ```>>>>> "Nicolas" == Nicolas Neuss 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 From: Cyrus Harmon - 2005-12-06 21:57:39 ```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 >>>>> 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 > Matlisp-users@... > https://lists.sourceforge.net/lists/listinfo/matlisp-users ```
 [Matlisp-users] Re: Matrix column access From: Jan Rychter - 2005-12-07 10:14:06 ```>>>>> "Cyrus" == Cyrus Harmon : [...] 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 From: A.J. Rossini - 2005-12-07 10:33:37 ```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 From: Steven H. Rogers - 2005-12-08 13:22:49 ```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 From: Nicolas Neuss - 2005-12-07 12:27:13 ```Cyrus Harmon 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 From: Jan Rychter - 2005-12-06 10:47:33 ```Raymond Toy: > >>>>> "Nicolas" == Nicolas Neuss 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 From: Raymond Toy - 2005-12-06 15:19:52 ```>>>>> "Jan" == Jan Rychter 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 From: Michael A. Koerber - 2005-12-06 12:43:18 ```Jan Rychter, > Raymond Toy: > >>>>>>>"Nicolas" == Nicolas Neuss 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 From: Jan Rychter - 2005-12-06 15:06:42 ```>>>>> "Michael" == Michael A Koerber : 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 From: Raymond Toy - 2005-12-06 15:21:10 ```>>>>> "Jan" == Jan Rychter writes: >>>>> "Michael" == Michael A Koerber : 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 From: Jan Rychter - 2005-12-06 16:41:10 ```>>>>> "Raymond" == Raymond Toy : >>>>> "Jan" == Jan Rychter 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 From: Robbie Sedgewick - 2005-12-06 17:33:50 ```On 12/6/05, Raymond Toy 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 From: Raymond Toy - 2005-12-06 19:55:53 ```>>>>> "Robbie" == Robbie Sedgewick writes: Robbie> On 12/6/05, Raymond Toy 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 From: Nicolas Neuss - 2005-12-07 12:35:54 ```Raymond Toy 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 From: Raymond Toy - 2005-12-07 14:10:36 ```>>>>> "Nicolas" == Nicolas Neuss writes: Nicolas> Raymond Toy 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 From: Nicolas Neuss - 2005-12-07 15:14:34 ```Raymond Toy writes: >>>>>> "Nicolas" == Nicolas Neuss writes: > > Nicolas> Raymond Toy 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. ```
 Re: [Matlisp-users] Re: Matrix column access From: Raymond Toy - 2005-12-07 14:14:44 ```>>>>> "AJ" == A J Rossini writes: AJ> (of course, I'm also shooting for general world domination, as well, AJ> which means including as much as possible in a single, cross-CL, AJ> package that I can use for facilitating LispStat, based on CommonLisp AJ> (across implementations), as a superior replacement for R). You do know, of course, that Matlisp only works with cmucl, sbcl, and allegro. No one has bothered to write the appropriate Fortran FFI macros for other systems. Perhaps using CFFI instead of our homegrown Fortran FFI would be useful here. Although I'm reluctant to add yet another external dependency, it could simplify some things quite a bit. Ray ```
 Re: [Matlisp-users] Re: Matrix column access From: A.J. Rossini - 2005-12-07 14:44:15 ```T24gMTIvNy8wNSwgUmF5bW9uZCBUb3kgPHJheW1vbmQudG95QGVyaWNzc29uLmNvbT4gd3JvdGU6 Cj4gPj4+Pj4gIkFKIiA9PSBBIEogUm9zc2luaSA8QS5KLj4gd3JpdGVzOgo+Cj4gICAgIEFKPiAo b2YgY291cnNlLCBJJ20gYWxzbyBzaG9vdGluZyBmb3IgZ2VuZXJhbCB3b3JsZCBkb21pbmF0aW9u LCBhcyB3ZWxsLAo+ICAgICBBSj4gd2hpY2ggbWVhbnMgaW5jbHVkaW5nIGFzIG11Y2ggYXMgcG9z c2libGUgaW4gYSBzaW5nbGUsIGNyb3NzLUNMLAo+ICAgICBBSj4gcGFja2FnZSB0aGF0IEkgY2Fu IHVzZSBmb3IgZmFjaWxpdGF0aW5nIExpc3BTdGF0LCBiYXNlZCBvbiBDb21tb25MaXNwCj4gICAg IEFKPiAoYWNyb3NzIGltcGxlbWVudGF0aW9ucyksIGFzIGEgc3VwZXJpb3IgcmVwbGFjZW1lbnQg Zm9yIFIpLgo+Cj4gWW91IGRvIGtub3csIG9mIGNvdXJzZSwgdGhhdCBNYXRsaXNwIG9ubHkgd29y a3Mgd2l0aCBjbXVjbCwgc2JjbCwgYW5kCj4gYWxsZWdyby4gIE5vIG9uZSBoYXMgYm90aGVyZWQg dG8gd3JpdGUgdGhlIGFwcHJvcHJpYXRlIEZvcnRyYW4gRkZJCj4gbWFjcm9zIGZvciBvdGhlciBz eXN0ZW1zLiAgUGVyaGFwcyB1c2luZyBDRkZJIGluc3RlYWQgb2Ygb3VyIGhvbWVncm93bgo+IEZv cnRyYW4gRkZJIHdvdWxkIGJlIHVzZWZ1bCBoZXJlLiAgQWx0aG91Z2ggSSdtIHJlbHVjdGFudCB0 byBhZGQgeWV0Cj4gYW5vdGhlciBleHRlcm5hbCBkZXBlbmRlbmN5LCBpdCBjb3VsZCBzaW1wbGlm eSBzb21lIHRoaW5ncyBxdWl0ZSBhCj4gYml0LgoKSSdtIFZFUlkgd2VsbCBhd2FyZSBvZiBpdC4g IEJ1dCAzIGlzIGEgZ29vZCBzdGFydCwgYW5kIENGRkkgZ2V0cwpiZXR0ZXIgYW5kIGJldHRlci4u LgoKYmVzdCwKLXRvbnkKCmJsaW5kZ2xvYmVAZ21haWwuY29tCk11dHRlbnosIFN3aXR6ZXJsYW5k LgoiQ29tbWl0IGVhcmx5LGNvbW1pdCBvZnRlbiwgYW5kIGNvbW1pdCBpbiBhIHJlcG9zaXRvcnkg ZnJvbSB3aGljaCB3ZSBjYW4gZWFzaWx5CnJvbGwtYmFjayB5b3VyIG1pc3Rha2VzIiAoQUpSLCA0 SmFuMDUpLgo= ```
 [Matlisp-users] Re: Matrix column access From: Jan Rychter - 2005-12-14 20:00:57 ```>>>>> "Nicolas" == Nicolas Neuss writes: Nicolas> Jan Rychter writes: [...] >> As it is, I'll probably reinvent the wheel and write my own >> functions using DCOPY, as you suggested. Nicolas> I'm quite sure this is the choice fitting the Matlisp way Nicolas> best. If you indeed want to make it into a generic function, Nicolas> it would be nice if you could use my MEXTRACT/MINJECT syntax. Nicolas> Probably, the Matlisp authors would also welcome such a Nicolas> contribution. Well, the discussion seems to have died, so I thought I'd contribute what I use now. It is much faster than my previous macros. Only works for real matrices for now. I didn't use DCOPY, because I don't know how to dereference a particular element in the matrix store, instead of the store itself (C pointers, anyone?). DCOPY would undoubtedly be much faster, especially for larger matrices. Nicolas -- sorry, I didn't use your syntax. I felt it isn't really compatible with matlisp and I really wanted to do things like (setf (column-ref m i) some-vector) --J. (defmethod column-ref ((matrix real-matrix) column) (let* ((n (nrows matrix)) (result (make-real-matrix-dim n 1)) (src-store (matlisp::store matrix)) (dst-store (matlisp::store result))) (declare (type fixnum n) (type (real-matrix-store-type (*)) src-store dst-store)) (dotimes (i n) (declare (type fixnum i)) (setf (aref dst-store i) (aref src-store (fortran-matrix-indexing i column n)))) result)) (defmethod (setf column-ref) (value (matrix real-matrix) column) (let* ((n (nrows matrix)) (src-store (matlisp::store value)) (dst-store (matlisp::store matrix))) (declare (type fixnum n) (type (real-matrix-store-type (*)) src-store dst-store)) (dotimes (i n) (declare (type fixnum i)) (setf (aref dst-store (fortran-matrix-indexing i column n)) (aref src-store i))) matrix)) (defmethod row-ref ((matrix real-matrix) row) (let* ((n (nrows matrix)) (m (ncols matrix)) (result (make-real-matrix-dim 1 m)) (src-store (matlisp::store matrix)) (dst-store (matlisp::store result))) (declare (type fixnum n m) (type (real-matrix-store-type (*)) src-store dst-store)) (dotimes (i m) (declare (type fixnum i)) (setf (aref dst-store (fortran-matrix-indexing 0 i 1)) (aref src-store (fortran-matrix-indexing row i n)))) result)) (defmethod (setf row-ref) (value (matrix real-matrix) row) (let* ((n (nrows matrix)) (m (ncols matrix)) (src-store (matlisp::store value)) (dst-store (matlisp::store matrix))) (declare (type fixnum n m) (type (real-matrix-store-type (*)) src-store dst-store)) (dotimes (i m) (declare (type fixnum i)) (setf (aref dst-store (fortran-matrix-indexing row i n)) (aref src-store (fortran-matrix-indexing 0 i 1)))) matrix)) (defmethod row-ref-transposed ((matrix real-matrix) row) (let* ((n (nrows matrix)) (m (ncols matrix)) (result (make-real-matrix-dim m 1)) (src-store (matlisp::store matrix)) (dst-store (matlisp::store result))) (declare (type fixnum n m) (type (real-matrix-store-type (*)) src-store dst-store)) (dotimes (i m) (declare (type fixnum i)) (setf (aref dst-store i) (aref src-store (fortran-matrix-indexing row i n)))) result)) ```