[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