matlisp-users — General discussion list.

Re: [Matlisp-users] anyone compiled matlisp on OSX?

[<os...@ka...>]

Hello Cyrus,

and many thanks for helping me out. First of all, I'm using OSX on PPC=20
currently.

In fact, yesterday I managed to get an almost working compilation of=20
matlisp, using the g95 compiler and matlisp leeched from CVS. With=20
'almost working' I mean that at least compiling the shared libraries=20
with fortran compiler didn't fail, but instead, while running 'make' or=20
cmucl -eval '(load "start.lisp")', I got output as at the end of this mai=
l.

I get arbitrarily many errors like the following
Undefined foreign symbol: 96470128
    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]

And regarding which Fortran compiler to use... I used g95 because it at=20
least seemed to be able to build the lib/libmatlisp.so package. With=20
gfortran, I have to hack matlisp.mk a bit (MATLIB variable points to=20
directory, -lf2c in compiler flags etc), make -f matlisp.mk ends up with

;;; Opening shared library=20
/Users/ossi/installers/sf/matlisp/lib/libmatlisp.so ...


Error in function SYSTEM::LOAD-OBJECT-FILE:
    Can't open object=20
#P"/Users/ossi/installers/sf/matlisp/lib/libmatlisp.so":=20
"/Users/ossi/installers/sf/matlisp/lib/libmatlisp.so in Symbol not=20
found: __gfortran_transfer_character
   Referenced from: /Users/ossi/installers/sf/matlisp/lib/libmatlisp.so
   Expected in: flat namespace
: 4 0"
    [Condition of type SIMPLE-ERROR]


Anyway, I'm a bit too n00b to troubleshoot problems related to both=20
fortran compiler/ linker errors and Lisp FFI errors...

Cyrus, which gfortran, matlisp, and cmucl versions are you exactly=20
using? 'configure' script options, compiler / linker flags, etc?

best regards,
Ossi




pupu:~/installers/sf/matlisp ossi$ make
make -f matlisp.mk
=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
Required fortran libraries have been built.
The following statement will sometimes fail.
If it fails, manually start your lisp and
load the file start.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
/opt/cmu/bin/lisp -noinit -eval '(progn (load "start.lisp"))'
; Loading #P"/Users/ossi/installers/sf/matlisp/start.lisp".
; Converted SETLOGICALROOT.
; Converted GETLOGICALROOT.
; Converted DEFLOGICALPATH.
;; Loading #P"/Users/ossi/installers/sf/matlisp/system.dcl".
;;; Loading #P"/Users/ossi/installers/sf/matlisp/defsystem.lisp".
Warning:  Old-style IN-PACKAGE.
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJECT STREAM):
; Compiling Top-Level Form:
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X):
; Compiling Top-Level Form:
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X):
; Compiling Top-Level Form:
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJECT STREAM):
; Compiling Top-Level Form:
; Converted COMPILED-FILE-P.

; In: DEFUN COMPILED-FILE-P

;   (DEFUN COMPILED-FILE-P (FILE-NAME)
;     "Return T if the FILE-NAME is a filename designator for a valid=20
compiled.
; Signal an error when it is not a filename designator.
; Return NIL when the file does not exist, or is not readable,
; or does not contain valid compiled code." ..)
; Note: Variable FILE-NAME defined but never used.
;; Loading #P"/Users/ossi/installers/sf/matlisp/config.lisp".
; [GC threshold exceeded with 12,838,184 bytes in use.  Commencing GC.]
; [GC completed with 4,738,696 bytes retained and 8,099,488 bytes freed.]
; [GC will next occur when at least 16,738,696 bytes are in use.]

;  - Loading defsystem "matlisp-packages"
;    - Loading binary file=20
"/Users/ossi/installers/sf/matlisp/packages.ppcf"
;; Loading #P"/Users/ossi/installers/sf/matlisp/packages.ppcf".
;  - Providing system matlisp-packages

;  - Loading defsystem "lazy-loader"
;    - Loading binary file
;      "/Users/ossi/installers/sf/matlisp/bin/lazy-loader.ppcf"

Error in function LISP::INTERNAL-LOAD:
    File has a fasl file type, but no fasl file header:
   "/Users/ossi/installers/sf/matlisp/bin/lazy-loader.ppcf"
    [Condition of type SIMPLE-ERROR]

Restarts:
   0: [CONTINUE] Load it as a source file.
   1:            Return NIL from load of=20
"/Users/ossi/installers/sf/matlisp/bin/lazy-loader.ppcf".
   2:            Return NIL from load of "start.lisp".
   3: [ABORT   ] Skip remaining initializations.

Debug  (type H for help)

(LISP::INTERNAL-LOAD=20
#P"/Users/ossi/installers/sf/matlisp/bin/lazy-loader.ppcf"
=20
#P"/Users/ossi/installers/sf/matlisp/bin/lazy-loader.ppcf"
                      :ERROR NIL)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer=20
exists:
   target:code/load.lisp.
0] 0

