matlisp-users — General discussion list.

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

[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

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

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

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

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.

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

[Matlisp-users] Problems with sbcl 0.9.4 osx

[Christos G. <gio...@gm...>]

Even though the subject goes straight to the matter, as a new member of the
mailing list I would firstly like to thank those who offered this extremely
useful work.

A. Brief description of the problem:
I can (load "/matlib/start.lisp") and everything works fine (except for the
help system which throws me to the debugger) until I exit lisp. If I start
lisp again, the functions are undefined and I get an error of
UNDEFINED-ALIEN-FUNCTION.

If I save-lisp-and-exit, the core is loadable but functions are still
undefined in the new core.

SIDENOTE: I can get a working Matlisp if I go to /matlisp/bin and delete the
fasls and let SBCL compile them again.


B. System Details
I have managed to install the cvs version of Matlisp as of 29-Nov-2005 on an
iBook G4 with g77 (GCC 3.4) and Xcode v2.2 (even though I am not sure that
means it uses gcc 4.0). Firstly, I had to play around a little with the
makefile as it would not compile libmatlisp.o or anything except
lazy-loader, so my manual installation is probably the reason of the
problem.
If I remember well, somewhere in the makefile was a /sw/bin which implies a
need for FINK which I have not installed.

I can still work with this messy procedure of deleting the fasls every time,
but every hint to the direction of solving this problem would be very
helpful.

Yours,
Christos Giogkarakis

Re: [Matlisp-users] Questions about matlisp

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

>>>>> "AJ" == A J Rossini <A.J.> writes:

    AJ> I've evaluated matlisp 2.0beta and it seems like it might work, with
    AJ> some glue, as the backend replacement for the current numerical linear
    AJ> algebra code.  But of course, there are some questions:

    AJ> #1 - mixing of ASDF (some of the current tools, cells-gtk and clunit,
    AJ> that I've started using) and MK:DEFSYSTEM installations?  Is it worth
    AJ> adding a joint ASDF build system for uniformity/install compatibility?

I'm not really an asdf user, so it probably won't be kept up-to-date,
unless users do so.

However, I have no problem mixing and matching asdf with mk:defsys.
This works especially well if your lisp supports an extension to
require that will load systems using asdf or mk:defsys.

    AJ> #2 - current status of the 2.0beta?  (it looks to be stalled for 2+ years now)

It's feature-complete. :-)  

I don't use it much, so any changes to matlisp these days are driven
by user requests or patches.  (Which reminds me that here is an
outstanding request.)

    AJ> #3 - interest in taking back some of the possible changes?

Yes, of course!

    AJ> Also, have there been many changes in CVS compared to the 2003
    AJ> 2.0 beta release?

Probably quite a few, but probably not many that a user would notice.
I'd have to check logs to be sure....

Ray

[Matlisp-users] Questions about matlisp

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

R3JlZXRpbmdzIQoKRm9yIHZhcmlvdXMgYW11c2luZyByZWFzb25zLCBJJ20gd29ya2luZyBhdCBy
ZXN1cnJlY3RpbmcgTGlzcFN0YXQgKGFuCmludGVyYWN0aXZlIHN0YXRpc3RpY2FsIGxhbmd1YWdl
L3BhY2thZ2Ugb3JpZ2luYWxseSBpbXBsZW1lbnRlZCBvbiB0b3AKb2YgWExpc3AsIGJ1dCB0aGVy
ZSB3YXMgYSBsaXR0bGUta25vd24gQ29tbW9uTGlzcCBwb3J0IHRoYXQgbmV2ZXIgbWFkZQppdCBv
ZmYgdGhlIGdyb3VuZCkuICAgQXJlYXMgb2Ygd2Vha25lc3MgdGhhdCBJJ20gd29ya2luZyB0byBh
ZGRyZXNzCmluY2x1ZGUgdGhlIHVuZGVybHlpbmcgbWF0aGVtYXRpY2FsIGFsZ29yaXRobXMgYW5k
IHRoZWlyIEZGSXMKKG9yaWdpbmFsbHkgb25seSBmb3IgS0NMLCBNQ0wsIGFuZCBBQ0wsIGJhY2sg
MTUgeWVhcnMgYWdvISksIGJyaW5nIGl0CnVwIHRvIGN1cnJlbnQgQU5TSSAoZnJvbSBDTHRMMiks
IGFuZCBpbmNvcnBvcmF0aW5nIHZhcmlvdXMgbW9kZXJuCnBhY2thZ2VzIGFuZCBjYXBhYmlsaXRp
ZXMuCgpJJ3ZlIGV2YWx1YXRlZCBtYXRsaXNwIDIuMGJldGEgYW5kIGl0IHNlZW1zIGxpa2UgaXQg
bWlnaHQgd29yaywgd2l0aApzb21lIGdsdWUsIGFzIHRoZSBiYWNrZW5kIHJlcGxhY2VtZW50IGZv
ciB0aGUgY3VycmVudCBudW1lcmljYWwgbGluZWFyCmFsZ2VicmEgY29kZS4gIEJ1dCBvZiBjb3Vy
c2UsIHRoZXJlIGFyZSBzb21lIHF1ZXN0aW9uczoKCiMxIC0gbWl4aW5nIG9mIEFTREYgKHNvbWUg
b2YgdGhlIGN1cnJlbnQgdG9vbHMsIGNlbGxzLWd0ayBhbmQgY2x1bml0LAp0aGF0IEkndmUgc3Rh
cnRlZCB1c2luZykgYW5kIE1LOkRFRlNZU1RFTSBpbnN0YWxsYXRpb25zPyAgSXMgaXQgd29ydGgK
YWRkaW5nIGEgam9pbnQgQVNERiBidWlsZCBzeXN0ZW0gZm9yIHVuaWZvcm1pdHkvaW5zdGFsbCBj
b21wYXRpYmlsaXR5PwoKIzIgLSBjdXJyZW50IHN0YXR1cyBvZiB0aGUgMi4wYmV0YT8gIChpdCBs
b29rcyB0byBiZSBzdGFsbGVkIGZvciAyKyB5ZWFycyBub3cpCgojMyAtIGludGVyZXN0IGluIHRh
a2luZyBiYWNrIHNvbWUgb2YgdGhlIHBvc3NpYmxlIGNoYW5nZXM/CgpBbHNvLCBoYXZlIHRoZXJl
IGJlZW4gbWFueSBjaGFuZ2VzIGluIENWUyBjb21wYXJlZCB0byB0aGUgMjAwMyAyLjAgYmV0YSBy
ZWxlYXNlPwoKYmVzdCwKLXRvbnkKCmJsaW5kZ2xvYmVAZ21haWwuY29tCk11dHRlbnosIFN3aXR6
ZXJsYW5kLgoiQ29tbWl0IGVhcmx5LGNvbW1pdCBvZnRlbiwgYW5kIGNvbW1pdCBpbiBhIHJlcG9z
aXRvcnkgZnJvbSB3aGljaCB3ZSBjYW4gZWFzaWx5CnJvbGwtYmFjayB5b3VyIG1pc3Rha2VzIiAo
QUpSLCA0SmFuMDUpLgo=

Re: [Matlisp-users] (no subject)

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

>>>>> "Jeremy" == Jeremy Shute <js...@ya...> writes:

    Jeremy> On the Matlisp homepage, I see:
    Jeremy> ...Cholesky decompositions and the list continues...

    Jeremy> Which method does Cholesky?  I can't find any mention of Cholesky by grepping
    Jeremy> the src/ folder, though I see it in the Fortran files...

Hmm.  I can't find it either.  It appears that the Cholesky
decomposition is in dpotrf and friends.

I'll look into adding it.

If it's in LAPACK, but not matlisp, it usually means no one got around
to hooking up an interface to it because no one had a need for it.

    Jeremy> (matlisp:help) doesn't work on my SBCL for whatever reason...

I've heard that, but I don't have a fix for that.

Ray

[Matlisp-users] (no subject)

[Jeremy S. <js...@ya...>]

On the Matlisp homepage, I see:

...Cholesky decompositions and the list continues...

Which method does Cholesky?  I can't find any mention of Cholesky by grepping
the src/ folder, though I see it in the Fortran files...

(matlisp:help) doesn't work on my SBCL for whatever reason...

Thanks,

Jeremy


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Progress Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

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

>>>>> "Harri" == Harri Hakula <Har...@tk...> writes:

    Harri> PS. Apple provides both BLAS and LAPACK routines in the form a
    Harri> framework. Whether
    Harri> frameworks can be loaded from Allegro is not clear to me.

Are they carefully optimized versions or just compiled versions?  If
they're optimized, it would be interesting to allow matlisp to use
them.  Matlisp already allows using ATLAS for BLAS.

Ray

Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

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

>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes:

    Marco> This may not be all that kosher.  The source-pathname here should
    Marco> probably be "matlisp:src;"

Why not?  The directory separator is needed?  But Harri Says It Works
For Him, So I'Ll Be Sure To Add That In.

Ray

Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

[Harri H. <Har...@tk...>]

Dear All,

I posted too soon! The trailing #\; did the trick!

Thank you very much again.

Cheers,

     Harri Hakula

On Aug 19, 2005, at 7:30 PM, Marco Antoniotti wrote:

> Can you inspect the "foreign-interface" module and send out the  
> result of a DESCRIBE?
>
> On Aug 19, 2005, at 10:23 AM, Raymond Toy wrote:
>
>
>>>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes:
>>>>>>>
>>
>>     Marco> Hi
>>
>>     Marco> This looks more like a Logical Pathname problem with  
>> ACL 7.0.
>>
>> Could be, but could be defsystem too.  I've always had some problems
>> with logical pathnames and defsystem.
>>
>>     Harri> ;    - Loading module "foreign-interface"
>>     Harri> Warning: An error occurred
>>     Harri>           (No translation rule for #P"matlisp:;src;f77- 
>> mangling.lisp")
>>     Harri>           during the reading or evaluation of -e
>>
>> Is rather suspicious because the defsystem there says
>>
>> (mk::defsystem matlisp
>>       :source-pathname "matlisp:"
>>       :source-extension "lisp"
>>       :binary-pathname "matlisp:bin;"
>>       :depends-on ("lazy-loader"
>>                    "matlisp-packages")
>>       :components
>>       ((:module "foreign-interface"
>>     :source-pathname "matlisp:src"
>>
>
> This may not be all that kosher.  The source-pathname here should  
> probably be "matlisp:src;"
>
>
>
>
>>     :source-extension "lisp"
>>     :binary-pathname ""
>>     :components ("f77-mangling"
>>              #+:cmu "ffi-cmu"
>>              #+:sbcl "ffi-sbcl"
>>              #+:allegro "ffi-acl"
>>              ))
>>        ...))
>>
>>
>> I don't see how it could produce the pathname
>> "matlisp:;src;f77-mangling.lisp".  It should be
>> "matlisp:src;f77-mangling.lisp".
>>
>>
>> As a workaround, Harri could just change "matlisp:src" to be
>> (translate-logical-pathname "matlisp:src") and similarly in other
>> places.
>>
>
> I just recompiled matlisp under CMUCL and did not have any  
> problems.  If you have to make changes, I'd try adding the trailing  
> #\; first.
>
> Cheers
>
> --
> Marco Antoniotti                    http://bioinformatics.nyu.edu
> NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
> 715 Broadway 10th FL                fax. +1 - 212 - 998 3484
> New York, NY, 10003, U.S.A.
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>

Progress Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

[Harri H. <Har...@tk...>]

Dear All,

I changed "matlisp:src" to
(translate-logical-pathname "/src")
since (translate-logical-pathname "matlisp:src") in the component  
ended up
expanding "matlisp" twice, this is for component modules, anyway.
This is, of course, a desperate hack and not a long-lasting solution  
to this problem...

Since I'm on the trial version, I had to limit the number of packages  
I could test :-)
but I'm happy to report that I've succesfully run an axpy!

Thank you very much for your helpful and prompt replies.

Once I've got my full license (waiting for funding) I'll report on  
the exact configuration,
fortran options etc.

Best regards,

     Harri Hakula

PS. Apple provides both BLAS and LAPACK routines in the form a  
framework. Whether
frameworks can be loaded from Allegro is not clear to me.

On Aug 19, 2005, at 5:23 PM, Raymond Toy wrote:

>>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes:
>>>>>>
>
>     Marco> Hi
>
>     Marco> This looks more like a Logical Pathname problem with ACL  
> 7.0.
>
> Could be, but could be defsystem too.  I've always had some problems
> with logical pathnames and defsystem.
>
>     Harri> ;    - Loading module "foreign-interface"
>     Harri> Warning: An error occurred
>     Harri>           (No translation rule for #P"matlisp:;src;f77- 
> mangling.lisp")
>     Harri>           during the reading or evaluation of -e
>
> Is rather suspicious because the defsystem there says
>
> (mk::defsystem matlisp
>       :source-pathname "matlisp:"
>       :source-extension "lisp"
>       :binary-pathname "matlisp:bin;"
>       :depends-on ("lazy-loader"
>                    "matlisp-packages")
>       :components
>       ((:module "foreign-interface"
>     :source-pathname "matlisp:src"
>     :source-extension "lisp"
>     :binary-pathname ""
>     :components ("f77-mangling"
>              #+:cmu "ffi-cmu"
>              #+:sbcl "ffi-sbcl"
>              #+:allegro "ffi-acl"
>              ))
>        ...))
>
>
> I don't see how it could produce the pathname
> "matlisp:;src;f77-mangling.lisp".  It should be
> "matlisp:src;f77-mangling.lisp".
>
>
> As a workaround, Harri could just change "matlisp:src" to be
> (translate-logical-pathname "matlisp:src") and similarly in other
> places.
>
> Ray
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>

Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

[Marco A. <ma...@cs...>]

Can you inspect the "foreign-interface" module and send out the result 
of a DESCRIBE?

On Aug 19, 2005, at 10:23 AM, Raymond Toy wrote:

>>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes:
>
>     Marco> Hi
>
>     Marco> This looks more like a Logical Pathname problem with ACL 
> 7.0.
>
> Could be, but could be defsystem too.  I've always had some problems
> with logical pathnames and defsystem.
>
>     Harri> ;    - Loading module "foreign-interface"
>     Harri> Warning: An error occurred
>     Harri>           (No translation rule for 
> #P"matlisp:;src;f77-mangling.lisp")
>     Harri>           during the reading or evaluation of -e
>
> Is rather suspicious because the defsystem there says
>
> (mk::defsystem matlisp
>       :source-pathname "matlisp:"
>       :source-extension "lisp"
>       :binary-pathname "matlisp:bin;"
>       :depends-on ("lazy-loader"
>                    "matlisp-packages")
>       :components
>       ((:module "foreign-interface"
> 	:source-pathname "matlisp:src"

This may not be all that kosher.  The source-pathname here should 
probably be "matlisp:src;"



> 	:source-extension "lisp"
> 	:binary-pathname ""
> 	:components ("f77-mangling"
> 		     #+:cmu "ffi-cmu"
> 		     #+:sbcl "ffi-sbcl"
> 		     #+:allegro "ffi-acl"
> 		     ))
>        ...))
>
>
> I don't see how it could produce the pathname
> "matlisp:;src;f77-mangling.lisp".  It should be
> "matlisp:src;f77-mangling.lisp".
>
>
> As a workaround, Harri could just change "matlisp:src" to be
> (translate-logical-pathname "matlisp:src") and similarly in other
> places.

I just recompiled matlisp under CMUCL and did not have any problems.  
If you have to make changes, I'd try adding the trailing #\; first.

Cheers

--
Marco Antoniotti					http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group		tel. +1 - 212 - 998 3488
715 Broadway 10th FL				fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

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

>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes:

    Marco> Hi

    Marco> This looks more like a Logical Pathname problem with ACL 7.0.

Could be, but could be defsystem too.  I've always had some problems
with logical pathnames and defsystem.

    Harri> ;    - Loading module "foreign-interface"
    Harri> Warning: An error occurred
    Harri>           (No translation rule for #P"matlisp:;src;f77-mangling.lisp")
    Harri>           during the reading or evaluation of -e

Is rather suspicious because the defsystem there says 

(mk::defsystem matlisp
      :source-pathname "matlisp:"
      :source-extension "lisp"
      :binary-pathname "matlisp:bin;"
      :depends-on ("lazy-loader"
                   "matlisp-packages")
      :components
      ((:module "foreign-interface"
	:source-pathname "matlisp:src"
	:source-extension "lisp"
	:binary-pathname ""
	:components ("f77-mangling"
		     #+:cmu "ffi-cmu"
		     #+:sbcl "ffi-sbcl"
		     #+:allegro "ffi-acl"
		     ))
       ...))


I don't see how it could produce the pathname
"matlisp:;src;f77-mangling.lisp".  It should be
"matlisp:src;f77-mangling.lisp".


As a workaround, Harri could just change "matlisp:src" to be
(translate-logical-pathname "matlisp:src") and similarly in other
places.

Ray

Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

[Harri H. <Har...@tk...>]

On Aug 19, 2005, at 6:19 AM, Marco Antoniotti wrote:


> Hi
>
> This looks more like a Logical Pathname problem with ACL 7.0.
>
> What does
>
>     (logical-pathname-translations "matlisp")
>
> return?
>
> If it signals an error what does
>
>     (logical-pathname-translations "MATLISP")
>
> return?
>
>

Here comes:

CL-USER(1): (logical-pathname-translations "matlisp")
((#P"**;*.*" #P"/Users/hhakula/Desktop/matlisp/**/*.*"
   #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL
                                    :DEVICE NIL
                                    :DIRECTORY NIL
                                    :NAME NIL
                                    :TYPE ...))
(#P"*.*" #P"/Users/hhakula/Desktop/matlisp/*.*"
   #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL
                                    :DEVICE NIL
                                    :DIRECTORY NIL
                                    :NAME NIL
                                    :TYPE ...)))
CL-USER(2): (logical-pathname-translations "MATLISP")
((#P"**;*.*" #P"/Users/hhakula/Desktop/matlisp/**/*.*"
   #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL
                                    :DEVICE NIL
                                    :DIRECTORY NIL
                                    :NAME NIL
                                    :TYPE ...))
(#P"*.*" #P"/Users/hhakula/Desktop/matlisp/*.*"
   #S(EXCL::CACHED-TRANSLATION-INFO :HOST NIL
                                    :DEVICE NIL
                                    :DIRECTORY NIL
                                    :NAME NIL
                                    :TYPE ...)))

