matlisp-users — General discussion list.

Re: [Matlisp-users] m.*! not native?

[Jefferson P. <jp...@cs...>]

On 1/31/02 5:40 PM, "Tunc Simsek" <si...@ee...> wrote:

> what do you mean by native.  both allegro and cmucl produce native code.
> looking at mtimes.lisp; it looks like all the declarations are in place
> for m.*! so the only reason that it may be slow is if the optimization
> flags were not set during compilation.  I personally never checked that
> they are.  It is worth checking this.

Sorry, I misspoke: by native I meant to say implemented in fortran.

Here are the average times of a few operations.

operation  | msecs  (mean of 100 runs)
-----------+---------
(m.*! a b) | 1351.6
(m.+! a b) |    8.6
(m* c d)   |   15.2

A,B = 500x500 real-matrices
C = 500x1 real matrix
D = 1x500 real matrix

(Machine: 1.2GHz Athlon w/ 512M RAM running Allegro 6.0 on Debian Linux)

Jeff

Re: [Matlisp-users] m.*! not native?

[Tunc S. <si...@ee...>]

what do you mean by native.  both allegro and cmucl produce native code.
looking at mtimes.lisp; it looks like all the declarations are in place
for m.*! so the only reason that it may be slow is if the optimization
flags were not set during compilation.  I personally never checked that
they are.  It is worth checking this.

Otherwise, a single loop in lisp with full declarations should not be
orders of magnitude slower than fortran.

 -- Tunc

Jefferson Provost wrote:
> 
> Hi,
> 
> I was profiling some of my code yesterday, and noticed that a single m.*!
> call was taking more than 90% of the run time for my program.  After
> poking around a little in mtimes.lisp, it seems that m.*! isn't native.
> Is this true?
> 
> I don't know BLAS very well.  Is there no way to do element-wise
> multiplication in BLAS?  The non-native routine is a couple of orders of
> magnitude slower than native routines of the same complexity: (e.g. m.+!
> or outer-product of vectors).
> 
> If BLAS can't do this, it seems like it would be an easy Fortran routine
> to write.  I could do it, though I'm not familiar with how to do foreign
> functions in Allegro or cmucl.
> 
> Jeff
> 
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users

[Matlisp-users] m.*! not native?

[Jefferson P. <jp...@cs...>]

Hi,

I was profiling some of my code yesterday, and noticed that a single m.*!
call was taking more than 90% of the run time for my program.  After
poking around a little in mtimes.lisp, it seems that m.*! isn't native.
Is this true?

I don't know BLAS very well.  Is there no way to do element-wise
multiplication in BLAS?  The non-native routine is a couple of orders of
magnitude slower than native routines of the same complexity: (e.g. m.+!
or outer-product of vectors).

If BLAS can't do this, it seems like it would be an easy Fortran routine
to write.  I could do it, though I'm not familiar with how to do foreign
functions in Allegro or cmucl.

Jeff

RE: [Matlisp-users] Problems with ACL 6.0 Trial

[marciot <ma...@la...>]

That fixed it. Works great now! Cool!

Thanks a million!

Marcio Luis Teixeira

>===== Original Message From Tunc Simsek <si...@EE...> =====
>got it.
>
>edit the file src/f77-mangling.lisp (note that this
>file is automatically generated by configure, so if you
>reconfigure in the future you will have to re-edit):
>
>  replace all "_" with ""
>
>Then, erase all .fasl files in the bin directory
>and then go make again and it should work.
>
>It seems that the auto configure utility that tries
>to detect fortran conventions was not tested with ACL.
>
>Good luck,
>Tunc
>
>On Mon, 1 Oct 2001, marciot wrote:
>
>> >How exactly did you install matlisp?  Does it
>> >work if you just do (load "start.lisp") then
>> >the stuff below?
>>
>> I downloaded CVS tree to my home directory,
>> then followed the INSTALL instructions:
>>
>>    ./configure --with-lisp=acl --with-lisp-exec=/usr/local/acl60/alisp
>> -prefix='pwd'
>>
>> Then I did a "make". Alisp loaded and compiled a
>> lot of files. With the exception of some warnings
>> about unreferenced lables, this part seemed to
>> go well.
>>
>> Now, once that is done, I start lisp using:
>>
>> alist -e '(progn (load "start.lisp"))'
>>
>> I then get the error when I try anything. I've attached
>> a "typescript" of my session.
>>
>> BTW, earlier I had indicated I was using the trial
>> edition on Linux. That is my home copy. I haven't
>> tried the CVS version at home yet, but I intend to
>> do so tonight.
>>
>> Right now I am on campus and am using the university's
>> licensed copy of ACL 6.0, on a Solaris box.
>>
>> Marcio Luis Teixeira
>>

