From: Erik Naggum
Subject: Re: [specialized arrays] which lisp has them?
Date:
Message-ID: <3165302816800445@naggum.no>
* Tunc Simsek <······@tudor.EECS.Berkeley.EDU>
| This is important because the recent tool matlisp relies on (simple-array
| double-float (*)) and that the array must have C doubles contiguous in
| memory.
could you explain why you rely on such low-level representational issues?
#:Erik
I remember reading the announcement for matlisp. Apparently it provides OO
facilities for working with matrices using the BLAS and LAPACK libraries,
high performance matrix algebra libraries orginally written in Fortran.
Therefore the requirements.
Sunil
"Erik Naggum" <····@naggum.no> wrote in message
·····················@naggum.no...
> * Tunc Simsek <······@tudor.EECS.Berkeley.EDU>
> | This is important because the recent tool matlisp relies on
(simple-array
> | double-float (*)) and that the array must have C doubles contiguous in
> | memory.
>
> could you explain why you rely on such low-level representational
issues?
>
> #:Erik
Sunil, that is precisely the requirement. However, it is noted that
this may
not be the best way to interface a fortran routine to a Lisp function.
Like I said, essentially I'm looking for a uniform implementation of
MALLOC
accross lisp implementations. Since none exists (to my knowledge),
we've used
specialized arrays as a hack.
Tunc
Sunil Mishra wrote:
>
> I remember reading the announcement for matlisp. Apparently it provides OO
> facilities for working with matrices using the BLAS and LAPACK libraries,
> high performance matrix algebra libraries orginally written in Fortran.
> Therefore the requirements.
>
> Sunil
>
> "Erik Naggum" <····@naggum.no> wrote in message
> ·····················@naggum.no...
> > * Tunc Simsek <······@tudor.EECS.Berkeley.EDU>
> > | This is important because the recent tool matlisp relies on
> (simple-array
> > | double-float (*)) and that the array must have C doubles contiguous in
> > | memory.
> >
> > could you explain why you rely on such low-level representational
> issues?
> >
> > #:Erik
From: ········@ne.mediaone.net
Subject: Re: [specialized arrays] which lisp has them?
Date:
Message-ID: <uya67s1he.fsf@ne.mediaone.net>
Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
> Sunil, that is precisely the requirement. However, it is noted that
> this may not be the best way to interface a fortran routine to a
> Lisp function.
> Like I said, essentially I'm looking for a uniform implementation of
> MALLOC accross lisp implementations. Since none exists (to my
> knowledge), we've used specialized arrays as a hack.
let me see if i have this straight.
iow you need to pass a scratch pad to your fortran functions?
--
johan kullstam l72t00052
········@ne.mediaone.net wrote:
>
> Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
>
> > Sunil, that is precisely the requirement. However, it is noted that
> > this may not be the best way to interface a fortran routine to a
> > Lisp function.
>
> > Like I said, essentially I'm looking for a uniform implementation of
> > MALLOC accross lisp implementations. Since none exists (to my
> > knowledge), we've used specialized arrays as a hack.
>
> let me see if i have this straight.
>
> iow you need to pass a scratch pad to your fortran functions?
>
I don't know what 'iow' means but yes, a scratch pad is what is passed
to
the fortran routines. Its more than that though, the scratch pad is
filled
by fortran and returned with valuable contents.
Tunc
> --
> johan kullstam l72t00052
From: Johan Kullstam
Subject: Re: [specialized arrays] which lisp has them?
Date:
Message-ID: <m21z3zujqg.fsf@euler.axel.nom>
Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
> ········@ne.mediaone.net wrote:
> >
> > Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
> >
> > > Sunil, that is precisely the requirement. However, it is noted that
> > > this may not be the best way to interface a fortran routine to a
> > > Lisp function.
> >
> > > Like I said, essentially I'm looking for a uniform implementation of
> > > MALLOC accross lisp implementations. Since none exists (to my
> > > knowledge), we've used specialized arrays as a hack.
> >
> > let me see if i have this straight.
> >
> > iow you need to pass a scratch pad to your fortran functions?
> >
> I don't know what 'iow' means
IOW = in other words
> but yes, a scratch pad is what is
> passed to the fortran routines. Its more than that though, the
> scratch pad is filled by fortran and returned with valuable
> contents.
nod. i would guess that any lisp with a foreign function interface
(FFI) would have some sort of mechanism for this. how to do it with
allegro? i don't know.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Johan Kullstam wrote:
>
> Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
>
> > ········@ne.mediaone.net wrote:
> > >
> > > Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
> > >
> > > > Sunil, that is precisely the requirement. However, it is noted that
> > > > this may not be the best way to interface a fortran routine to a
> > > > Lisp function.
> > >
> > > > Like I said, essentially I'm looking for a uniform implementation of
> > > > MALLOC accross lisp implementations. Since none exists (to my
> > > > knowledge), we've used specialized arrays as a hack.
> > >
> > > let me see if i have this straight.
> > >
> > > iow you need to pass a scratch pad to your fortran functions?
> > >
>
> > I don't know what 'iow' means
>
> IOW = in other words
>
> > but yes, a scratch pad is what is
> > passed to the fortran routines. Its more than that though, the
> > scratch pad is filled by fortran and returned with valuable
> > contents.
>
> nod. i would guess that any lisp with a foreign function interface
> (FFI) would have some sort of mechanism for this. how to do it with
> allegro? i don't know.
>
Again NOD = ??. Allegro has specialized arrays (not as rich as CMUCL).
I'm guessing
that it has an equivalent of an SAP (system area pointer) as in CMUCL as
well, to that
the chunk of memory allocated for the array can be accessed directly and
passed to
a foreign function.
I've looked at CLISP, and it has a very rich FFI, so you can call the C
malloc directly,
but you may have to be tedious about garbage collection etc ...
Tunc
> --
> J o h a n K u l l s t a m
> [········@ne.mediaone.net]
> Don't Fear the Penguin!
From: Johan Kullstam
Subject: Re: [specialized arrays] which lisp has them?
Date:
Message-ID: <m2wvlrszla.fsf@euler.axel.nom>
Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
> Johan Kullstam wrote:
> > nod. i would guess that any lisp with a foreign function interface
> > (FFI) would have some sort of mechanism for this. how to do it with
> > allegro? i don't know.
> >
>
> Again NOD = ??.
nod isn't an acronym. i was nodding.
btw is there a good plotting package for lisp?
i'd rather use cmucl or clisp with matlisp than matlab or octave. but
i do need a good graphing facility.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
On Sat, 22 Apr 2000 01:18:12 GMT, Johan Kullstam <········@ne.mediaone.net>
wrote:
> btw is there a good plotting package for lisp?
You may try the gnuplot interface by Sam Steingold:
src/cllib/gnuplot.lisp
included with cllib, which is part of CLOCC (Common Lisp Open Code
Collection):
http://clocc.sourceforge.net/
Source tree snapshots are available at:
ftp://clocc.sourceforge.net/pub/clocc/snapshots/
If you prefer you can access the source tree by anonymous CVS (blank
password). I include below the documentation of the routines exported by
the interface.
> i'd rather use cmucl or clisp with matlisp than matlab or octave. but
The gnuplot interface works at least with CLISP and CMU CL.
Paolo
---------------------------------------------------------------------------
WITH-PLOT-STREAM ((str plot &rest header) &body body) [MACRO]
Execute body, with STR bound to the gnuplot stream.
Usage: (with-plot-stream (stream PLOT &rest HEADER) body).
HEADERs are passed to `plot-header', which see.
PLOT means:
T, :plot => plot;
:print => print;
:wait => plot and wait for gnuplot to terminate.
:file => write `*gnuplot-file*' and print a message.
NIL => do nothing, print nothing, return NIL.
PLOT-DATED-LISTS (begd endd dls &rest opts [FUNCTION]
&key (title "dated plot") (xlabel "time") rel
data-style
(ylabel (if rel "relative value" "value"))
(timefmt "%y-%m-%d") ema (slot 'val) (plot t)
&allow-other-keys)
Plot the dated lists from BEGD to ENDD.
Most of the keys are the gnuplot options (see the documentation
for `plot-header' and `with-plot-stream' for details.)
REL means plot everything relative to the first value.
EMA is the list of parameters for Exponential Moving Averages.
PLOT-LISTS (lss &rest opts &key (key #'value) [FUNCTION]
(title "list plot") (plot t) rel (xlabel "nums")
(ylabel (if rel "relative value" "value")) (depth
(1- (apply #'min (mapcar #'length lss))))
(data-style (plot-data-style depth))
&allow-other-keys)
Plot the given lists of numbers.
Most of the keys are the gnuplot options (see the documentation
for `plot-header' and `with-plot-stream' for details.)
LSS is a list of lists, car of each list is the title, cdr is the
numbers.
PLOT-LISTS-ARG (lss &rest opts &key (key #'identity) rel lines [FUNCTION]
(title "arg list plot") (xlabel "nums")
(ylabel (if rel "relative value" "value"))
data-style quads (plot t) xbeg xend
&allow-other-keys)
Plot the given lists of numbers.
Most of the keys are the gnuplot options (see the documentation
for `plot-header' and `with-plot-stream' for details.)
LSS is a list of lists, car of each list is the title, cdr is the
list of conses of abscissas and ordinates. KEY is used to extract the
cons.
PLOT-ERROR-BARS (ll &rest opts &key (title "error bar plot") [FUNCTION]
(xlabel "nums") (ylabel "value") (plot t)
(data-style (plot-data-style (list ll))) (xkey
#'first)
(ykey #'second) (ydkey #'third)
&allow-other-keys)
Plot the list with errorbars.
Most of the keys are the gnuplot options (see the documentation
for `plot-header' and `with-plot-stream' for details.)
The first element is the title, all other are records from which we
get x, y and ydelta with xkey, ykey and ydkey.
PLOT-FUNCTIONS (fnl xmin xmax numpts &rest opts [FUNCTION]
&key data-style (plot t) (title "function plot")
&allow-other-keys)
Plot the functions from XMIN to XMAX with NUMPTS+1 points.
Most of the keys are the gnuplot options (see the documentation
for `plot-header' and `with-plot-stream' for details.)
FNL is a list of (name . function).
E.g.: (plot-functions (list (cons 'sine #'sin)) 0 pi 100)
PLOT-DATED-LISTS-DEPTH (depth dls slot &rest opts) [FUNCTION]
Plot the dated lists, DEPTH *days* from the beginning.
OPTS is passed to `plot-lists-arg'.
---------------------------------------------------------------------------
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
On Sat, 22 Apr 2000, Johan Kullstam wrote:
> Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
>
> > Johan Kullstam wrote:
> > > nod. i would guess that any lisp with a foreign function interface
> > > (FFI) would have some sort of mechanism for this. how to do it with
> > > allegro? i don't know.
> > >
> >
> > Again NOD = ??.
>
> nod isn't an acronym. i was nodding.
>
> btw is there a good plotting package for lisp?
>
> i'd rather use cmucl or clisp with matlisp than matlab or octave. but
> i do need a good graphing facility.
CLLIB has a simple gnuplot interface (via pipes), and I have one as well,
which is very incomplete.
In my opinion, the plotting part is one of the most important. Matlab,
octave do this very well, and non-trivially. For example, doing replot
with gnuplot is not easy (there can be a confusion of plotting modes or
a preivous plot may not exist), but octaves gnuplot interface hacks this
problem really well.
I think that gnuplot is an excellent package and a stronger lisp interface
would be well worth the effort, especially with recent additions to the
gnuplot package (see http://www.sci.muni.cz/~mikulik/gnuplot.html for
some impressive results).
Regards,
Tunc
>
> --
> J o h a n K u l l s t a m
> [········@ne.mediaone.net]
> Don't Fear the Penguin!
>
>
From: Johan Kullstam
Subject: Re: [specialized arrays] which lisp has them?
Date:
Message-ID: <m2zoqlwqtk.fsf@euler.axel.nom>
Tunc Simsek <······@tudor.EECS.Berkeley.EDU> writes:
> On Sat, 22 Apr 2000, Johan Kullstam wrote:
>
> > Tunc Simsek <······@robotics.eecs.berkeley.edu> writes:
> >
> > > Johan Kullstam wrote:
> > > > nod. i would guess that any lisp with a foreign function interface
> > > > (FFI) would have some sort of mechanism for this. how to do it with
> > > > allegro? i don't know.
> > > >
> > >
> > > Again NOD = ??.
> >
> > nod isn't an acronym. i was nodding.
> >
> > btw is there a good plotting package for lisp?
> >
> > i'd rather use cmucl or clisp with matlisp than matlab or octave. but
> > i do need a good graphing facility.
>
> CLLIB has a simple gnuplot interface (via pipes), and I have one as well,
> which is very incomplete.
>
> In my opinion, the plotting part is one of the most important. Matlab,
> octave do this very well, and non-trivially. For example, doing replot
> with gnuplot is not easy (there can be a confusion of plotting modes or
> a preivous plot may not exist), but octaves gnuplot interface hacks this
> problem really well.
imho octave's gnuplot interface is awfully kludgy.
> I think that gnuplot is an excellent package and a stronger lisp interface
> would be well worth the effort, especially with recent additions to the
> gnuplot package (see http://www.sci.muni.cz/~mikulik/gnuplot.html for
> some impressive results).
gnuplot itself is an excellent package. unfortunately, the interface
is via a text mode. it's good for interaction, but not for calling
from another program. plus all plots must go through a file read and
write instead of passing an array in memory. i'd rather gnuplot were
a C library too.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: Erik Naggum
Subject: Re: [specialized arrays] which lisp has them?
Date:
Message-ID: <3165409740471698@naggum.no>
* "Sunil Mishra" <·······@arslogica.com>
| I remember reading the announcement for matlisp. Apparently it provides OO
| facilities for working with matrices using the BLAS and LAPACK libraries,
| high performance matrix algebra libraries orginally written in Fortran.
| Therefore the requirements.
well, from that follows the requirements _in the FFI_, but not the native
representation. I see no reason whatsoever to require the native Common
Lisp system to represent arrays or matrices like this, but it is obvious
that the ability to access arrays or matrices represented like this from
Common Lisp when they were declared/created/whatever from or in the FFI,
is a requirement of the system as a whole.
#:Erik
On 22 Apr 2000, Erik Naggum wrote:
> * "Sunil Mishra" <·······@arslogica.com>
> | I remember reading the announcement for matlisp. Apparently it provides OO
> | facilities for working with matrices using the BLAS and LAPACK libraries,
> | high performance matrix algebra libraries orginally written in Fortran.
> | Therefore the requirements.
>
> well, from that follows the requirements _in the FFI_, but not the native
> representation. I see no reason whatsoever to require the native Common
> Lisp system to represent arrays or matrices like this, but it is obvious
> that the ability to access arrays or matrices represented like this from
> Common Lisp when they were declared/created/whatever from or in the FFI,
> is a requirement of the system as a whole.
your observation is correct. The native representation should not matter.
However, if your native representation of a matrix (say, contiguous column
major with n bytes for each float) does not agree with the foreign routine
then you will need an extra malloc,copy,free to do a foreign operation.
If this extra cost does not matter to you then everything is o.k., but
I'm trying to avoid it if possible (which is the case with matlisp and
cmucl).
Regards,
Tunc
>
> #:Erik
>
>
>>>>> "Erik" == Erik Naggum <····@naggum.no> writes:
Erik> * "Sunil Mishra" <·······@arslogica.com>
Erik> | I remember reading the announcement for matlisp. Apparently it provides OO
Erik> | facilities for working with matrices using the BLAS and LAPACK libraries,
Erik> | high performance matrix algebra libraries orginally written in Fortran.
Erik> | Therefore the requirements.
Erik> well, from that follows the requirements _in the FFI_, but not the native
Erik> representation. I see no reason whatsoever to require the native Common
Erik> Lisp system to represent arrays or matrices like this, but it is obvious
Erik> that the ability to access arrays or matrices represented like this from
Erik> Common Lisp when they were declared/created/whatever from or in the FFI,
Erik> is a requirement of the system as a whole.
Perhaps a bit of history will clarify this a bit.
The very first version of matlisp actually used the native malloc to
allocate space. While this worked fine, at the time CMUCL had a limit
on how much alien space you could actually allocate. It was about 8
MB (I think this limit has been raised in later versions on some
architectures). Hardly useful you if wanted to work with reasonably
large matrices.
The only way out I could see at the time was to use the specialized
arrays in CMUCL which are laid out just like C arrays. This would
give me the full lisp heap to use, with the added benefit that the
arrays looked just like lisp arrays and the nice ability of the
foreign code to destroy the lisp heap if I goofed. :-)
I'm not sure of any other way out of this malloc limitation in CMUCL.
Ray