matlisp-users — General discussion list.

Re: [Matlisp-users] Still can't get Matlisp working

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

>>>>> "Ryan" == Ryan M Rifkin <ri...@MI...> writes:

    Ryan> ---------------
    Ryan>  ** MATLISP is loaded.  Type (HELP MATLISP)
    Ryan>     to see a list of available symbols.
    Ryan>     To use matlisp:

    Ryan>           (use-package "MATLISP")

    Ryan>     or

    Ryan>           (in-package "MATLISP-USER")

    Ryan>  ** The logical pathname matlisp has been
    Ryan>     set to:

    Ryan>           /home/rif/Software/matlisp/

    Ryan> CMU Common Lisp release x86-linux 3.0.8 18c+ 31 December 2001 build 3030, running on oscar
    Ryan> For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS.
    Ryan> or to pva...@de...
    Ryan> type (help) for help, (quit) to exit, and (demo) to see the demos

    Ryan> Loaded subsystems:
    Ryan>     Python 1.0, target Intel x86
    Ryan>     CLOS based on PCL version:  September 16 92 PCL (f)
    Ryan>     MATLISP/Pre 2.0

The fact that you get this far tells me that it very likey worked.

    Ryan> * (help matlisp)

    Ryan> Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable MATLISP is unbound.

Did you do (use-package "MATLISP") or (in-package "MATLISP-USER") as
suggested by the banner?  If not, try that and then try the help
command again.

Ray

[Matlisp-users] Still can't get Matlisp working

[Ryan M. R. <ri...@MI...>]

Sorry about this, I'm still not understanding how to get Matlisp
working.  As I mentioned, I'm using CMUCL with matlisp fresh from the
CVS repository.  I download matlisp from the repository, go into the
directory, and do

configure --with-lisp=cmucl
make

It compiles a bunch of stuff, eventually starts up Lisp, looks like
it's loading a bunch of alien objects, and finally says, but if I try
to see what symbols are there (according to the instructions), I get
an error:

---------------
 ** MATLISP is loaded.  Type (HELP MATLISP)
    to see a list of available symbols.
    To use matlisp:

          (use-package "MATLISP")

    or

          (in-package "MATLISP-USER")

 ** The logical pathname matlisp has been
    set to:

          /home/rif/Software/matlisp/

CMU Common Lisp release x86-linux 3.0.8 18c+ 31 December 2001 build 3030, running on oscar
For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS.
or to pva...@de...
type (help) for help, (quit) to exit, and (demo) to see the demos

Loaded subsystems:
    Python 1.0, target Intel x86
    CLOS based on PCL version:  September 16 92 PCL (f)
    MATLISP/Pre 2.0
* (help matlisp)

Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable MATLISP is unbound.
Restarts:
  0: [ABORT] Return to Top-Level.

Debug  (type H for help)

(EVAL MATLISP)
Source: Error finding source: 
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:  target:code/eval.lisp.
0] 
---------------

This is probably something obvious, but I'm just not getting it.
Any help/advice is appreciated.

Cheers,

rif

Re: [Matlisp-users] Trying to use Matlisp on CMUCL

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

>>>>> "rif" == rif  <ri...@MI...> writes:

    rif> Dr. Koerber: Thanks.  Your suggestions worked.  It seems that the
    rif> Matlisp homepage at sourceforge is out of date --- it suggests just
    rif> unpacking and then typing 'make cmu', which does not work.  But it
    rif> seems to be OK now.  The sourceforge webpage should probably be
    rif> updated...

Sorry about that.  There are many things out-of-date with matlisp,
but, hopefully, not the code. :-) I just haven't been motivated to do
anything about them, unfortunately.

Thanks for the tip, though.

    rif> Tunc: Yes, I did download the latest CVS version today.  Not 1.0b.

Yet another thing that I've been meaning to fix.  I guess I should
just package everything up and call it 2.0 and release it.

Yet another item on my TODO list....

Ray