Cheers,

     Harri

Re: [Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

[Marco A. <ma...@cs...>]

Hi

This looks more like a Logical Pathname problem with ACL 7.0.

What does

	(logical-pathname-translations "matlisp")

return?

If it signals an error what does

	(logical-pathname-translations "MATLISP")

return?

Cheers

marco





On Aug 18, 2005, at 11:11 AM, Harri Hakula wrote:

> Environment: Allegro 7.0 trial/MacOSX 10.4
>
> I have downloaded the latest matlisp via CVS.
>
> I've compiled the libraries with xlf 8.1 and am reasonably confident 
> that everything
> is OK. Loading fails, however. This looks like a mk::defsystem problem.
> (Then again, I'm a newbie, or at least feel like one :-)
>
> ;  - Loading defsystem "matlisp"
> ;    - Loading module "foreign-interface"
> Warning: An error occurred
>          (No translation rule for #P"matlisp:;src;f77-mangling.lisp")
>
> Harri Hakula
> Institute of Mathematics
> Helsinki University of Technology
>
> Here is the output from make:
> ==============================================
> ~/Desktop/acl70_trial/alisp -e '(progn (load "start.lisp"))'
> ; Loading /Users/hhakula/Desktop/matlisp/start.lisp
> ;   Loading /Users/hhakula/Desktop/matlisp/system.dcl
> ;     Loading /Users/hhakula/Desktop/matlisp/defsystem.lisp
> ;   Loading /Users/hhakula/Desktop/matlisp/config.lisp
>
> ;  - Loading defsystem "matlisp-packages"
> ;    - Loading binary file 
> "/Users/hhakula/Desktop/matlisp/packages.fasl"
> ;   Fast loading /Users/hhakula/Desktop/matlisp/packages.fasl
> ;  - Providing system matlisp-packages
>
> ;  - Loading defsystem "lazy-loader"
> ;    - Loading binary file
> ;      "/Users/hhakula/Desktop/matlisp/bin/lazy-loader.fasl"
> ;   Fast loading /Users/hhakula/Desktop/matlisp/bin/lazy-loader.fasl
> ;     Foreign loading matlisp:lib;libmatlisp.dylib.
> ;  - Providing system lazy-loader
>
> ;  - Loading defsystem "matlisp"
> ;    - Loading module "foreign-interface"
> Warning: An error occurred
>          (No translation rule for #P"matlisp:;src;f77-mangling.lisp")
>          during the reading or evaluation of -e
>          "(progn (load \"start.lisp\"))"
> International Allegro CL Trial Edition
> 7.0 [Mac OS X] (Aug 4, 2005 16:09)
> Copyright (C) 1985-2004, Franz Inc., Oakland, CA, USA.  All Rights 
> Reserved.
>
> This development copy of Allegro CL is licensed to:
>    Harri Hakula, Helsinki University of Technology
>
> ;; Optimization settings: safety 1, space 1, speed 1, debug 2.
> ;; For a complete description of all compiler switches given the
> ;; current optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS).
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
> & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>
--
Marco Antoniotti					http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group		tel. +1 - 212 - 998 3488
715 Broadway 10th FL				fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

[Matlisp-users] mk::defsystem problem? Allegro 7.0 trial/MacOSX 10.4

[Harri H. <Har...@tk...>]

Environment: Allegro 7.0 trial/MacOSX 10.4

I have downloaded the latest matlisp via CVS.

I've compiled the libraries with xlf 8.1 and am reasonably confident  
that everything
is OK. Loading fails, however. This looks like a mk::defsystem problem.
(Then again, I'm a newbie, or at least feel like one :-)

;  - Loading defsystem "matlisp"
;    - Loading module "foreign-interface"
Warning: An error occurred
          (No translation rule for #P"matlisp:;src;f77-mangling.lisp")

Harri Hakula
Institute of Mathematics
Helsinki University of Technology

Here is the output from make:
==============================================
~/Desktop/acl70_trial/alisp -e '(progn (load "start.lisp"))'
; Loading /Users/hhakula/Desktop/matlisp/start.lisp
;   Loading /Users/hhakula/Desktop/matlisp/system.dcl
;     Loading /Users/hhakula/Desktop/matlisp/defsystem.lisp
;   Loading /Users/hhakula/Desktop/matlisp/config.lisp

;  - Loading defsystem "matlisp-packages"
;    - Loading binary file "/Users/hhakula/Desktop/matlisp/ 
packages.fasl"
;   Fast loading /Users/hhakula/Desktop/matlisp/packages.fasl
;  - Providing system matlisp-packages

;  - Loading defsystem "lazy-loader"
;    - Loading binary file
;      "/Users/hhakula/Desktop/matlisp/bin/lazy-loader.fasl"
;   Fast loading /Users/hhakula/Desktop/matlisp/bin/lazy-loader.fasl
;     Foreign loading matlisp:lib;libmatlisp.dylib.
;  - Providing system lazy-loader

;  - Loading defsystem "matlisp"
;    - Loading module "foreign-interface"
Warning: An error occurred
          (No translation rule for #P"matlisp:;src;f77-mangling.lisp")
          during the reading or evaluation of -e
          "(progn (load \"start.lisp\"))"
International Allegro CL Trial Edition
7.0 [Mac OS X] (Aug 4, 2005 16:09)
Copyright (C) 1985-2004, Franz Inc., Oakland, CA, USA.  All Rights  
Reserved.

This development copy of Allegro CL is licensed to:
    Harri Hakula, Helsinki University of Technology

;; Optimization settings: safety 1, space 1, speed 1, debug 2.
;; For a complete description of all compiler switches given the
;; current optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS).

[Matlisp-users] Re: Problem with function geev

[Raymond T. <rt...@ea...>]

Paul Ledbetter III wrote:
>>Ah, thanks for digging into this.  A little googling finds the LAPACK
>>FAQ (http://www.netlib.org/lapack/faq.html) which indicates that dlamch
>>(and its dependent routines dlamc[1-5]) should be compiled without
>>optimization?  Can you compile dlamch.f by hand without optimization and
>>see if that makes a difference for you?
>>
>>I'd really appreciate if you could, since I don't seem to have this
>>problem on my linux boxes.
>>
> 
> 
> I recompiled with an unoptimized dlamch and this solved the problem as
> well.  So now we have found multiple ways to solve the problem, and
> this should do well for anyone wanting to use geev.  But in the
> following I argue that we still haven't found the real issue.
> 

[snip nice discussion]

I agree.  We haven't found the real issue.  However, since the LAPACK 
guys didn't change dlamch, I am reluctant to modify it.  Therefore, I 
think the right course is to do what the FAQ suggests and compile dlamch 
without optimization.

Ray

[Matlisp-users] geev left eigenvectors

[Paul L. I. <aea...@gm...>]

Hello, =20
 =20
  I noticed a problem with the geev-workspace-inquiry functions.  It
causes a problem if you do for instance (geev (eye 3) :vv).  This
patch should correct the issue.

Paul

Index: geev.lisp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/matlisp/matlisp/src/geev.lisp,v
retrieving revision 1.10
diff -u -w -r1.10 geev.lisp
--- geev.lisp=0926 Oct 2001 15:24:16 -0000=091.10
+++ geev.lisp=0916 Aug 2005 20:32:41 -0000
@@ -249,7 +249,8 @@
 =09  (:vv (values "V" "V")))
=20
       (let* ((ldvr (if (equal jobvr "V") n 1))
-=09     (xxx (allocate-complex-store ldvr)))
+=09     (ldvl (if (equal jobvl "V") n 1))
+=09     (xxx (allocate-complex-store 1))) ; this is a dummy variable
=20
 =09(multiple-value-bind (store-a store-wr store-wi store-vl store-vr
 =09=09=09=09      work info)
@@ -261,7 +262,7 @@
 =09=09   xxx=09=09=09; WR
 =09=09   xxx=09=09=09; WI
 =09=09   xxx=09=09=09; VL
-=09=09   1=09=09=09; LDVL
+=09=09   ldvl=09=09=09; LDVL
 =09=09   xxx=09=09=09; VR
 =09=09   ldvr=09=09=09; LDVR
 =09=09   work=09=09=09; WORK
@@ -390,7 +391,8 @@
 =09  (:vv (values "V" "V")))
      =20
       (let* ((ldvr (if (equal jobvr "V") n 1))
-=09     (xxx (allocate-complex-store ldvr)))
+=09     (ldvl (if (equal jobvl "V") n 1))
+=09     (xxx (allocate-complex-store 1)))
=20
 =09(multiple-value-bind (store-a store-w store-vl store-vr work info)
 =09    (zgeev jobvl
@@ -400,14 +402,15 @@
 =09=09   n=09=09=09; LDA
 =09=09   xxx=09=09=09; W
 =09=09   xxx=09=09=09; VL
-=09=09   1=09=09=09; LDVL
+=09=09   ldvl=09=09=09; LDVL
 =09=09   xxx=09=09=09; VR
 =09=09   ldvr=09=09=09; LDVR
 =09=09   work=09=09=09; WORK
 =09=09   -1=09=09=09; LWORK
 =09=09   xxx=09=09=09; RWORK
 =09=09   0 )=09=09=09; INFO
-=09  (declare (ignore store-a store-w store-vl store-vr info))
+=09  (declare (ignore store-a store-w store-vl store-vr))
+=09  (assert (zerop info))
 =09  ;; The desired size in in work[0], which we convert to an
 =09  ;; integer.
 =09  (ceiling (aref work 0)))))))