RE: [Matlisp-users] Problems with ACL 6.0 Trial

[Tunc S. <si...@EE...>]

Well, the [ ... ] thing is just a macro and does not
use any foreign functions so it will work.
However, do not understand why dcopy is not yet
(or no longer) loaded.

How exactly did you install matlisp?  Does it
work if you just do (load "start.lisp") then
the stuff below?

On Mon, 1 Oct 2001, marciot wrote:

> >All these problems were fixed, however a new release was not
> >made.  You may however, use CVS to checkout the current source files
> >directly from SourceForge.  These sources will work with your
> >Allegro system.
>
> Excellent. This much seems to work. I was able to download, compile
> and install Matlisp. I am now able to create matrices from the
> top-level:
>
> CL-USER(2): (use-package "MATLISP")
> T
> CL-USER(3): [1 2]
> #<REAL-MATRIX  1 x 2
>     1.0000      2.0000     >
> CL-USER(4): (setf a [1 2;3 4])
> #<REAL-MATRIX  2 x 2
>     1.0000      2.0000
>     3.0000      4.0000     >
> CL-USER(5):
>
> But any non-trivial function returns an error:
>
> CL-USER(6): (m+ a a)
> Error: Attempt to call #("dcopy__" 4269187168 0 2 4269187168) for which
>        the definition has not yet been (or is no longer) loaded.
>   [condition type: SIMPLE-ERROR]
>
> Restart actions (select using :continue):
>  0: Return to Top Level (an "abort" restart)
>  1: Abort #<PROCESS Initial Lisp Listener>
> [1] CL-USER(7):
>
> Thank you for the help so far. Any ideas as to what might causing this latter
> problem?
>
> Thank you,
>
> Marcio Luis Teixeira
>
>
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>

RE: [Matlisp-users] Problems with ACL 6.0 Trial

[marciot <ma...@ho...>]

>All these problems were fixed, however a new release was not
>made.  You may however, use CVS to checkout the current source files
>directly from SourceForge.  These sources will work with your
>Allegro system.

Excellent. This much seems to work. I was able to download, compile
and install Matlisp. I am now able to create matrices from the
top-level:

CL-USER(2): (use-package "MATLISP")
T
CL-USER(3): [1 2]
#<REAL-MATRIX  1 x 2
    1.0000      2.0000     >
CL-USER(4): (setf a [1 2;3 4])
#<REAL-MATRIX  2 x 2
    1.0000      2.0000
    3.0000      4.0000     >
CL-USER(5):

But any non-trivial function returns an error:

CL-USER(6): (m+ a a)
Error: Attempt to call #("dcopy__" 4269187168 0 2 4269187168) for which
       the definition has not yet been (or is no longer) loaded.
  [condition type: SIMPLE-ERROR]

Restart actions (select using :continue):
 0: Return to Top Level (an "abort" restart)
 1: Abort #<PROCESS Initial Lisp Listener>
[1] CL-USER(7):

Thank you for the help so far. Any ideas as to what might causing this latter 
problem?

Thank you,

Marcio Luis Teixeira

Re: [Matlisp-users] Problems with ACL 6.0 Trial

[Tunc S. <si...@EE...>]

Hi Marcio;

Matlisp 1.0b doesn't support Allegro 6.0 for a very few reasons.
Although I don't remember all of them the major reason was
because of the version of defsystem.lisp that was distributed
with matlisp 1.0b.