;; Loading #P"/Users/ossi/installers/sf/matlisp/bin/lazy-loader.ppcf".
;  - Providing system lazy-loader

;  - Loading defsystem "matlisp"
;    - Loading module "foreign-interface"
;      - Loading binary file
;        "/Users/ossi/installers/sf/matlisp/bin/f77-mangling.ppcf"
;; Loading #P"/Users/ossi/installers/sf/matlisp/bin/f77-mangling.ppcf".

;      - Loading binary file
;        "/Users/ossi/installers/sf/matlisp/bin/ffi-cmu.ppcf"
;; Loading #P"/Users/ossi/installers/sf/matlisp/bin/ffi-cmu.ppcf".

;    - Loading module "foreign-functions"
;      - Loading binary file=20
"/Users/ossi/installers/sf/matlisp/bin/blas.ppcf"
;; Loading #P"/Users/ossi/installers/sf/matlisp/bin/blas.ppcf".


Undefined foreign symbol: 96470128
    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]

Restarts:
   0: [CONTINUE] Return NIL from load of=20
"/Users/ossi/installers/sf/matlisp/bin/blas.ppcf".
   1:            Return NIL from load of "start.lisp".
   2: [ABORT   ] Skip remaining initializations.

Debug  (type H for help)

("Bogus stack frame")
0]


