- gsll-devel - mailman3.common-lisp.net

[Gsll-devel] Build problems
by Zach 24 Jun '09

24 Jun '09

I haven't been able to build a fresh clone of GSLL for a while now (maybe never?). This has already floated up on this list before, but GSLL/CFFI-GROVEL don't know where to find header files. There seems to be no way to tell them other than changing the source and passing a special :cc-flags on the groveler line. I also have to do this with FSBV. It would be nice if there was something in CFFI-GROVEL that allows you to say "check here, here, and here for my header files." I'm talking about something like CFFI:*FOREIGN-LIBRARY-DIRECTORIES*. I am bringing it up here first since I might be mistaken about the state of things. Any other people out there have headers in places CFFI-GROVEL doesn't think to look? Do you have a better solution? Zach

2 1

[Gsll-devel] Problems with SVD through gsll on OS X 10.5 with SBCL
by Nimalan Mahendran 24 Jun '09

24 Jun '09

Hello everyone, I'm trying to see whether I could use SBCL (or whatever CL implementation) as an alternative for Matlab in machine learning research. I have gsll running, but I saw that gsll's SVD, (sv-decomposition u s v) is converging to the wrong answers for the identity matrix. >> M = [1 0 0; 0 1 0; 0 0 1] but Matlab's SVD works fine. Here's what happens in gsll/SBCL: (setf M1 (MAKE-MARRAY '(UNSIGNED-BYTE 32) :INITIAL-CONTENTS '((1 0 0) (0 1 0) (0 0 1)))) (setf u (copy m1)) (setf s (make-marray 'vector-unsigned-byte-32 :dimensions 3)) (setf v (make-marray 'matrix-unsigned-byte-32 :dimensions '(3 3))) (sv-decomposition u s v) GSL> u #<MATRIX-UNSIGNED-BYTE-32 #2A((0 0 0) (2147483648 0 3220176896) (0 2147483648 0))> GSL> s #<VECTOR-UNSIGNED-BYTE-32 #(268809831 296241371 268543215)> GSL> v #<MATRIX-UNSIGNED-BYTE-32 #2A((2083159301 2991920483 0) (2147483648 0 1072693248) (0 3220176896 0))> GSL> The answers are definitely not right.. I don't think the right memory addresses are even being accessed. I noticed in the definition of SV-decomposition in svd.lisp, the :outputs parameter is (A S V), but according to the GSL documentation at http://www.gnu.org/software/gsl/manual/html_node/Singular-Value-Decompositi…, maybe it should be (A V S)? I'm not sure how these parameters to defmfun actually work or what they mean (although I am familiar with cffi..). I was getting the same numbers even when I did SVD on this matrix: >> M = [1 0 0; 0 2 0; 0 0 3] so a memory access error seems likely to me. Would someone mind helping me fix this? Thanks! -- Nimalan Mahendran

2 2

Re: [Gsll-devel] gsll:+edom+ has no value
by Liam Healy 19 Jun '09

19 Jun '09

On Tue, Jun 16, 2009 at 11:11 PM, Mirko Vukovic<mirko.vukovic(a)gmail.com> wrote: > On Mon, Jun 15, 2009 at 10:03 PM, Liam Healy<lhealy(a)common-lisp.net> wrote: >> On Mon, Jun 15, 2009 at 10:46 AM, Mirko Vukovic<mirko.vukovic(a)gmail.com> wrote: >>> Liam, >>> >>> My reading of hyperspec is that defconstant is evaluated as a >>> top-level form. Thus the need to use the `eval-when' >> >> Mirko, >> >> Actually the hyperspec is pretty ambiguous but seems to imply that >> it could be evaluated at compile time or not. >> The CLISP manual on the other hand >> http://clisp.cons.org/impnotes/defconstant.html >> is quite definite that it does not evaluate at compile time: >> The initial value is not evaluated at compile time, just like with >> DEFVAR and DEFPARAMETER. Use EVAL-WHEN if you need the value at >> compile time. >> >> I have fixed this and it now works for me in CLISP. Do a fresh pull >> in master and try it. > > You fixed it, but the compilation order needs to change: > In order to get conditions.lisp to compile & load, I first had to > compile & load libgsl-unix.lisp. > It wasn't an order problem, but a dependency declaration problem. Fixed; try again with a fresh pull. >> >> Keep in mind that many tests still fail miserably in CLISP, and in >> fact I can only get through a dozen or so before the test suite >> crashes out of CLISP. If you (or anyone) has patches or ideas about >> how to fix this, I'd be happy to hear about it. > > Well, I did not get that far ;-) Here is where things broke again: > > Illegal keyword/value pair :TYPE, DOUBLE-FLOAT in argument list. > The allowed keywords are #1=(:OPTIONAL > :DOCUMENTATION) > [Condition of type SYSTEM::SIMPLE-KEYWORD-ERROR] You need to get a fresh update to CFFI, version 0.10.5 (released on Tuesday) or later. Liam

2 1

[Gsll-devel] need fft routines
by Mirko Vukovic 18 Jun '09

18 Jun '09

I tried recently to link to gsl's gsl_fft_complex_radix2_forward, but failed miserably: (defmfun fft-c2f (x n) "gsl_fft_complex_radix2_forward" ;; for gsl doc and example see ;; http://www.gnu.org/software/gsl/manual/html_node/Radix_002d2-FFT-routines-f… ;; for stride I use the example from sorting.lisp (((mpointer x) :pointer) (1 sizet) (n :int)) :inputs (x) :definition :function :c-return :success-failure :documentation "Forward FFT for a complex double radix-2 vector") #| ;; test run (let ((arg (make-marray '(complex double-float) :dimensions 4 :initial-element #c(0d0 0d0)))) (setf (aref arg 2) #c(1d0 0d0)) (let* ((dim (length arg))) ;; (double (make-array (* 2 dim) ;; :element-type 'double-float ;; :initial-element 0d0))) ;; repackaging complex as double -- is there a built-in? ; ;; (loop ;; for re-im across arg ;; for i from 0 to (* 2 (1- dim)) by 2 ;; do (progn ;; (setf (aref double i) (realpart re-im)) ;; (setf (aref double (1+ i)) (imagpart re-im)))) (print dim) (fft-c2f arg dim))) |# I see one possible problem, that gsl_complex_packed_array datatypes. I don't see those defined in gsll. Can someone help me with linking to the fft routines? Once I can access gsl's fft's, I will verify the computation, and also generate the unit tests. Thanks, Mirko

1 1

[Gsll-devel] gsll:+edom+ has no value
by Mirko Vukovic 16 Jun '09

16 Jun '09

Hello, on loading a fresh gsll (no fasl, lib, exe) on clisp+cygwin+windows, I get: #<ADDRESS #x44C9D500>: variable GSLL::+EDOM+ has no value [Condition of type SYSTEM::SIMPLE-UNBOUND-VARIABLE] Restarts: 0: [USE-VALUE] You may input a value to be used instead of GSLL::+EDOM+. 1: [STORE-VALUE] You may input a new value for GSLL::+EDOM+. 2: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL #x1018B8A1> on #<ASDF:CL-SOURCE-FILE "conditions" #x10465C61>. 3: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL #x1018B8A1> on #<ASDF:CL-SOURCE-FILE "conditions" #x10465C61> as having been successful. 4: [ABORT] Return to SLIME's top level. 5: [ABORT] Abort --more-- The call stack seems to originate in the `define-gsl-condition' (see attached file) Any ideas? Thanks, Mirko PS BTW, I had to teach cffi-grovel how to access gcc under cygwin. I posted a message to cffi-grovel, so hopefully you will not need to do anything on the gsll side

2 3

[Gsll-devel] cffi-grovel dependency
by Mirko Vukovic 14 Jun '09

14 Jun '09

Hello The cffi-grovel package does not seem to be listed in gsll.asd (pulled down a few minutes ago). I have to load it separately for the installation to proceed. Does anyone else see this problem? Thanks Mirko

2 1

[Gsll-devel] Correct scalarsp form for gsl:make-multi-dimensional-minimizer-fdf?
by James Wright 10 Jun '09

10 Jun '09

Hi everyone, First of all, thanks very much for GSLL. It's impressively comprehensive, and it's making my life a lot easier. I've been using `gsl:make-multi-dimensional-minimizer-f' in one of my projects for a while now, and I'm looking at switching to one of the gradient-based methods instead. However, I can't figure out how SCALARSP works with the f-and-gradient function. As a very simple example, consider the function F(x1 x2) = x1^2 + x2^3: (defun f (x1 x2) (+ (* x1 x1) (* x2 x2 x2))) For the function-and-gradient function, I need to return the value at [x1 x2], plus a vector of 2 partial derivatives. In total that's 3 items, so I had thought that the following function would work: (defun h (x1 x2) (values (+ (* x1 x1) (* x2 x2 x2)) (* 2 x1) (* 3 x2 x2))) However, when I try to use it like so: (gsl:make-multi-dimensional-minimizer-fdf gsl:+vector-bfgs2+ 2 '(f g h) #m(9.0 9.0) 0.1d0 0.1d0 t) I get a TYPE-ERROR: The value NIL is not of type DOUBLE-FLOAT. I'm fairly sure that my definition of H is the problem here, because when I trace F, G, and H, H is the only function that gets called. I've also tried having H return F(X) as the first value and the gradient vector as the second value, but no dice. (SBCL complains that a double-float vector is not a double-float, which is true. :) I'm running SBCL and the most recent version of GSLL (I pulled from the master branch about an hour ago). Could anyone give me a hint as to what I'm doing wrong here? I could always implement using non-scalarsp functions, but if that's the only fix, then it seems pointless for make-multi-dimensional-minimizer-fdf to take a scalarsp argument in the first place. Thanks very much! James

2 2

[Gsll-devel] slightly off topic: 2D interpolation
by Mirko Vukovic 15 May '09

15 May '09

Hello, I could not find 2D routines for interpolation on regular & irregular grids in gsl. Did I miss something? Do folks have experience with alternatives? Thanks, Mirko

1 0

[Gsll-devel] Failure in gsll-tests
by Jason Nielsen 30 Apr '09

30 Apr '09

I just pull gsll from the git and am getting the following error when trying to compile gsll-tests: debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread #<THREAD "initial thread" RUNNING {1002A40011}>: LISP-UNIT:NUMERICAL-EQUAL already names an ordinary function or a macro. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE ] Replace the function binding 1: [TRY-RECOMPILING] Recompile augment and try loading it again 2: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {1004FA2F81}> on #<ASDF:CL-SOURCE-FILE "augment" {1002DA6DB1}>. 3: [ACCEPT ] Continue, treating #<ASDF:LOAD-OP NIL {1004FA2F81}> on #<ASDF:CL-SOURCE-FILE "augment" {1002DA6DB1}> as having been successful. 4: [ABORT ] Exit debugger, returning to top level. (ENSURE-GENERIC-FUNCTION LISP-UNIT:NUMERICAL-EQUAL) 0] 3 NIL I suspect this is related to your previous e-mail. Jason

2 2

Re: [Gsll-devel] practical differences between native CL array and the GSLL marray type?
by Liam Healy 30 Apr '09

30 Apr '09

Tom, Problem should be fixed now. I didn't make clear in my previous message, but the error was in GSLL, not lisp-unit, so Malcolm, do a git pull on GSLL to get the update. Thanks. Liam On Thu, Apr 30, 2009 at 12:09 PM, Thomas M. Hermann <tmh.public(a)gmail.com> wrote: > Malcolm, > > I'm a little tied up through the weekend, but I'll try to get to it. I'm > not actively testing GSLL, so if you discover more details, please > forward them to me. Otherwise, it'll have to wait until I can reproduce > the error. > > Tom > > Malcolm Reynolds wrote: >> Unless I'm mistaken I think there is a bug in the implementation >> currently.. this is with the latest from the lisp-unit and gsll git >> repositories, such that lisp-unit is at commit >> e7c4faa8baf9d071972a66c62671001a62f3cc1c ("Implementations of >> NUMERICAL-EQUAL for mixed list/vector arguments.") and gsll is at >> commit 64a0b6c271530b298ce97f168d03ab715fb80a39 ("Tests marrays >> directly"). Full log of a slime session follows: >> >> ; SLIME 2009-03-09 >> CL-USER> (asdf:operate 'asdf:load-op :gsll) >> ; loading system definition from >> ; /Users/malc/opt/lisp/asdf-registry/gsll.asd into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM "gsll" {12295D61}> as gsll >> ; loading system definition from >> ; /Users/malc/opt/lisp/sbcl/sbcl-inst-1.0.23-x86-darwin/lib/sbcl/site-systems/trivial-garbage.asd >> ; into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM TRIVIAL-GARBAGE {124BF099}> as TRIVIAL-GARBAGE >> ; registering #<SYSTEM TRIVIAL-GARBAGE-TESTS {1272DDF1}> as >> ; TRIVIAL-GARBAGE-TESTS >> ; loading system definition from >> ; /Users/malc/opt/lisp/sbcl/sbcl-inst-1.0.23-x86-darwin/lib/sbcl/site-systems/cffi.asd >> ; into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM CFFI {119164D1}> as CFFI >> ; loading system definition from >> ; /Users/malc/opt/lisp/sbcl/sbcl-inst-1.0.23-x86-darwin/lib/sbcl/site-systems/babel.asd >> ; into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM BABEL {11CA1489}> as BABEL >> ; loading system definition from >> ; /Users/malc/opt/lisp/sbcl/sbcl-inst-1.0.23-x86-darwin/lib/sbcl/site-systems/alexandria.asd >> ; into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM :ALEXANDRIA {1276FF09}> as ALEXANDRIA >> ; loading system definition from >> ; /Users/malc/opt/lisp/sbcl/sbcl-inst-1.0.23-x86-darwin/lib/sbcl/site-systems/trivial-features.asd >> ; into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM TRIVIAL-FEATURES {129ED569}> as TRIVIAL-FEATURES >> NIL >> CL-USER> (asdf:operate 'asdf:load-op :gsll-tests) >> ; loading system definition from >> ; /Users/malc/opt/lisp/asdf-registry/gsll-tests.asd into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM "gsll-tests" {11B966E9}> as gsll-tests >> ; loading system definition from >> ; /Users/malc/opt/lisp/asdf-registry/lisp-unit.asd into #<PACKAGE "ASDF0"> >> ; registering #<SYSTEM :LISP-UNIT {12484CB9}> as LISP-UNIT >> NIL >> CL-USER> (in-package :gsll) >> #<PACKAGE "GSLL"> >> GSL> (lisp-unit:assert-numerical-equal '(1 2 3) '(1 2 4)) >> '(1 2 4) failed: >> Expected (1 2 3) but saw (1 2 4) >> NIL >> GSL> (lisp-unit:assert-numerical-equal (make-marray 'double-float >> :initial-contents '(1 2 3)) >> (make-marray 'double-float :initial-contents '(1 2 4))) >> T >> >> Can you guys reproduce this? I'm SBCL 1.0.23 on OS X if that makes a >> difference.. >> >> Cheers >> >> Malcolm >> > > -- > === Thomas M. Hermann === >

1 0