All these problems were fixed, however a new release was not
made.  You may however, use CVS to checkout the current source files
directly from SourceForge.  These sources will work with your
Allegro system.  The only potential problem is that if Allegro trial
version has a memory limit then matlisp may (or may not) try that
limit.

Good luck,
Tunc

On Sun, 30 Sep 2001, Marcio Luis Teixeira wrote:

>
> Hi there,
>
> I was wanting to try out Matlisp using the trial edition of Allegro
> Common Lisp 6.0
> but here is what happens:
>
> CL-USER(1): (load "start.lisp")
> ; Loading /home/marciot/matlisp-1.0b/start.lisp
> ;   Loading /home/marciot/matlisp-1.0b/config.lisp
> ;   Loading /home/marciot/matlisp-1.0b/system.dcl
> Error: No translation rule for #p"matlisp:;code;packages.fasl"
>   [condition type: SIMPLE-ERROR]
>
> I'm fairly new at LISP, so the error message makes no sense to me. Any
> ideas?
>
> Thanks,
>
> Marcio Luis Teixeira
>
>
>
>
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>

[Matlisp-users] Problems with ACL 6.0 Trial

[Marcio L. T. <ma...@ho...>]

Hi there,

I was wanting to try out Matlisp using the trial edition of Allegro
Common Lisp 6.0
but here is what happens:

CL-USER(1): (load "start.lisp")
; Loading /home/marciot/matlisp-1.0b/start.lisp
;   Loading /home/marciot/matlisp-1.0b/config.lisp
;   Loading /home/marciot/matlisp-1.0b/system.dcl
Error: No translation rule for #p"matlisp:;code;packages.fasl"
  [condition type: SIMPLE-ERROR]

I'm fairly new at LISP, so the error message makes no sense to me. Any
ideas?

Thanks,

Marcio Luis Teixeira

Re: [Matlisp-users] Naive installation problems

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

>>>>> "Jacek" == Jacek Generowicz <jm...@ec...> writes:

    Jacek> Raymond Toy writes:
    >> Are you running CMUCL 18c?

    Jacek> Indeedy.

    >> Can you get the current CVS sources?  That should work better.

    Jacek> Seems to have done the trick. I got these warnings, though:

    Jacek>   configure: WARNING: F77 name mangling doesn't match our expectations.
    Jacek>   configure: WARNING: You may need to change some the FFI code.

    Jacek> Is it likely that I have a problem ?

Can you tell me what Fortran compiler you are using?  I must have
either screwed up the logic of the test or the Fortran compiler is
doing something weird.

Ray

Re: [Matlisp-users] Bug in mref ?

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

>>>>> "Jacek" == Jacek Generowicz <jm...@ec...> writes:

    Jacek> Here's a transcript of a little exchange I just had with matlisp in
    Jacek> CMUCL. 

Thanks.  Your solution is the right one and I'll be committing the
change soon.

Ray

[Matlisp-users] Bug in mref ?

[Jacek G. <jm...@ec...>]

Here's a transcript of a little exchange I just had with matlisp in
CMUCL. 

(The matlisp was checked out from CVS within the last couple of
hours).

Jacek.

----------------------------------------------------------------------

* (setq the-matrix (make-real-matrix '((1 2 3) (4 5 6))))
#<REAL-MATRIX  2 x 3
    1.0000      2.0000      3.0000     
    4.0000      5.0000      6.0000     >
* (matrix-ref the-matrix 1 1)
5.0d0
* (help mref)

In package MATLISP, the function MREF
=====================================
Same as MATRIX-REF
* (mref the-matrix 1 1)

Invalid number of arguments: 3

Restarts:
  0: [ABORT] Return to Top-Level.

Debug  (type H for help)

(MREF 3
      #<REAL-MATRIX  2 x 3
    1.0000      2.0000      3.0000     
    4.0000      5.0000      6.0000     >
      1)[:EXTERNAL]
Source: 
; File: /usr/local/src/matlisp-cvs/src/compat.lisp
(DEFUN MREF (I &OPTIONAL J)
  "Same as MATRIX-REF"
  (IF J (MATRIX-REF M I J) (MATRIX-REF M I)))
0] (defun mref (m i &optional j)
      (if j (matrix-ref m i j) 
     (matrix-ref m i)))
Converted MREF.
MREF
0] 0
* (mref the-matrix 1 1)
5.0d0

