matlisp

My "right answer" to the "wrong question" (that you didn't ask).

If you don't mind the potential overhead of CFFI, take a look at the
cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
(concepts and code) for Fortran linking with CFFI.

On Wed, Dec 10, 2008 at 2:20 PM, Nicolas Neuss
<neuss@...> wrote:
> Hello,
>
> I have troubles with interfacing to Fortran using Allegro and I think that
> maybe the experience of the people here might help me with this problem.
>
> The following code using SBCL works fine and returns sqrt(10).
>
>    (sb-alien:load-shared-object #p"/usr/lib/libblas.so")
>    (SB-ALIEN:DEFINE-ALIEN-ROUTINE "dnrm2_" SB-ALIEN:DOUBLE
>                                   (N SB-ALIEN:INT :COPY)
>                                   (X (* SB-ALIEN:DOUBLE) :IN)
>                                   (INCX SB-ALIEN:INT :COPY))
>
>    (dnrm2- 10 (sb-sys:vector-sap
>                 (make-array 10 :element-type 'double-float
>                 :initial-element 1.0d0))
>            1)
>
> works fine.  But when I try the same thing with Allegro (ACL 8.1, trial
> edition), I get:
>
> CL-USER(1): (cl:load #p"/usr/lib/libblas.so")
>
> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
>    ((n :int) (x (:array :double)) (incx :int))
>  :convention :fortran
>  :returning :double)
>
> (dnrm2- 10 (make-array 10 :element-type 'double-float :initial-element 1.0d0) 1)
>
> ; Foreign loading /usr/lib/libblas.so.
> T
> CL-USER(2): CL-USER(2): DNRM2-
> CL-USER(3): CL-USER(3): Error: Attempt to do an array operation on -269087380 which is not an
>       array.
>  [condition type: TYPE-ERROR]
>
> Restart actions (select using :continue):
>  0: Return to Top Level (an "abort" restart).
>  1: Abort entirely from this (lisp) process.
> [1] CL-USER(4): :bt
> Evaluation stack:
>
> DNRM2- <-
>  EVAL <- TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP <-
>  TPL:START-INTERACTIVE-TOP-LEVEL
>
> [1] CL-USER(5): :local
> Interpreted lexical environment:
> INCX: 1
> X: #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
> N: 10
> Compiled lexical environment:
> 0(REQUIRED): N: 10
> 1(REQUIRED): X:
>   #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
> 2(REQUIRED): INCX: 1
> [1] CL-USER(6):
>
> Does anyone have an idea what happens here?
>
> Thanks, Nicolas
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matlisp-users mailing list
> Matlisp-users@...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>



-- 
best,
-tony

blindglobe@...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!

>>>>> "AJ" == A J Rossini <A.J.> writes:

    AJ> My "right answer" to the "wrong question" (that you didn't ask).
    AJ> If you don't mind the potential overhead of CFFI, take a look at the
    AJ> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
    AJ> (concepts and code) for Fortran linking with CFFI.

On my list of things to do is replacing the existing FFI in matlisp
with a new version that calls CFFI instead.

And, I think, for the the existing supported Lisps, CFFI has no
additional overhead.  And then matlisp will be automagically support
more lisps than sbcl, cmucl, and Allegro.

I can't really debug the Allegro issue since I don't have Allegro.
Will the free Allegro version compile enough of matlisp for me to test
it?

Ray

Raymond Toy <raymond.toy@...> writes:

> I can't really debug the Allegro issue since I don't have Allegro.
> Will the free Allegro version compile enough of matlisp for me to test
> it?
>
> Ray

I think, yes, because it should be sufficient to compile only blas.lisp.
At least that worked for me.  But I've found the problem already - see my
other post.

Nicolas

Comparing with Matlisp, I have found my bug.

Nicolas Neuss <neuss@...> writes:

> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
                                              "dnrm2" is correct

>     ((n :int) (x (:array :double)) (incx :int))
>   :convention :fortran
>   :returning :double)

To make sure I understand this correctly: dnrm2_ is probably a routine
suitable for calling from C (passing arrays as a pointer to values) while
Allegro with convention :fortran passes arrays pointing to values-1 as is
suitable for the Fortran "dnrm2".

Is this correct?

Thanks, Nicolas

"A.J. Rossini" <blindglobe@...> writes:

> My "right answer" to the "wrong question" (that you didn't ask).
>
> If you don't mind the potential overhead of CFFI, take a look at the
> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
> (concepts and code) for Fortran linking with CFFI.

OK, thanks for the pointer.  I will have a look.

Nicolas

Nicolas Neuss <neuss@...> writes:

> "A.J. Rossini" <blindglobe@...> writes:
>
>> My "right answer" to the "wrong question" (that you didn't ask).
>>
>> If you don't mind the potential overhead of CFFI, take a look at the
>> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
>> (concepts and code) for Fortran linking with CFFI.
>
> OK, thanks for the pointer.  I will have a look.
>
> Nicolas

Stupid question: How can I get those (cl-blapack, lisp-matrix)?  Are there
homepages or official download sites for those projects?

Thanks, Nicolas

>>>>> "Nicolas" == Nicolas Neuss <neuss@...> writes:

    Nicolas> Comparing with Matlisp, I have found my bug.
    Nicolas> Nicolas Neuss <neuss@...> writes:

    >> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
    Nicolas>                                               "dnrm2" is correct

    >> ((n :int) (x (:array :double)) (incx :int))
    >> :convention :fortran
    >> :returning :double)

    Nicolas> To make sure I understand this correctly: dnrm2_ is probably a routine
    Nicolas> suitable for calling from C (passing arrays as a pointer to values) while
    Nicolas> Allegro with convention :fortran passes arrays pointing to values-1 as is
    Nicolas> suitable for the Fortran "dnrm2".

I don't know what the :fortran convention means, but your explanation
sounds plausible.  It seems a little odd to me.  For n and incx, I can
see the :fortran convention to mean pass the address of the location
of n and incx to the routine, since that's what Fortran does
(everything is pass by reference).  Arrays are a bit trickier.  I
don't see why you want to pass the address of x-1 instead of just x.
After all, Fortran x(1) is the first element of the array, however
that array might be arranged in memory.

Ray

Unofficial site for cl-blapack and lisp-matrix (if you can "git") is


On Wed, Dec 10, 2008 at 6:19 PM, Nicolas Neuss
<neuss@...> wrote:
> Nicolas Neuss <neuss@...> writes:
>
>> "A.J. Rossini" <blindglobe@...> writes:
>>
>>> My "right answer" to the "wrong question" (that you didn't ask).
>>>
>>> If you don't mind the potential overhead of CFFI, take a look at the
>>> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
>>> (concepts and code) for Fortran linking with CFFI.
>>
>> OK, thanks for the pointer.  I will have a look.
>>
>> Nicolas
>
> Stupid question: How can I get those (cl-blapack, lisp-matrix)?  Are there
> homepages or official download sites for those projects?
>
> Thanks, Nicolas
>



-- 
best,
-tony

blindglobe@...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!

I have some code which goes part way towards that (using the
cl-blapack links to BLAS and LAPACK, which are auto-generated and use
CFFI), but got seduced by lisp-matrix's duality for either
lisp-centric or foriegn-centric storage.

So much for getting sold on hype.

On the other hand, it's been a fun project (as per another post, you
can see the lisp-matrix/cl-blapack work I'm doing at github, and I
probably should return by matlisp hacks back there for posterity,
though unfortunately not for reuse, I'm just not that good at lisp
right now...).


On Wed, Dec 10, 2008 at 5:28 PM, Raymond Toy <raymond.toy@...> wrote:
>>>>>> "AJ" == A J Rossini <A.J.> writes:
>
>    AJ> My "right answer" to the "wrong question" (that you didn't ask).
>    AJ> If you don't mind the potential overhead of CFFI, take a look at the
>    AJ> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
>    AJ> (concepts and code) for Fortran linking with CFFI.
>
> On my list of things to do is replacing the existing FFI in matlisp
> with a new version that calls CFFI instead.
>
> And, I think, for the the existing supported Lisps, CFFI has no
> additional overhead.  And then matlisp will be automagically support
> more lisps than sbcl, cmucl, and Allegro.
>
> I can't really debug the Allegro issue since I don't have Allegro.
> Will the free Allegro version compile enough of matlisp for me to test
> it?
>
> Ray
>



-- 
best,
-tony

blindglobe@...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!