Re: [Matlisp-users] Trying to use Matlisp on CMUCL

[rif <ri...@MI...>]

Dr. Koerber: Thanks.  Your suggestions worked.  It seems that the
Matlisp homepage at sourceforge is out of date --- it suggests just
unpacking and then typing 'make cmu', which does not work.  But it
seems to be OK now.  The sourceforge webpage should probably be
updated...

Tunc: Yes, I did download the latest CVS version today.  Not 1.0b.

Anyways, thanks much.  I'm looking forward to playing with this
package.  If anyone has any nice programs they've written using this
(that they're willing to share of course), I'd love to take a look,
just to get a better feel for it.  

Cheers,

rif

Re: [Matlisp-users] Trying to use Matlisp on CMUCL

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

Seems like a makefile problem.  You should not be getting
static libraries.  The latest cvs version is configured to
get dynamic libraries which should produce a libmatlisp.so 
file.  Are you sure you got the latest 'cvs' version or did you
get matlisp 1.0b?

Tunc

rif wrote:
> 
> Hello.
> 
> I am a relative newbie to LISP, so I may not know some things which
> are obivous, but I'm having some trouble getting Matlisp installed under
> CMUCL.
> 
> I just downloaded the latest version from the CVS repository.  After
> uncommenting most of the makefile (why is everything in the main makefile
> commented by default?), it builds a bunch of .o files, after which I get
> the following errors:
> 
> make[1]: Leaving directory `/home/rif/Software/matlisp'
> /usr/bin/lisp -eval '(progn (load "start.lisp"))'
> ; Loading #p"/home/rif/Software/matlisp/start.lisp".
> Converted SETLOGICALROOT.
> Converted GETLOGICALROOT.
> Converted DEFLOGICALPATH.
> ;; Loading #p"/home/rif/Software/matlisp/system.dcl".
> ;; Loading #p"/home/rif/Software/matlisp/config.lisp".
> 
> Error in function EXTENSIONS:LOAD-FOREIGN:  /usr/bin/ld failed:
> /usr/bin/ld: cannot find -lmatlisp
> 
> Restarts:
>   0: [CONTINUE] Return NIL from load of "start.lisp".
>   1: [ABORT   ] Skip remaining initializations.
> 
> Debug  (type H for help)
> 
> (EXTENSIONS:LOAD-FOREIGN "matlisp:lib;lazy-loader.o"
>                          :LIBRARIES
>                          ("-L/home/rif/Software/matlisp/lib"
>                           "-R/home/rif/Software/matlisp/lib" "-lmatlisp"
>                           "-L/usr/lib/gcc-lib/i386-linux/3.0.4"
>                           "-L/usr/lib/gcc-lib/i386-linux/3.0.4/../../.." ...)
>                          :BASE-FILE
>                          ...)
> Source: Error finding source:
> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:  target:code/foreign.lisp.
> 0]
> 
> BTW, I am running a new Debian woody installation, with cmu installed
> from the debian package, and I am using gcc 3.0.4 (browing the mailing
> list indicated there were some problems with gcc 2.95, so I switched
> versions).
> 
> I get a library in the toplevel directory of matlisp called static.a.
> Perusal of the makefile indicates that one target of make distclean is
> lib/libmatlispstatic.a.  In matlisp.mk, the static target makes a
> library called $(LIB)static.a, but there's nothing in matlisp.mk that
> can set $(LIB).  I assume this is somehow related to the problem,
> although I've tried renaming the static.a library to some other things
> to no avail.
> 
> Any help you can offer is appreciated.
> 
> Cheers,
> 
> rif
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users

Re: [Matlisp-users] Trying to use Matlisp on CMUCL

[Michael A. K. <ma...@ll...>]

Rif,

> I just downloaded the latest version from the CVS repository.  After
> uncommenting most of the makefile (why is everything in the main makefile
> commented by default?), it builds a bunch of .o files, after which I get
> the following errors:

Read the INSTALL.  I think alot of the stuff in the Makefile is
"once upon a time" stuff.  Type the two lines:

  ./configure --with-lisp=cmucl
  make

You'll be left with a Matlisp core which can be saved with (m:save-matlisp).

mike
**************************************************
Dr Michael A. Koerber    	Micro$oft Free Zone
MIT/Lincoln Laboratory	 	

[Matlisp-users] Trying to use Matlisp on CMUCL

[rif <ri...@MI...>]

Hello.

I am a relative newbie to LISP, so I may not know some things which
are obivous, but I'm having some trouble getting Matlisp installed under
CMUCL.

I just downloaded the latest version from the CVS repository.  After
uncommenting most of the makefile (why is everything in the main makefile
commented by default?), it builds a bunch of .o files, after which I get
the following errors:

make[1]: Leaving directory `/home/rif/Software/matlisp'
/usr/bin/lisp -eval '(progn (load "start.lisp"))'
; Loading #p"/home/rif/Software/matlisp/start.lisp".
Converted SETLOGICALROOT.
Converted GETLOGICALROOT.
Converted DEFLOGICALPATH.
;; Loading #p"/home/rif/Software/matlisp/system.dcl".
;; Loading #p"/home/rif/Software/matlisp/config.lisp".


Error in function EXTENSIONS:LOAD-FOREIGN:  /usr/bin/ld failed:
/usr/bin/ld: cannot find -lmatlisp

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

Debug  (type H for help)

(EXTENSIONS:LOAD-FOREIGN "matlisp:lib;lazy-loader.o"
                         :LIBRARIES
                         ("-L/home/rif/Software/matlisp/lib"
                          "-R/home/rif/Software/matlisp/lib" "-lmatlisp"
                          "-L/usr/lib/gcc-lib/i386-linux/3.0.4"
                          "-L/usr/lib/gcc-lib/i386-linux/3.0.4/../../.." ...)
                         :BASE-FILE
                         ...)
Source: Error finding source: 
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:  target:code/foreign.lisp.
0] 