Cyrus Harmon wrote:
> Hi Ossi,
>=20
> i've used matlisp on OSX for both PPC and Intel. Not sure what the=20
> problem is, but I can help you get to the bottom of this. PPC or Intel?
>=20
> I'm guessing ppc and g95, from the looks of things.
>=20
> I use gfortran from Simon Urbanek. Dig around here:
>=20
> http://wiki.urbanek.info/index.cgi?HomePage
>=20
> Good luck,
>=20
> Cyrus
>=20
> On Apr 23, 2006, at 5:15 AM, Ossi V=E4=E4n=E4nen wrote:
>=20
>> Hello!
>>
>> I'm trying to compile matlisp on Mac OS X, but without too much=20
>> success...
>>
>> First question, which is the way to get a bunch of working sources? It=
=20
>> seems there are three approaches
>> 1. get matlisp-1.0b release, and try to configure using config* from=20
>> /usr/share/automake-1.6, since the 1.0b release doesn't come with=20
>> autoconf support for darwin
>> 2. get the last matlisp2 beta, which is a couple years old
>> 3. get matlisp from CVS
>>
>> Well, 1. and 2. fails when trying to compile the libmatlisp shared=20
>> library:
>> ld: Undefined symbols:
>> dyld_stub_binding_helper
>> ___fixdfdi
>> ___fixsfdi
>> restFP
>> saveFP
>> ___udivdi3
>> ___divdi3
>> ___moddi3
>> ___umoddi3
>> ___ashldi3
>> ___lshrdi3
>> make[1]: *** [lib/libmatlisp.so] Error 1
>> make: *** [all] Error 2
>>
>>
>> 3. fails too, it is possible to compile the libmatlisp.so on OSX, see=20
>> the longish copy-paste below.
>>
>> I'm using g95 to compile the shared libraries, with F77 and FCC=20
>> environment variables set to g95. Tried with gfortran as well, but ran=
=20
>> into lots of linking problems.
>>
>> Any help would be appreciated.
>>
>> pupu:~/installers/sf/matlisp ossi$ make
>> make -f matlisp.mk
>> =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
>> Required fortran libraries have been built.
>> The following statement will sometimes fail.
>> If it fails, manually start your lisp and
>> load the file start.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
>> /Applications/acl80/alisp8 -e '(progn (load "start.lisp"))'
>> ; Loading /Users/ossi/installers/sf/matlisp/start.lisp
>> ;   Loading /Users/ossi/installers/sf/matlisp/system.dcl
>> ;     Loading /Users/ossi/installers/sf/matlisp/defsystem.lisp
>> ;   Loading /Users/ossi/installers/sf/matlisp/config.lisp
>>
>> ;  - Loading defsystem "matlisp-packages"
>> ;    - Loading binary file=20
>> "/Users/ossi/installers/sf/matlisp/packages.fasl"
>> ;   Fast loading /Users/ossi/installers/sf/matlisp/packages.fasl
>> ;  - Providing system matlisp-packages
>>
>> ;  - Loading defsystem "lazy-loader"
>> ;    - Compiling source file
>> ;      "/Users/ossi/installers/sf/matlisp/lib/lazy-loader.lisp"
>> ;;; Compiling file
>> ;;;   /Users/ossi/installers/sf/matlisp/lib/lazy-loader.lisp
>> ;   Loading matlisp:lib;libmatlisp.so
>> ;      (/Users/ossi/installers/sf/matlisp/lib/libmatlisp.so)
>> ; While compiling (:TOP-LEVEL-FORM "lazy-loader.lisp" 4726):
>> Warning: An error occurred
>>          (Can't have unescaped whitespace in token. [file position =3D
>>           16])
>>          during the reading or evaluation of -e
>>          "(progn (load \"start.lisp\"))"
>> Allegro CL Professional Edition
>> 8.0 [Mac OS X] (Dec 30, 2005 9:49)
>> Copyright (C) 1985-2005, Franz Inc., Oakland, CA, USA.  All Rights=20
>> Reserved.
>>
>> This development copy of Allegro CL is licensed to:
>>    [TC13706] University of Oulu
>>
>> ;; 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).
>> CL-USER(1):
>>
>>
>>
>>
>>
>> - osku
>>
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, securi=
ty?
>> Get stuff done quickly with pre-integrated technology to make your job=
=20
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache=20
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
>> _______________________________________________
>> Matlisp-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>=20

Re: [Matlisp-users] anyone compiled matlisp on OSX?

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

Hi Ossi,

i've used matlisp on OSX for both PPC and Intel. Not sure what the =20
problem is, but I can help you get to the bottom of this. PPC or Intel?

I'm guessing ppc and g95, from the looks of things.

I use gfortran from Simon Urbanek. Dig around here:

http://wiki.urbanek.info/index.cgi?HomePage

Good luck,

Cyrus

On Apr 23, 2006, at 5:15 AM, Ossi V=E4=E4n=E4nen wrote:

> Hello!
>
> I'm trying to compile matlisp on Mac OS X, but without too much =20
> success...
>
> First question, which is the way to get a bunch of working sources? =20=

