Prev: Lisp internships and jobs at HPC Platform, Boston and Paris
Next: Forgot to mention...
From: Norbert_Paul on 19 Mar 2010 06:37
On my efforts to migrate my project from Java (where I use jlapack)
to Lisp I took Lapack out of the Maxima source tree and wanted to
convert it into a stand-alone library using asdf (which I thereby
started to learn).

What already works is

(asdf:operate 'asdf:load-source-op 'blas)

which was not easy, because there seems to be a bug in f2cl such that
sources produced by f2cl can only be loaded after

(setf *read-default-float-format* 'double-float).

However, when I try

(asdf:operate 'asdf:load-source-op 'lapack)

I get

"Heap exhausted during garbage collection: ..."

which also shows how much effort was spent into lapack :).

Here is my blas system:

(defpackage blas-system
(:use :asdf :common-lisp))

(in-package :blas-system)

;; Handle an f2cl-bug.
(defvar saved-read-default-float-format *read-default-float-format*)
(setf *read-default-float-format* 'double-float)

(defsystem "blas"
:description
"A stand-alone system to import the lisp-port of blas shipped with maxima"
:version "0.9"
:author "Norbert Paul"
:licence "GNU"
:depends-on ("blas-package" "f2cl")
:components
((:module blas
:perform (load-source-op :after (op c) (print 'CLEANING)
(setf *read-default-float-format*
saved-read-default-float-format ))
:components
((:file "daxpy")
;;; and many more files I omit here
)))).

The lapack-system looks similar, depends on blas, and has an even longer list of
components (to omit here).

Now my questions:

(1) Lapack is a huge library which is usually not used as a whole but rather
cherry picked.

How can I define a system where components are only loaded on demand?
(Like Java classes: There is no problem in importing the entire jlapack
library into a project.)

(2) The blas-system:saved-read-default-float-format construction is quite
an ugly hack.
I initially tried to define a (defclass f2cl-source-file (asdf:source-file) ())
and specialize the method asdf:perform such its body says

(let ((*read-default-float-format* 'double-float))
(call-next-method) )

but then asdf complains that the perform method is "not implemented".
However, if I replace (call-next-method) by some dummy code like

(print 'PERFORMING)

asdf is happily printing "PERFORMING", so I specialized at the right
spot.

How can I set up a construction like Hyperspec's proposed
(let ((*read-default-float-format* 'double-float)) (load "daxpy.lisp") )
in asdf?

(3) Is there a full documentation of asdf (except for the source, of course)?
I consider the standard doc I have far from complete.

(4) Should I consider use a different packaging tool?

(5) Has someone else (except the maxima people who also cherry-pick some of
the lapack routines) already made a lapack system for Lisp which I
could use out of the box?

There seem to be issues with the load operation in asdf. Therefore I kept
working on load-source and thought of addressing problems with load later.

Norbert
From: Raymond Toy on 19 Mar 2010 08:32
On 3/19/10 6:37 AM, Norbert_Paul wrote:
> On my efforts to migrate my project from Java (where I use jlapack)
> to Lisp I took Lapack out of the Maxima source tree and wanted to
> convert it into a stand-alone library using asdf (which I thereby
> started to learn).
>
> What already works is
>
> (asdf:operate 'asdf:load-source-op 'blas)
>
> which was not easy, because there seems to be a bug in f2cl such that
> sources produced by f2cl can only be loaded after
>
> (setf *read-default-float-format* 'double-float).

What kind of error do you see? I don't think it's a bug f2cl. The
converted code was generated assuming *read-default-float-format* is
'double-float.


> (4) Should I consider use a different packaging tool?
You could use the mk:defsys that is used with the lapack sources you got
from maxima. It's already working.
>
> (5) Has someone else (except the maxima people who also cherry-pick some of
> the lapack routines) already made a lapack system for Lisp which I
> could use out of the box?
I think there's at least one other, but I can't remember the name.

Ray

From: Norbert_Paul on 19 Mar 2010 11:40
Raymond Toy wrote:
> What kind of error do you see? I don't think it's a bug f2cl. The
> converted code was generated assuming *read-default-float-format* is
> 'double-float.

The message is
"Compile-time error:
Bound is not *, a DOUBLE-FLOAT or a list of a DOUBLE-FLOAT: 1.0"
both in cmucl and sbcl.

Note that
http://www.lispworks.com/documentation/HyperSpec/Body/v_rd_def.htm
says "Initial value: The symbol single-float."

Note also that maxima's blas-lisp.system file says
:compiler-options (:package :blas
:float-format double-float).

> You could use the mk:defsys that is used with the lapack sources you got
> from maxima. It's already working.

Yes. It seemed to me that it was already cherry-picked for maxima but with
a closer look I saw that the system indeed consists of entire lapack.
What I thought was "cherry-picking" was the :exports declaration in the lapack
package.

I can also
use the one I made myself, because it works with the few routines (the solver
and, eventually, SVD) I need.

From: Raymond Toy on 19 Mar 2010 12:17
On 3/19/10 11:40 AM, Norbert_Paul wrote:
> Raymond Toy wrote:
>> What kind of error do you see? I don't think it's a bug f2cl. The
>> converted code was generated assuming *read-default-float-format* is
>> 'double-float.
>
> The message is
> "Compile-time error:
> Bound is not *, a DOUBLE-FLOAT or a list of a DOUBLE-FLOAT: 1.0"
> both in cmucl and sbcl.

Yeah, I guess you really need to set *r-d-f-f* to double-float. I don't
recall exactly why I generated these files assuming the float format was
double-float. Perhaps because maxima defaults to having the float
format set to double-float?

>
> Yes. It seemed to me that it was already cherry-picked for maxima but with
> a closer look I saw that the system indeed consists of entire lapack.
> What I thought was "cherry-picking" was the :exports declaration in the
> lapack
> package.

If you load up all of the lapack routines, I think there's enough
information to figure out the call dependency tree and write out a new
defsystem that can be more fine-grained. (At the end of each file is a
form that describes the what routines are called by the routine in the
file. I think you need to have f2cl itself for this to work.)

However, I wouldn't be surprised if you ended up with basically one
defsystem definition per routine. It would be pretty sweet if you could
just say you wanted the SVD routine, and defsystem would automatically
build just the routines needed to run the SVD routine.

That would be pretty useful for maxima too. As it is, compiling all of
the lapack routines takes quite a bit of time for maxima, just to
compute, say, an eigenvalue.

Ray
From: Norbert_Paul on 20 Mar 2010 06:41
Raymond Toy wrote:
> On 3/19/10 11:40 AM, Norbert_Paul wrote:
> However, I wouldn't be surprised if you ended up with basically one
> defsystem definition per routine. It would be pretty sweet if you could
> just say you wanted the SVD routine, and defsystem would automatically
> build just the routines needed to run the SVD routine.
This is exactly what I had in mind in my initial post. But a defsystem
definition per routine is a bit of overkill. Wouldn't that require a
package declaration for each subroutine? (An asdf-learner's question)

Norbert
 |  Next  |  Last
Pages: 1 2
Prev: Lisp internships and jobs at HPC Platform, Boston and Paris
Next: Forgot to mention...