BTW, I am running a new Debian woody installation, with cmu installed
from the debian package, and I am using gcc 3.0.4 (browing the mailing
list indicated there were some problems with gcc 2.95, so I switched
versions).

I get a library in the toplevel directory of matlisp called static.a.
Perusal of the makefile indicates that one target of make distclean is
lib/libmatlispstatic.a.  In matlisp.mk, the static target makes a
library called $(LIB)static.a, but there's nothing in matlisp.mk that
can set $(LIB).  I assume this is somehow related to the problem,
although I've tried renaming the static.a library to some other things
to no avail.

Any help you can offer is appreciated.

Cheers,

rif

[Matlisp-users] Re: the example

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

>>>>> "Tunc" == Tunc Simsek <si...@ee...> writes:

    Tunc> Ray;  I just checked out matlisp, compiled it and ran the
    Tunc> example; all this on ACL-6.1, solaris.
    Tunc> I don't know if these results are correct, but 
    Tunc> here they are.  Could you also forward to Mike, I don't have
    Tunc> his email in my address book.

These are the expected results, so ACL doesn't have the same problem
as CMUCL for this.

(Forwarded to the list, Mike should see this then.)

Ray


    Tunc> Thanks,
    Tunc> Tunc

    Tunc> -----------------------------

    Tunc> MATLISP-USER(4): (format t "(dot ws d):  ~A~%" (m:dot *ws* d))
    Tunc>  (dot ws d): 5.771771422547397d0
    Tunc> NIL
    Tunc> MATLISP-USER(5): (format t "(dot wd d):  ~A~%" (m:dot *wd* d))  
    Tunc>  (dot wd d):  #c(0.0d0 -8.946814270309073d0)
    Tunc> NIL
    Tunc> MATLISP-USER(6): (format t "(/ (m:dot *wd* d) (m:dot *ws* d)): ~A~%" (/
    Tunc> (m:dot *wd* d) (m:dot *ws* d)))
    Tunc>  (/ (m:dot *wd* d) (m:dot *ws* d)): #c(0.0d0 -1.5500985079482508d0)
    Tunc> NIL
    Tunc> MATLISP-USER(7):