Re: [Matlisp-users] Naive installation problems

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

>>>>> "Jacek" == Jacek Generowicz <jm...@ec...> writes:

    Jacek> Raymond Toy writes:
    >> Are you running CMUCL 18c?

    Jacek> Indeedy.

    >> Can you get the current CVS sources?  That should work better.

    Jacek> Seems to have done the trick. I got these warnings, though:

    Jacek>   configure: WARNING: F77 name mangling doesn't match our expectations.
    Jacek>   configure: WARNING: You may need to change some the FFI code.

    Jacek> Is it likely that I have a problem ?

Yes, but since you're running 18c, that means x86 or sparc, so you can
ignore the warning.  It must be some error in the config script.  I'll
check into it.

Ray

Re: [Matlisp-users] Naive installation problems

[Jacek G. <jm...@ec...>]

Raymond Toy writes:
> Are you running CMUCL 18c?

Indeedy.

> Can you get the current CVS sources?  That should work better.

Seems to have done the trick. I got these warnings, though:

  configure: WARNING: F77 name mangling doesn't match our expectations.
  configure: WARNING: You may need to change some the FFI code.

Is it likely that I have a problem ?

Re: [Matlisp-users] Naive installation problems

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

> X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to to...@rt... using -f
> Cc: mat...@li...
> From: Raymond Toy <to...@rt...>
> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise)
> Content-Type: text/plain; charset=us-ascii
> Sender: mat...@li...
> X-BeenThere: mat...@li...
> X-Mailman-Version: 2.0.5
> Precedence: bulk
> List-Help: <mailto:mat...@li...?subject=help>
> List-Post: <mailto:mat...@li...>
> List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/matlisp-users>,
> 	<mailto:mat...@li...?subject=subscribe>
> List-Id: Matlisp users mailing list. <matlisp-users.lists.sourceforge.net>
> List-Unsubscribe: <http://lists.sourceforge.net/lists/listinfo/matlisp-users>,
> 	<mailto:mat...@li...?subject=unsubscribe>
> List-Archive: <http://lists.sourceforge.net/archives//matlisp-users/>
> Date: 23 Jul 2001 09:01:53 -0400
> Content-Length: 900
> 
> >>>>> "Jacek" == Jacek Generowicz <jm...@ec...> writes:
> 
>     Jacek> Greetings,
>     Jacek> I have been trying to compile matlisp (on a SuSE 7.1 system) for
>     Jacek> integration with CMUCL.
> 
>     Jacek> Having set the cmu-lisp varialble in the makefile, and issued `make
>     Jacek> cmu', the installation runs into a problem, which as a comparative
>     Jacek> lisp novice, leaves me stumped.
> 
>     Jacek> I'd appreciate a prod in the right direction.
> 
>     Jacek> Error message included below . . .
> 
> Are you running CMUCL 18c?  I believe this is a "bug" introduced in
> 18c but the 1.0b defsystem doesn't have the fix.

The problem may be that the DEFSYSTEM distributed with matlisp is not
synchronized with the last official one out of CLOCC.

Cheers


-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.

Re: [Matlisp-users] Naive installation problems

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

>>>>> "Jacek" == Jacek Generowicz <jm...@ec...> writes:

    Jacek> Greetings,
    Jacek> I have been trying to compile matlisp (on a SuSE 7.1 system) for
    Jacek> integration with CMUCL.

    Jacek> Having set the cmu-lisp varialble in the makefile, and issued `make
    Jacek> cmu', the installation runs into a problem, which as a comparative
    Jacek> lisp novice, leaves me stumped.

    Jacek> I'd appreciate a prod in the right direction.

    Jacek> Error message included below . . .