> It seems there are three approaches
> 1. get matlisp-1.0b release, and try to configure using config* =20
> from /usr/share/automake-1.6, since the 1.0b release doesn't come =20
> with autoconf support for darwin
> 2. get the last matlisp2 beta, which is a couple years old
> 3. get matlisp from CVS
>
> Well, 1. and 2. fails when trying to compile the libmatlisp shared =20
> library:
> ld: Undefined symbols:
> dyld_stub_binding_helper
> ___fixdfdi
> ___fixsfdi
> restFP
> saveFP
> ___udivdi3
> ___divdi3
> ___moddi3
> ___umoddi3
> ___ashldi3
> ___lshrdi3
> make[1]: *** [lib/libmatlisp.so] Error 1
> make: *** [all] Error 2
>
>
> 3. fails too, it is possible to compile the libmatlisp.so on OSX, =20
> see the longish copy-paste below.
>
> I'm using g95 to compile the shared libraries, with F77 and FCC =20
> environment variables set to g95. Tried with gfortran as well, but =20
> ran into lots of linking problems.
>
> Any help would be appreciated.
>
> pupu:~/installers/sf/matlisp ossi$ make
> make -f matlisp.mk
> =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
> Required fortran libraries have been built.
> The following statement will sometimes fail.
> If it fails, manually start your lisp and
> load the file start.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
> /Applications/acl80/alisp8 -e '(progn (load "start.lisp"))'
> ; Loading /Users/ossi/installers/sf/matlisp/start.lisp
> ;   Loading /Users/ossi/installers/sf/matlisp/system.dcl
> ;     Loading /Users/ossi/installers/sf/matlisp/defsystem.lisp
> ;   Loading /Users/ossi/installers/sf/matlisp/config.lisp
>
> ;  - Loading defsystem "matlisp-packages"
> ;    - Loading binary file "/Users/ossi/installers/sf/matlisp/=20
> packages.fasl"
> ;   Fast loading /Users/ossi/installers/sf/matlisp/packages.fasl
> ;  - Providing system matlisp-packages
>
> ;  - Loading defsystem "lazy-loader"
> ;    - Compiling source file
> ;      "/Users/ossi/installers/sf/matlisp/lib/lazy-loader.lisp"
> ;;; Compiling file
> ;;;   /Users/ossi/installers/sf/matlisp/lib/lazy-loader.lisp
> ;   Loading matlisp:lib;libmatlisp.so
> ;      (/Users/ossi/installers/sf/matlisp/lib/libmatlisp.so)
> ; While compiling (:TOP-LEVEL-FORM "lazy-loader.lisp" 4726):
> Warning: An error occurred
>          (Can't have unescaped whitespace in token. [file position =3D
>           16])
>          during the reading or evaluation of -e
>          "(progn (load \"start.lisp\"))"
> Allegro CL Professional Edition
> 8.0 [Mac OS X] (Dec 30, 2005 9:49)
> Copyright (C) 1985-2005, Franz Inc., Oakland, CA, USA.  All Rights =20
> Reserved.
>
> This development copy of Allegro CL is licensed to:
>    [TC13706] University of Oulu
>
> ;; 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).
> CL-USER(1):
>
>
>
>
>
> - osku
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users

[Matlisp-users] anyone compiled matlisp on OSX?

[<os...@ka...>]

Hello!

I'm trying to compile matlisp on Mac OS X, but without too much success...

First question, which is the way to get a bunch of working sources? It 
seems there are three approaches
1. get matlisp-1.0b release, and try to configure using config* from 
/usr/share/automake-1.6, since the 1.0b release doesn't come with 
autoconf support for darwin
2. get the last matlisp2 beta, which is a couple years old
3. get matlisp from CVS

Well, 1. and 2. fails when trying to compile the libmatlisp shared library:
ld: Undefined symbols:
dyld_stub_binding_helper
___fixdfdi
___fixsfdi
restFP
saveFP
___udivdi3
___divdi3
___moddi3
___umoddi3
___ashldi3
___lshrdi3
make[1]: *** [lib/libmatlisp.so] Error 1
make: *** [all] Error 2


3. fails too, it is possible to compile the libmatlisp.so on OSX, see 
the longish copy-paste below.

I'm using g95 to compile the shared libraries, with F77 and FCC 
environment variables set to g95. Tried with gfortran as well, but ran 
into lots of linking problems.

Any help would be appreciated.

pupu:~/installers/sf/matlisp ossi$ make
make -f matlisp.mk
===============================================
Required fortran libraries have been built.
The following statement will sometimes fail.
If it fails, manually start your lisp and
load the file start.lisp.

==============================================
/Applications/acl80/alisp8 -e '(progn (load "start.lisp"))'
; Loading /Users/ossi/installers/sf/matlisp/start.lisp
;   Loading /Users/ossi/installers/sf/matlisp/system.dcl
;     Loading /Users/ossi/installers/sf/matlisp/defsystem.lisp
;   Loading /Users/ossi/installers/sf/matlisp/config.lisp

;  - Loading defsystem "matlisp-packages"
;    - Loading binary file 
"/Users/ossi/installers/sf/matlisp/packages.fasl"
;   Fast loading /Users/ossi/installers/sf/matlisp/packages.fasl
;  - Providing system matlisp-packages