[Matlisp-users] Re: [Matlisp-devel] Re: (DOT REAL-MAT COMPLEX-MAT) ERROR

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

>>>>> "Raymond" == Raymond Toy <to...@rt...> writes:

    Raymond> In any case, I think the following solves the immediate problem:

    Raymond> (defmethod dot ((x complex-matrix) (y complex-matrix) &optional (conjugate-p t))
    Raymond>   (let* ((nxm (number-of-elements x))
    Raymond> 	 (store-x (store x))
    Raymond> 	 (store-y (store y))
    Raymond> 	 (dot (if conjugate-p
    Raymond> 		  (zdotc nxm store-x 1 store-y 1)
    Raymond> 		  (zdotu nxm store-x 1 store-y 1))))
    Raymond>     (if (zerop (imagpart dot))
    Raymond> 	(realpart dot)
    Raymond> 	(complex (realpart dot) (imagpart dot)))))

    Raymond> I think this need to be fixed in ffi-cmu.lisp in some way.  There's no
    Raymond> telling what other bugs will be found because of this, if I'm right.

I've committed a fix to ffi-cmu.lisp.  I'd appreciate it if you can
try it out.  It works for me. :-)

I hope Tunc will try your example with ACL to see if the same bug
exists there.

Ray

[Matlisp-users] Re: [Matlisp-devel] Re: (DOT REAL-MAT COMPLEX-MAT) ERROR

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

>>>>> "Raymond" == Raymond Toy <to...@rt...> writes:

>>>>> "Mike" == mak  <ma...@ll...> writes:
    Mike> Ray,
    Mike> I may have spoken too soon.  Yes, the SEGMENT violation is gone.  However, 
    Mike> I stumbled upon this.  I define three distinct vectors *WS*, *WD*, and D.
    Mike> Then I compute the following

    Mike> (dot *ws* d): 			      5.771771444577276d0
    Mike> (dot *wd* d): 			      #C(0.0d0 -8.946814341083627d0)
    Mike> (/ (m:dot *wd* d) (m:dot *ws* d)):    #C(1.0d0 0.0d0)

    Mike> ==> THIS SHOULD HAVE BEEN #C(0.0D0 -1.5500985142939754D0) <==

    Mike> Now what?  I'm clueless on how to track this one down.  

    Raymond> This is very, very weird.  I'll look in to it.  And actually, it's an

I have a sneaking suspicion that this is a compiler bug where it
thinks that the temp variable used to hold the result of zdotc/zdotu
is never modified.  And since that temp variable is initialized to the
constant #c(0d0 0d0), it leaves it in a fixed place.  Thus, the result
of zdotc is recycled over and over.  We don't see it if you save the
intermediate result because a copy is made.

In any case, I think the following solves the immediate problem:

(defmethod dot ((x complex-matrix) (y complex-matrix) &optional (conjugate-p t))
  (let* ((nxm (number-of-elements x))
	 (store-x (store x))
	 (store-y (store y))
	 (dot (if conjugate-p
		  (zdotc nxm store-x 1 store-y 1)
		  (zdotu nxm store-x 1 store-y 1))))
    (if (zerop (imagpart dot))
	(realpart dot)
	(complex (realpart dot) (imagpart dot)))))

I think this need to be fixed in ffi-cmu.lisp in some way.  There's no
telling what other bugs will be found because of this, if I'm right.

Ray

[Matlisp-users] Re: (DOT REAL-MAT COMPLEX-MAT) ERROR

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