Are you running CMUCL 18c?  I believe this is a "bug" introduced in
18c but the 1.0b defsystem doesn't have the fix.

Can you get the current CVS sources?  That should work better.  If
not, a new release is coming soon.

Ray

[Matlisp-users] Naive installation problems

[Jacek G. <jm...@ec...>]

Greetings,

I have been trying to compile matlisp (on a SuSE 7.1 system) for
integration with CMUCL.

Having set the cmu-lisp varialble in the makefile, and issued `make
cmu', the installation runs into a problem, which as a comparative
lisp novice, leaves me stumped.

I'd appreciate a prod in the right direction.

Error message included below . . .

Thanks,

Jacek

----------------------------------------------------------------

/usr/local/bin/cmucl -eval '(progn (load "start.lisp"))'
; Loading #p"/usr/local/src/matlisp-1.0b/start.lisp".
;; Loading #p"/usr/local/src/matlisp-1.0b/config.lisp".
;; Loading #p"/usr/local/src/matlisp-1.0b/system.dcl".
;;; Loading #p"/usr/local/src/matlisp-1.0b/packages.lisp".
;;; Loading #p"/usr/local/src/matlisp-1.0b/packages.lisp".
;;; Loading #p"/usr/local/src/matlisp-1.0b/packages.lisp".
;;; Loading #p"/usr/local/src/matlisp-1.0b/packages.lisp".
;;; Loading #p"/usr/local/src/matlisp-1.0b/packages.lisp".
;;; Loading #p"/usr/local/src/matlisp-1.0b/defsystem.lisp".

In: LAMBDA (FILENAME &REST ARGS &KEY OUTPUT-FILE ...)
  #'(LAMBDA (FILENAME &REST ARGS &KEY OUTPUT-FILE ...)
      (DECLARE (IGNORE ARGS))
      (BLOCK C-COMPILE-FILE (RUN-UNIX-PROGRAM *C-COMPILER* `#)))
Note: Variable ERROR-FILE defined but never used.

Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
   #() is not of type (OR CONS
                          BASE-STRING
                          (MEMBER NIL :UNSPECIFIC :WILD)
                          COMMON-LISP::PATTERN)

Restarts:
  0: [CONTINUE] Return NIL from load of "matlisp:system.dcl".
  1:            Return NIL from load of "start.lisp".
  2: [ABORT   ] Skip remaining initializations.

Debug  (type H for help)

