Prev: Raffy's Karma [was Re: [ANN] Filtered functions]
Next: (apply #'concatenate 'list list)
From: Tamas K Papp on 9 Dec 2009 10:43
On Wed, 09 Dec 2009 07:18:34 -0800, Mirko wrote:

> On Dec 9, 9:54 am, Mirko <mirko.vuko...(a)gmail.com> wrote:
>> On Dec 9, 4:32 am, Tamas K Papp <tkp...(a)gmail.com> wrote:
>>
>> > On Wed, 09 Dec 2009 09:30:40 +0000, Tamas K Papp wrote:
>> > > I am working on a LAPACK/BLAS wrapper for CL. [1] It is pretty
>> > > usable
>>
>> > [1] I left off the link:http://github.com/tpapp/lla
>>
>> I applaud your effort in doing this and making it available to the rest
>> of us.  Thank you.
>>
>> Can you comment on where does your package fit in with the several
>> other lisp packages that interface with lapack/blas (blapack comes to
>> mind)?
>>
>> Thanks,
>>
>> Mirko
>
> One other question/comment: Your array access routines provide
> functionality not present in CL. That is great.
>
> What would be really cool (and I would love to help if need be) is to
> have a vector/matrix/arrays that one can pass to both your library (and
> others) *and* gsll.
>
> Or is this already taken care of?

I mean to blog about these things one of these days, but the short
summary is:

1. I wrote a library called XARRAY, which is meant to be a general
array interface. If you have an array-like object (in gsll,
lisp-matrix, LLA, or CL's native arrays), you just define
corresponding methods, eg xref, xdims, etc. The generic function

(take 'requested-type your-object)

can take care of conversions. It will try to do something sensible,
and you can define your own methods. This is meant to be a general
interface, independent of LLA. AFAIK Tony plans to support this in
LISP-MATRIX. XARRAY has a lot of bells & whistles for manipulating
arrays in general, views, vectorized functions, etc. They are meant
as fallbacks, and should be optimizable if you want something to be
superfast. XARRAY is pretty stable now. I am using it for my own
purposes, ironing out the remaining wrinkles and simplifying the
interface.

2. LLA is a high-level linear algebra package based on LAPACK (and
BLAS, but not a lot of the latter). It has its own numeric-vector
class, and has classes for matrix types (eg UPPER-TRIANGULAR-MATRIX,
HERMITIAN-MATRIX) and matrix decompositions. So

(solve a b)

will do the "right thing" if A is a dense matrix, a triangular matrix,
an LU decomposition, etc, and if B is a matrix or a vector. Similarly,

(eigen a :vectors-p t)

will give you eigenvalues w/ vectors, selecting the correct LAPACK
procedure based on the type of A.

LLA also has a sort-of lazy copying mechanism: if a vector is copied
with nv-copy, it will share structure until it is modified (using
XREF).

3. Sorry for the lack of documentation yet, things are still in flux.
I am unwilling to fix the API of either library for the moment,
because I get a lot of ideas on how to make things more sensible when
I am using them. Eg XARRAY benefited a lot from being used in LLA,
and LLA is benefiting a lot from my current project (fast Kalman
smoothers w/ Gibbs sampling, CL code will eventually be released).
But both should be usable, they pass unit tests, just don't count on
the interface being super-stable in the long run.

4. In relation to other libraries: I find that none are sufficiently
high-level or polished enough for my purposes (though LISP-MATRIX
comes close). It seems that the prevailing attitude is to worry about
micro-optimizations until the authors get disgusted with the whole
thing and abandon the project. My purpose is to make something that
_I_ love using because it allows me to do all my numerical programming
in CL. So the main advantage you (should) get compared to other
libraries is a well-designed, convenient interface. That said, it
should be fast, especially on SBCL.

Feedback is welcome. But don't send hate mail if functions just
disappear or change semantics :-) The best way to keep up with the
changes is to follow the package on github.

Cheers,

Tamas
From: Mirko on 10 Dec 2009 09:39
On Dec 9, 10:43 am, Tamas K Papp <tkp...(a)gmail.com> wrote:
> On Wed, 09 Dec 2009 07:18:34 -0800, Mirko wrote:
> > On Dec 9, 9:54 am, Mirko <mirko.vuko...(a)gmail.com> wrote:
> >> On Dec 9, 4:32 am, Tamas K Papp <tkp...(a)gmail.com> wrote:
>
> >> > On Wed, 09 Dec 2009 09:30:40 +0000, Tamas K Papp wrote:
> >> > > I am working on a LAPACK/BLAS wrapper for CL. [1] It is pretty
> >> > > usable
>
> >> > [1] I left off the link:http://github.com/tpapp/lla
>
> >> I applaud your effort in doing this and making it available to the rest
> >> of us.  Thank you.
>
> >> Can you comment on where does your package fit in with the several
> >> other lisp packages that interface with lapack/blas (blapack comes to
> >> mind)?
>
> >> Thanks,
>
> >> Mirko
>
> > One other question/comment:  Your array access routines provide
> > functionality not present in CL.  That is great.
>
> > What would be really cool (and I would love to help if need be) is to
> > have a vector/matrix/arrays that one can pass to both your library (and
> > others) *and* gsll.
>
> > Or is this already taken care of?
>
> I mean to blog about these things one of these days, but the short
> summary is:
>
> 1. I wrote a library called XARRAY, which is meant to be a general
> array interface.  If you have an array-like object (in gsll,
> lisp-matrix, LLA, or CL's native arrays), you just define
> corresponding methods, eg xref, xdims, etc.  The generic function
>
> (take 'requested-type your-object)
>
> can take care of conversions.  It will try to do something sensible,
> and you can define your own methods.  This is meant to be a general
> interface, independent of LLA.  AFAIK Tony plans to support this in
> LISP-MATRIX.  XARRAY has a lot of bells & whistles for manipulating
> arrays in general, views, vectorized functions, etc.  They are meant
> as fallbacks, and should be optimizable if you want something to be
> superfast.  XARRAY is pretty stable now.  I am using it for my own
> purposes, ironing out the remaining wrinkles and simplifying the
> interface.
>
> 2. LLA is a high-level linear algebra package based on LAPACK (and
> BLAS, but not a lot of the latter).  It has its own numeric-vector
> class, and has classes for matrix types (eg UPPER-TRIANGULAR-MATRIX,
> HERMITIAN-MATRIX) and matrix decompositions.  So
>
> (solve a b)
>
> will do the "right thing" if A is a dense matrix, a triangular matrix,
> an LU decomposition, etc, and if B is a matrix or a vector.  Similarly,
>
> (eigen a :vectors-p t)
>
> will give you eigenvalues w/ vectors, selecting the correct LAPACK
> procedure based on the type of A.
>
> LLA also has a sort-of lazy copying mechanism: if a vector is copied
> with nv-copy, it will share structure until it is modified (using
> XREF).
>
> 3. Sorry for the lack of documentation yet, things are still in flux.
> I am unwilling to fix the API of either library for the moment,
> because I get a lot of ideas on how to make things more sensible when
> I am using them.  Eg XARRAY benefited a lot from being used in LLA,
> and LLA is benefiting a lot from my current project (fast Kalman
> smoothers w/ Gibbs sampling, CL code will eventually be released).
> But both should be usable, they pass unit tests, just don't count on
> the interface being super-stable in the long run.
>
> 4. In relation to other libraries: I find that none are sufficiently
> high-level or polished enough for my purposes (though LISP-MATRIX
> comes close).  It seems that the prevailing attitude is to worry about
> micro-optimizations until the authors get disgusted with the whole
> thing and abandon the project.  My purpose is to make something that
> _I_ love using because it allows me to do all my numerical programming
> in CL.  So the main advantage you (should) get compared to other
> libraries is a well-designed, convenient interface.  That said, it
> should be fast, especially on SBCL.
>
> Feedback is welcome.  But don't send hate mail if functions just
> disappear or change semantics :-)  The best way to keep up with the
> changes is to follow the package on github.
>
> Cheers,
>
> Tamas

Thanks. I will check it out. Primarily xarray (found it on github),
since I am slicing and dicing them right now.

Mirko
First  |  Prev  | 
Pages: 1 2
Prev: Raffy's Karma [was Re: [ANN] Filtered functions]
Next: (apply #'concatenate 'list list)