>>>>> "Mike" == mak  <ma...@ll...> writes:

    Mike> Ray,
    Mike>  I may have spoken too soon.  Yes, the SEGMENT violation is gone.  However, 
    Mike> I stumbled upon this.  I define three distinct vectors *WS*, *WD*, and D.
    Mike> Then I compute the following

    Mike> (dot *ws* d): 			      5.771771444577276d0
    Mike> (dot *wd* d): 			      #C(0.0d0 -8.946814341083627d0)
    Mike> (/ (m:dot *wd* d) (m:dot *ws* d)):    #C(1.0d0 0.0d0)

    Mike>      ==> THIS SHOULD HAVE BEEN #C(0.0D0 -1.5500985142939754D0) <==

    Mike>  Now what?  I'm clueless on how to track this one down.  

This is very, very weird.  I'll look in to it.  And actually, it's an
error in (dot complex complex) since you've created *ws* and *wd* as
complex matrixes.  Some weird problem since it computes the individual
dots correctly.

Ray

[Matlisp-users] (DOT REAL-MAT COMPLEX-MAT) ERROR

[<ma...@ll...>]

Ray,

 I may have spoken too soon.  Yes, the SEGMENT violation is gone.  However, 
I stumbled upon this.  I define three distinct vectors *WS*, *WD*, and D.
Then I compute the following

(dot *ws* d): 			      5.771771444577276d0
(dot *wd* d): 			      #C(0.0d0 -8.946814341083627d0)
(/ (m:dot *wd* d) (m:dot *ws* d)):    #C(1.0d0 0.0d0)

     ==> THIS SHOULD HAVE BEEN #C(0.0D0 -1.5500985142939754D0) <==

 Now what?  I'm clueless on how to track this one down.  

mike

;;; Here is the test file I used...

(defparameter *ws*
  (m:make-complex-matrix '(
          0.1950           
          0.2268           
          0.3161           
          0.4467           
          0.5964           
          0.7425           
          0.8661           
          0.9544           
           1.000           
           1.000           
          0.9544           
          0.8661           
          0.7425           
          0.5964           
          0.4467           
          0.3161           
          0.2268           
          0.1950)))

(defparameter *wd*
  (m:make-complex-matrix '(
          0.2316           
          0.3783           
          0.6041           
          0.8240           
          0.9720           
           1.000           
          0.8755           
          0.5988           
          0.2126           
         -0.2126           
         -0.5988           
         -0.8755           
          -1.000           
         -0.9720           
         -0.8240           
         -0.6041           
         -0.3783           
         -0.2316 )))