("DEFUN MAKE-PATHNAME" 268433182 8)[:OPTIONAL]
Source: 
; File: target:code/pathname.lisp
(DEFUN MAKE-PATHNAME
       (&KEY HOST (DEVICE # DEVP) (DIRECTORY # DIRP) (NAME # NAMEP) ...)
  "Makes a new pathname from the component arguments.  Note that host is
a host-structure or string."
  (DECLARE (TYPE # HOST)
           (TYPE # DEVICE)
           (TYPE # DIRECTORY)
           (TYPE # NAME TYPE)
           ...)
  ...)
0] 

Re: [Matlisp-users] Combination with ordinary arrays

[Tunc S. <si...@ro...>]

Nicolas;

Matlisp functions work on matrices.  So you need to
make a matrix out of your vector.  You can do so
using:

	(make-real-matrix <your-vector>)

or

	(make-complex-matrix <your-vector>)

Good luck,
Tunc

On 8 May 2001, Nicolas Neuss wrote:

> Hello, matlisp-team (and/or other users).
>
> First, I would like to say that matlisp helps me quite a lot.  Thank
> you.  Next, I have the following question: how does one do the
> interaction with usual arrays in the best way.  E.g., is it possible
> to have matlisp matrices operating as linear operators on ordinary
> uniform double-float vectors?  Or is it necessary to construct matlisp
> nx1-matrices for those vectors instead?  What do you recommend?
>
> Yours, Nicolas.
>
>
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> http://lists.sourceforge.net/lists/listinfo/matlisp-users
>

[Matlisp-users] Combination with ordinary arrays

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

Hello, matlisp-team (and/or other users).

First, I would like to say that matlisp helps me quite a lot.  Thank
you.  Next, I have the following question: how does one do the
interaction with usual arrays in the best way.  E.g., is it possible
to have matlisp matrices operating as linear operators on ordinary
uniform double-float vectors?  Or is it necessary to construct matlisp
nx1-matrices for those vectors instead?  What do you recommend?

Yours, Nicolas.

Re: [Matlisp-users] Need help w/ computing sums

[Tunc S. <si...@ro...>]

Hmm, that looks like a windowed fft. If that's the
case you may want to try (HELP FFT)

Richard James Panturis Giuly wrote:
> 
> Is there a good way to compute the following for a large matrix?
> 
> (v's are column vectors of V, u's are vectors of U)
> 
> I need the value of each line; I'm sort of dragging one matrix over
> the other (horizontally) and adding the elements of the parts that
> touch.
> 
> [v3] + [u1]
> 
> [v2 v3] + [u1 u2]
> 
> [v1 v2 v3] + [u1 u2 u3]
> 
> [v1 v2] + [u2 u3]
> 
> [v1] + [u3]
> 

I'm guessing that the intermediary results form another array of
length 2n-1.  I can't see any immediate way of doing this using
the higher level matlisp interfaces.  But you may be able to
do something clever with the direct interfaces.  Try (HELP BLAS)
and (HELP LAPACK).

Regards,
Tunc


> 
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> http://lists.sourceforge.net/mailman/listinfo/matlisp-users

[Matlisp-users] Need help w/ computing sums

[Richard J. P. G. <rg...@bi...>]

Is there a good way to compute the following for a large matrix?

(v's are column vectors of V, u's are vectors of U)

I need the value of each line; I'm sort of dragging one matrix over
the other (horizontally) and adding the elements of the parts that
touch.

[v3] + [u1]

[v2 v3] + [u1 u2]

[v1 v2 v3] + [u1 u2 u3]

[v1 v2] + [u2 u3]

[v1] + [u3]

   

[Matlisp-users] Re: Problem with matlisp:map-matrix!

[Tunc S. <si...@ro...>]

I'm cc'ing my reply to matlisp-users so that this gets archived.

ps. You may try sending matlisp specific messages to matlisp-users
or reporting bugs from the matlisp homepage:

	mat...@us...
	http://matlisp.sourceforge.net

I found another bug recently with map-matrix and reported that
to the bug list, I'm surprised you didn't get that error:

1. in some platforms (at least on my solaris, with CMU), map-matrix
  expects a compiled function (an interpreted function is not
specialized
	correctly)
2. in your case, map-matrix is (SETF (AREF ...) (FUNCALL ..)) where the
array is double-float, so the error is coming from there.  As a
temporary
fix, you can edit the file src/map.lisp and replace:

	(AREF STORE K) with (MATRIX-REF MAT K)

or 

	replace (FUNCALL ..) with (COERCE (FUNCALL ..)
'real-matrix-element-type)

1 or the other, but both is not needed since MATRIX-REF will coerce as
needed.

Good luck,
Tunc


Richard James Panturis Giuly wrote:
> 
> I'm having trouble using the map-matrix function of matlisp. I
> keep getting the error "Attempt to store the wrong type of a
> value in an array."
> 
> This works fine:
> (setq m (matlisp:make-real-matrix  3 3))
> 
> So does this:
> (matlisp:map-matrix! #'+ m)
> 
> But this does not:
> (matlisp:map-matrix! #'(lambda (dummy) 1) m)
> Error: Attempt to store the wrong type of a value in an array.
>   [condition type: SIMPLE-ERROR]
> 
> (using Franz ACL on Linux)
> 
> any help is appreciated
> 
> --
>         ricky
>         rg...@su...

[Matlisp-users] matlisp comments

[Tunc S. <si...@ro...>]

Thanks Wheeler,

I am forwarding your message together with my reply to the matlisp
mailing list mat...@us... so that it gets 
archived.


Wheeler Ruml wrote:
> 
> Thanks very much for making the matlisp package available!  I have
> been using an adhoc colleciton of interfaces, and matlisp is so much
> cleaner...
> 
> I didn't know how to pass along suggestions for future improvements,
> so I thought I'd email you directly.  (I tried posting in a discussion
> forum at sourceforge, but they didn't exactly seem active.)
> 
> --
> Wheeler Ruml, http://www.eecs.harvard.edu/~ruml/, 617/495-2081 voice
> ru...@ee..., Maxwell Dworkin Lab 219    617/496-1066 fax
> -------------------Possible improvements to distribution
> -----------------------------
> 
> write a document to explain design rationale, to avoid naive questions
>    from users about why things were coded this way.
> 

well, this was in the plan, sometime, somewhere.  I guess what the
user really needs to know, as you suggest, is the very basic
*rationale*.
For example, storage, class names etc ...  Otherwise, the function HELP
will give you the specific help on a particular generic function (for
example,
try (HELP SVD) or (HELP dgemm) or (HELP gemm))

> use 2-d lisp arrays for matrix store, rather than 1d
>    this allows using aref to manipulate matrices easily in Lisp
>      (just need a macro to reverse indices, and a separate macro for
>       complex matrices)

well, this is to make interfacing to the *fortran* code easier, which
stores matrices contiguously.

>    need function to make matrix from a given store (user might not
>       want to have new storage allocated)

I think you can already do that:

 (help make-real-matrix-array)
 
 
In package MATLISP, the function MAKE-REAL-MATRIX-ARRAY
=======================================================
 
  Syntax
  ======
  (MAKE-REAL-MATRIX-ARRAY array)
 
  Purpose
  =======
  Creates a REAL-MATRIX with the same contents as ARRAY.
 



> 
> config.lisp changes some global special variables!
>    in general, distribution should not assume it owns the lisp.
>    it should be easier to just load it as a system component, without
>       getting banners printed...

Agreed, we were planning on getting rid of config.  But, right you
should
be able to remove (load "matlisp:config") from start.lisp without any
damage.

> 
> README
>   explain where to get prebuilt BLAS and LAPACK libraries
>   explain where to send bug reports and feature suggestions
>   document use of , in []
>   list of functions incomplete
> 
> dec make doesn't work (requires GNU make)

Does it work with GNU make? Is that the only problem?

> 
> linking doesn't go through on alpha

Hmm! I'm not sure if I have an alpha around, I'll check to see what the
problem is.

> 
> needs centralized documentation so one doesn't have to browse the code

In principle, HELP should do the trick most of the time.  Try (HELP
MATLISP).

> 
> ask Franz if they want to donate the documentation from their defunct
>    Allegro Matrix product (which was a ffi to lapack, I think).
> 

I haven't heard of this product and can't seem to fine it on their
homepage.

> separate into 3 levels:
>    ffi definitions - like it is now
>    wrapper to deal with argument processing - a little simpler than
>       current matlisp functions, exposing all lapack flags.  (Eg,
>       expert user might want to call gemm with transpose flag set.)
>    easy-to-use-with-long-names - with minimal arguments to avoid
>      confusing users.  Eg, singular-values and svd would be separate
>      functions rather than :job keyword arg.
>    in general, it would be nice if there were two levels of matlisp -
>       one for naive users who won't really be coding in lisp much, and
>       another for those who will.
> 
> have printed matrices be readable

How do you mean?  The reason why its unreadable is because you can test
matrix
equality with EQ (at least my weak notion of many Lisp concepts tells me
that).
Perhaps if you elaborate we can think of this.

> 
> separate out the FFI part and document it well, so it can be used in
>    other efforts to integrate fortran code with Lisp.

I though that this was the case.  At least for me, all I had to do was
basically
create a new file ffi-acl.lisp (similar to ffi-cmu.lisp) to port to
Allegro
(Plus a few CMU specific things in other parts of the code).

> 
> put links on web page to other numerical lisp code

This is in the plan.

> 
> how to integrate MINPACK and other numerical packages?
>    keep separate?

Well, the problem with incorporating more and more packages is:

[1] There needs to be an insentive.  I wouldn't add packages for the fun
of it.
[2] Its not clear that many xxxPACK's are still high tech (for example,
with optimization
   new techniques are coming out every day).  However, BLAS and LAPACK
are fairly stable,
   compile almost everywhere and their replacements (ATLAS etc ...) are
almost fully compatible.
[3] I had bad experience with DFFTPACK which compiled but gave
undiagnosable errors on some
    machines.  I could not reproduce the problem so I cannot elaborate.
[4] Writing an interface to such a package is tough and needs to be well
thought out.
[5] The main reason to build matlisp is not a replacement for say
octave,rlab or matlab.
   Instead, you can write *good* programs that can incorporate *precise*
matric operations.
   For example, here is a piece of code from Lambda-SHIFT:

 
(defhybrid vehicle-to-environment-processor ()
  ((model
          :initarg :model
	  :documentation "\
Some model that is assumed to have accessors called 
ANGULAR-VELOCITY and VELOCITY, both of which should be 
3D vectors in body coordinate frames.

No default initializer to ensure an error if not 
initialized on creation.
")
   (angular-position := [0 0 0]')
   (global-position := [0 0 0]'
		    :initarg :global-position
		    :reader global-position
		    :documentation "A 3D vector. The global position of MODEL.")
   (global-velocity := [0 0 0]'
		    :initarg :global-velocity
		    :reader global-velocity
		    :documentation "A 3D vector. The global velocity of MODEL.")
   (rotation-matrix :documentation "See SO3.")
   (jacobian-angles :documentation "See JACOBIAN3."))
  (:discrete
   ('default
     :flow ((<- rotation-matrix (so3 angular-position))
	    (<- jacobian-angles (jacobian3 angular-position))
	    (d/dt global-position (gemm! 1.0d0 
                                         rotation-matrix
                                         (velocity model)
                                         0.0d0
                                         global-position))
	    (d/dt angular-position (gemm! 1.0d0
					  jacobian-angles
					  (angular-velocity model)
					  0.0d0
					  angular-position))))))
  

Notice the use of GEMM! to save memory (something you could possibly not
do in matlab, octave or rlab).


> 
> 
> # EOF
Thanks for the comments, and hopefully, now that they are recorded in
the
mail archive they will be treated.

Regards,
Tunc

[Matlisp-users] Allegro port of matlisp

[Tunc S. <si...@ro...>]

Regards,

I have an Allegro port of Matlisp (currently Unix and Linux for v5.x).
I had trouble with the WinNT v5.02 port.

In particular, I can't get Allegro to load blas and lapack dll's.
I got some precompiled blas and lapack dll's from:

 http://www.che.chalmers.se/~agris/Programming/clapack/clapack.html -->
archive

and did (load "blas.dll") and (load "lapack.dll").
The first worked but the second failed without much indications.

Any help would be appreciated.

Thanks,
Tunc

p.s. I'm forwarding a copy of this message to c.l.l, in hope that
someone has had previous experience.

Re: [Matlisp-users] clisp port

[Tunc S. <si...@ro...>]

a) I'm trying to do the port, but I need help from
   the CLISP people.  Hopefully if they can give me hand 
   with the CLISP FFI I'll have it done in a jiffy.

b) No, I don't know how that would be done, would you suggest how that
would be done?  What aspect of the port would you test:

	i) that the fortran code is doing the right thing
	ii) that lisp is doing the right thing?

Thanks,
Tunc

On Wed, 28 Jun 2000, [iso-8859-1] Bjørn Remseth wrote:

> 
> a) Is anyone actively working on a clisp port now?
> b) Is there a test-suite with regression tests
>    to check if a port is behaving correctly?
> 
> 						(Rmz)
> 
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> http://lists.sourceforge.net/mailman/listinfo/matlisp-users
> 

[Matlisp-users] clisp port

[<rm...@du...>]

a) Is anyone actively working on a clisp port now?
b) Is there a test-suite with regression tests
   to check if a port is behaving correctly?

						(Rmz)