;  - Loading defsystem "lazy-loader"
;    - Compiling source file
;      "/Users/ossi/installers/sf/matlisp/lib/lazy-loader.lisp"
;;; Compiling file
;;;   /Users/ossi/installers/sf/matlisp/lib/lazy-loader.lisp
;   Loading matlisp:lib;libmatlisp.so
;      (/Users/ossi/installers/sf/matlisp/lib/libmatlisp.so)
; While compiling (:TOP-LEVEL-FORM "lazy-loader.lisp" 4726):
Warning: An error occurred
          (Can't have unescaped whitespace in token. [file position =
           16])
          during the reading or evaluation of -e
          "(progn (load \"start.lisp\"))"
Allegro CL Professional Edition
8.0 [Mac OS X] (Dec 30, 2005 9:49)
Copyright (C) 1985-2005, Franz Inc., Oakland, CA, USA.  All Rights Reserved.

This development copy of Allegro CL is licensed to:
    [TC13706] University of Oulu

;; 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).
CL-USER(1):





- osku

[Matlisp-users] Re: Matrix column access

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

>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
 Nicolas> Jan Rychter <ja...@ry...> 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))

Re: [Matlisp-users] Matlisp as an Array Programming Language

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

Gday Ernst:

I'd like to see an APL in CL, but haven't been ambitious enough to do it 
myself.  NLisp (http://www.cpom.org/nlisp/) seems to be moving in that 
direction.

Steve
//////////////////////////////////////

Ernst van Waning wrote:

>Hello,
>
>  
>
>>ACM SIGAPL (http://sigapl.org) is broadening its scope to 
>>include Array Programming Languages other than classic APL.  
>>I believe that Matlisp could qualify.  I encourage those on 
>>this list to take a look at SIGAPL and consider submitting a 
>>paper to APL Quote Quad.
>>    
>>
>
>I think this is an excellent idea.  APL in CL would perhaps be even better
>:-)
>
>Kind regards,
>
>Ernst van Waning
>
>
>
>  
>

RE: [Matlisp-users] Matlisp as an Array Programming Language

[Ernst v. W. <ev...@in...>]

Hello,

> ACM SIGAPL (http://sigapl.org) is broadening its scope to 
> include Array Programming Languages other than classic APL.  
> I believe that Matlisp could qualify.  I encourage those on 
> this list to take a look at SIGAPL and consider submitting a 
> paper to APL Quote Quad.

I think this is an excellent idea.  APL in CL would perhaps be even better
:-)

Kind regards,

Ernst van Waning

[Matlisp-users] Matlisp as an Array Programming Language

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

ACM SIGAPL (http://sigapl.org) is broadening its scope to include Array 
Programming Languages other than classic APL.  I believe that Matlisp 
could qualify.  I encourage those on this list to take a look at SIGAPL 
and consider submitting a paper to APL Quote Quad.

Regards,
Steve

-- 
Steven H. Rogers, Ph.D., st...@sh...
Weblog: http://shrogers.com/weblog
"He who refuses to do arithmetic is doomed to talk nonsense."
-- John McCarthy
    

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

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

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

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

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

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

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

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

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

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

Thanks for the information,

Nicolas.

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

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

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=

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

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

>>>>> "AJ" == A J Rossini <A.J.> 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

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

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

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

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

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

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

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

Ray

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

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

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

> 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

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

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

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

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

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

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

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

Yours, Nicolas.

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

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

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

[Matlisp-users] Re: Matrix column access

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

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

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

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

--J.

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

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

Nicolas and Ray,

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

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

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

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

Thanks,

Cyrus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ray

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

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

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

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

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

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

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

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

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

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

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

> Good luck in your job search!
> Ray

Thank you,

Nicolas.

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

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

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

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

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

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

Ray

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

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

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

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

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

Thanks,
Robbie

[Matlisp-users] Re: Matrix column access

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

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

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

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

Fair enough!

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

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

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

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

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

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

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

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

--J.

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

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

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

    Nicolas> Hello Ray,

Hello!

    >> I would be happy to incorporate any or all of these things into
    >> matlisp, if you are willing to donate them and if they seem
    >> appropriate.

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

Cool.

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

What are FL.MATLISP matrix structures?

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

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

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

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

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

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

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

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

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

Good luck in your job search!

Ray

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

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

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

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

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

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

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

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

Ray

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

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

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

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

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

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

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

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

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

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

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

Ray