(defparameter d
  (m:make-complex-matrix '(
   #C( -6.8643E-1  -7.2719E-1) 
   #C( -4.6423E-1  -8.8572E-1) 
   #C( -2.0744E-1  -9.7825E-1) 
   #C(  6.4808E-2  -9.9790E-1) 
   #C(  3.3222E-1  -9.4320E-1) 
   #C(  5.7489E-1  -8.1823E-1) 
   #C(  7.7472E-1  -6.3230E-1) 
   #C(  9.1684E-1  -3.9926E-1) 
   #C(  9.9064E-1  -1.3648E-1) 
   #C(  9.9064E-1   1.3648E-1) 
   #C(  9.1684E-1   3.9926E-1) 
   #C(  7.7472E-1   6.3230E-1) 
   #C(  5.7489E-1   8.1823E-1) 
   #C(  3.3222E-1   9.4320E-1) 
   #C(  6.4808E-2   9.9790E-1) 
   #C( -2.0744E-1   9.7825E-1) 
   #C( -4.6423E-1   8.8572E-1) 
   #C( -6.8643E-1   7.2719E-1))))

(format t "(dot ws d): 			      ~A~%" (m:dot *ws* d))
(format t "(dot wd d): 			      ~A~%" (m:dot *wd* d))  
(format t "(/ (m:dot *wd* d) (m:dot *ws* d)): ~A~%" (/ (m:dot *wd* d) (m:dot *ws* d)))

[Matlisp-users] Re: [Matlisp-devel] (DOT REAL-MAT COMPLEX-MAT) causes segment violation

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

>>>>> "Michael" == Michael A Koerber <ma...@ll...> writes:

    Michael> I noticed today that (DOT X Y) causes a segment violation whenever one
    Michael> of X or Y is complex and the other is real.  

    Michael> I looked at DOT.LISP and noted that it hasn't changed in 2 years...I
    Michael> can't believe its been broke that long.  I've done no further
    Michael> research.

What platform?  I just tried this on my Solaris box using CMUCL 18d+
and I get 130 as the answer.

Ray

[Matlisp-users] (DOT REAL-MAT COMPLEX-MAT) causes segment violation

[Michael A. K. <ma...@ll...>]

I noticed today that (DOT X Y) causes a segment violation whenever one
of X or Y is complex and the other is real.  

I looked at DOT.LISP and noted that it hasn't changed in 2 years...I
can't believe its been broke that long.  I've done no further
research.

Is the problem obvious to someone else?

tnx

mike

;;; EXAMPLE OF PROBLEM

  * (setf x (m:make-real-matrix (m:seq 0 5)) y (m:make-complex-matrix (m:seq 5 10)))
  * (m:dot x y)
  
  
  Error in function UNIX::SIGSEGV-HANDLER:  Segmentation Violation at #x40331478.
  
  Restarts:
    0: [ABORT] Return to Top-Level.
  
  Debug  (type H for help)
  
  (UNIX::SIGSEGV-HANDLER #<unused-arg>
                         #<unused-arg>
                         #.(SYSTEM:INT-SAP #x3FFFE8D0))
  Source: Error finding source: 
  Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
    target:code/signal.lisp.
  0] 

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

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

Raymond Toy <to...@rt...> writes:

> 
> You missed the context, I think, and made the same mistake I
> originally made.  I think Jefferson was talking about
> element-by-element matrix multiply, not a real matrix multiply.
> 
> Ray

Of course.

N. (searching for a hole in the ground)

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

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

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

    Nicolas> Jefferson Provost <jp...@cs...> writes:
    >> Yes it's quite fast.  Multiplying two NxN matrices is still a little 
    >> slower than the outer product of two N-length vectors (which should also 
    >> be O(N^2) operations) -- but this is probably from going out of cache on 
    >> the large matrices, while the smaller vectors will stay in cache.

    Nicolas> Please rethink how many operations a matrix-matrix-multiplication
    Nicolas> needs...

You missed the context, I think, and made the same mistake I
originally made.  I think Jefferson was talking about
element-by-element matrix multiply, not a real matrix multiply.

Ray

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

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

Jefferson Provost <jp...@cs...> writes:

> Yes it's quite fast.  Multiplying two NxN matrices is still a little 
> slower than the outer product of two N-length vectors (which should also 
> be O(N^2) operations) -- but this is probably from going out of cache on 
> the large matrices, while the smaller vectors will stay in cache.

Please rethink how many operations a matrix-matrix-multiplication
needs...

Nicolas.

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

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

Raymond Toy wrote:
>>>>>>"Jefferson" == Jefferson Provost <jp...@cs...> writes:
>>>>>
> 
>     Jefferson> I'm not sure.  The short answer is that I would love to have it better
>     Jefferson> optmized, but if it's not a priority for you guys, I understand.
> 
> If you can, please try the CVS version.  I've put in an optimized
> version that should run as fast as a Fortran version should (on
> CMUCL).
> 
> I'd be interested to know if it's fast enough for you.

Yes it's quite fast.  Multiplying two NxN matrices is still a little 
slower than the outer product of two N-length vectors (which should also 
be O(N^2) operations) -- but this is probably from going out of cache on 
the large matrices, while the smaller vectors will stay in cache.

As I mentioned before, I had changed my code so I didn't need to call 
M.* as often, but that was a sub-optimal solution.  But, I realized that 
my main use of M.* was to "mask" a matrix, i.e. set a bunch of elements 
to 0.0 using another matrix as a guide:  (m.*! mask x).  So I wrote a 
special function just to do that masking.  It's MUCH faster, since it 
does no multiplication at all...


(defmethod mmask! ((a real-matrix) (mask real-matrix))

   (let* ((nxm (number-of-elements a))
	 (aa (store a))
	 (bb (store mask)))
     (declare (type fixnum nxm)
	     (type (real-matrix-store-type (*)) aa bb)
	     (optimize (speed 3) (safety 0)))

     (dotimes (k nxm a)
       (declare (type fixnum k))
       (let ((b-val (aref bb k)) )
	(declare (type real-matrix-element-type b-val)
		 (:explain :calls :types :boxing))
	(when (zerop b-val)
	  (setf (aref aa k) 0.0d0))))))

J.

[Matlisp-users] Re: [Matlisp-devel] M:SEQ Too Slow

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

>>>>> "Michael" == Michael A Koerber <ma...@ll...> writes:

    >> Instead of an array, I've decided to just do (push x seq) and then
    >> (nreverse seq) at the end.  This is quite fast for me.

    Michael> Ray,

    Michael>   Yes...this worked faster for me is well.  I've included it, w/ obvious mods,
    Michael> in my local working src copy.

    Michael> tnx for the quick response

Thank you for finding the bug, and testing out a new solution!

I'd check it into CVS but I can't seem to access it today.
Sourceforge problems, I guess.

I'll do it soon.

Ray

[Matlisp-users] Re: [Matlisp-devel] M:SEQ Too Slow

[Michael A. K. <ma...@ll...>]

> Instead of an array, I've decided to just do (push x seq) and then
> (nreverse seq) at the end.  This is quite fast for me.

Ray,

  Yes...this worked faster for me is well.  I've included it, w/ obvious mods,
in my local working src copy.

tnx for the quick response

mike
**************************************************
Dr Michael A. Koerber    	Micro$oft Free Zone
MIT/Lincoln Laboratory	 	
ma...@ll...

[Matlisp-users] Re: [Matlisp-devel] M:SEQ Too Slow

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

>>>>> "Michael" == Michael A Koerber <ma...@ll...> writes:

    Michael> I noted the following yesterday...

    Michael>   * (time (setf tmp (m:seq 0 32767) done 'done))
    Michael>   Evaluation took:
    Michael>     45.28 seconds of real time
    Michael>     44.78 seconds of user run time
    Michael>     0.01 seconds of system run time
    Michael>     2 page faults and
    Michael>     785416 bytes consed.
    Michael>   DONE
 
    Michael> Looking at SEQ.LISP I'd blame %PUSH-ON-END%.  Due to time constraints
    Michael> I did a quick hack to use an ARRAY and coerce it to a LIST on return.
    Michael> I DON'T KNOW IF THIS IS A GOOD FIX (the fastest and compatible with
    Michael> other MATLISP internal uses or not), but it answered the mail for me
    Michael> yesterday.  This is the new timing...

    Michael> * (time (setf tmp (seq 0 32767) done 'done))
    Michael> Evaluation took:
    Michael>   0.02 seconds of real time
    Michael>   0.02 seconds of user run time
    Michael>   0.0 seconds of system run time
    Michael>   0 page faults and
    Michael>   393224 bytes consed.
    Michael> DONE
    Michael> * 

Thanks for the note!  That is really bad.

Instead of an array, I've decided to just do (push x seq) and then
(nreverse seq) at the end.  This is quite fast for me.

I've attached my proposed solution.  It seems to be slightly faster
than your array solution and conses quite a bit less.

If you get a chance, let me know if this is better or not for you.

Ray


(defun seq (start step &optional end)
  (when (not end)
    (setq end step)
    (setq step 1))

  (let ((start (rationalize start))
	 (type (type-of step))
	 (step (rationalize step))
	 (end (rationalize end))
	 (seq nil))

    (when (zerop step)
      (error "STEP equal to 0"))
    (do ((x start (+ x step)))
	((if (> step 0)
	     (> x end)
	   (< x end))
	 (nreverse seq))
      (push (coerce x type) seq))))

[Matlisp-users] M:SEQ Too Slow

[Michael A. K. <ma...@ll...>]

I noted the following yesterday...

  * (time (setf tmp (m:seq 0 32767) done 'done))
  Evaluation took:
    45.28 seconds of real time
    44.78 seconds of user run time
    0.01 seconds of system run time
    2 page faults and
    785416 bytes consed.
  DONE
 
Looking at SEQ.LISP I'd blame %PUSH-ON-END%.  Due to time constraints
I did a quick hack to use an ARRAY and coerce it to a LIST on return.
I DON'T KNOW IF THIS IS A GOOD FIX (the fastest and compatible with
other MATLISP internal uses or not), but it answered the mail for me
yesterday.  This is the new timing...

* (time (setf tmp (seq 0 32767) done 'done))
Evaluation took:
  0.02 seconds of real time
  0.02 seconds of user run time
  0.0 seconds of system run time
  0 page faults and
  393224 bytes consed.
DONE
* 

FWIW the diffs and the new SEQ.LIST are attached.  Note also that I
moved the check for STEP equal to zero earlier in the routine.

[Matlisp-users] Re: matlisp unresolved sumbols

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

>>>>> "Heiko" == Heiko Schaefer <hei...@sw...> writes:

    Heiko> the following symbols are 'unknown foreign symbols':
    Heiko> daxpy_
    Heiko> dgesv_
    Heiko> zffti_
    Heiko> dcopy_

    Heiko> I have not had time to look deeper into it.

Insufficient information for me to figure this out.  I, obviously,
don't have this problem.

Please supply more info.  Joining the mailing list isn't a bad idea
either.

Ray

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

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

>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes:

    Jefferson> I'm not sure.  The short answer is that I would love to have it better
    Jefferson> optmized, but if it's not a priority for you guys, I understand.

If you can, please try the CVS version.  I've put in an optimized
version that should run as fast as a Fortran version should (on
CMUCL).

I'd be interested to know if it's fast enough for you.

Ray

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

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

I'm not sure.  The short answer is that I would love to have it better
optmized, but if it's not a priority for you guys, I understand.

I looked into optimizing it further myself, but I don't know enough about
the lisp optimization to proceed.  I managed to get around it by changing my
algorithm so I don't need to call it as often, but that solution may be
sub-optimal for me in the long run.

However, I may end up reimplementing my stuff in C++ (with Guile bindings)
for other reasons.  I'm not sure...

Jeff



On 6/13/02 11:21 AM, "Raymond Toy" <to...@rt...> wrote:

>>>>>> "Tunc" == Tunc Simsek <si...@ee...> writes:
> 
>   Tunc> Hi Ray, Jefferson;
>   Tunc> I've played with Allegro 6.0 as follows (I asked it to explain
>   Tunc>  the compilation of m.*!):
> 
>   Tunc> (defmethod m.*! ((a real-matrix) (b real-matrix))
>   Tunc>   (let* ((nxm (number-of-elements b)))
>   Tunc>     (declare (type fixnum nxm)
>   Tunc>          (optimize (speed 3) (safety 0)))
> 
>   Tunc>     (dotimes (k nxm b)
>   Tunc>       (declare (type fixnum k))
>   Tunc>       (let ((a-val (matrix-ref a k))
>   Tunc>         (b-val (matrix-ref b k)))
>   Tunc>     (declare (type real-matrix-element-type a-val b-val)
>   Tunc>          (:explain :calls :types :boxing))
>   Tunc>     (setf (matrix-ref b k) (* a-val b-val))))))
> 
> Jefferson, do you still need this optimized?   I think Tunc's version
> is good enough when both matrices are real.  The complex-valued
> versions need to be done.
> 
> Ray
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
> http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>