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

[Gsll-devel] The price of progress: sbcl1.0.37 and gsl1.14
by Mirko Vukovic 25 Apr '10

25 Apr '10

The following is my experience on 64-bit RedHat Enterprise Linux and emacs 23.1. I am slowly learning the meaning of `bleeding edge' hardware & software. *64-bit* I cannot link to 64-bit libraries. I had to use the 32-bit versions of gsl and ffi libraries. I don't think I had this problem with sbcl1.0.34. I am not sure what is the root cause of this. I suspect something with cffi and latest sbcl1.037. But I don't know how to test this. (btw, to compile gsl for 32 bit, I used the configure switch `./configure -CFLAGS=-m4') *gsll/mathematical/complex.lisp* The file fails to compile. The error is: warning: Asserted type SB-SYS:SYSTEM-AREA-POINTER conflicts with derived type (VALUES (COMPLEX DOUBLE-FLOAT) &OPTIONAL). I guess SBCL is picky about something, but I really wish I understood what was going under GSLL's hood (those macros are huge). But that is only part of the story. I can evaluate a `defmfun' form (such as (defmfun cx-add ...)), but I cannot execute it. For example, (gsl::cx-add #C(1d0 2d0) #C(3d0 4d0)) will throw an error: The value #C(1.0d0 2.0d0) is not of type SB-SYS:SYSTEM-AREA-POINTER. [Condition of type TYPE-ERROR] I looked at fsbv/examples.lisp (see complex-add), and don't understand why one works and the other does not. *testing* Testing produces more failures with the 32-bit version than with the 64-bit one. The testing results can be improved somewhat by doing: (let ((lisp-unit:*epsilon* 1d-6)) (lisp-unit:run-tests)) resulting in TOTAL: 1432 assertions passed, 29 failed, 9 execution errors. Admittedly, this is a dubious way of improving the testing score :-) So caveat emptor :-) *fsbv init.lisp* Here is a little patch to load libraries. Notice the missing 64-bit locations. These are banished for now. (cffi:define-foreign-library libffi (:darwin (:or "/opt/local/lib/libffi.dylib" "/sw/lib/libffi.dylib" "/usr/local/lib/libffi.dylib")) (:unix (:or "/usr/local/lib/libffi.so.0" "/usr/local/lib/libffi.so" "/usr/lib/libffi.so.0" "/usr/lib/libffi.so")) (t (:default "libffi"))) (cffi:use-foreign-library libffi) (I cannot push patches to git as I am behind the firewall, and even the http protocol does not work) Cheers, Mirko

2 1

[Gsll-devel] CCL install question
by Zhang Mian 25 Apr '10

25 Apr '10

Finally I resolved it. This is what i did: (1) installed all components of ASDF libs (2) libgsl-unix.lisp which is in /gsll/init is revised "#+darwin (cc-flags "-I/your_GSL_header_.h_path " (3) init.lisp which is in /gsll/init is revised a. "(cffi:define-foreign-library libgslcblas (:darwin "(:or ""-I/your_GSL_cblas_Dynmic_lib_path" b. "(cffi:define-foreign-library libgsl (:darwin (:or "-I/your_GSL_main_Dynmic_lib_path" c. same thing did in fsbv. (4) in GSL installation use : " ./configure --enable-static=yes --enable-shared=yes" (in GSL install manual, it is said "./configure --disable-shared") I ran test and got " TOTAL: 1530 assertions passed, 62 failed, 10 execution errors" on my Mac OS 10.6.3 Clozure CL64 GSL-1.14. regards Zhang Mian Shanghai Astronomical Observatory Nandan Road 80, 200030 Shanghai

2 1

[Gsll-devel] Patch that exports symbols required to use non-linear fitting outside the gsl package
by Liam Healy 25 Apr '10

25 Apr '10

Hmm, so it does. I'm wondering if fit-test-delta is always called with last-step and current-position derived from the same fit object. In which case, would it make sense to just have one argument there, the fit object? E.g. (fit-test-delta fit 1.0d-4 1.0d-4) What do you think? Liam On Wed, Apr 21, 2010 at 10:15 PM, Russell Kliese <russell(a)kliese.id.au> wrote: > Hi Liam, > > The example included at the bottom of > gsll/solve-minimize-fit/nonlinear-least-squares.lisp, line 373 > (fit-test-delta (last-step fit) (mpointer (solution fit)) 1.0d-4 > 1.0d-4)) uses (mpointer (solution fit)). Because mpointer isn't > exported, I thought I would create a specific function like last-step > and jacobian that return raw pointers. I don't really have a good > working knowledge of the internals of gsll so this may be a naive fix. > > Cheers, > > Russell > > 2010/4/22 Liam Healy <lhealy(a)common-lisp.net>: >> Russell, >> >> Can you give an example showing why this function is needed? >> If I understand correctly, #'solution gives an marray which >> can be used like any other marray. As a general practice >> I don't define functions returning raw pointers unless the exclusive >> use of the returned value from the original function >> use is to pass to a GSL function that must take a raw >> pointer, and that is very rare. >> >> Liam

2 2

[Gsll-devel] CCL install question
by Zhang Mian 23 Apr '10

23 Apr '10

Hi all, I install gsll under OSX10.6. But failed. This is the information : ; registering #<SYSTEM C-ARRAY #x302000FA13BD> as C-ARRAY > Error: value NIL is not of the expected type PACKAGE. > While executing: CCL::%READ-FORM, in process Listener(6). ; NOTE: *PACKAGE* was NIL, was reset to > Error: Attempt to print object #<Package "COMMON-LISP-USER"> on stream #<SYNONYM-STREAM to *TERMINAL-IO* #x302000BCDAED> . > While executing: CCL::PRINT-NOT-READABLE-ERROR, in process Listener(6). > Type cmd-. to abort, cmd-\ for a list of available restarts. > Type :? for other options. 1 > So any idea about my problem? Thanks Mian

1 0

[Gsll-devel] Patch that exports symbols required to use non-linear fitting outside the gsl package
by Russell Kliese 21 Apr '10

21 Apr '10

Hi, I think some additional exports are required in order to make use of the non-linear least-squares fitting outside of the gsl package. Attached is a patch that achieves this. Cheers, Russell

2 2

[Gsll-devel] feedback on gsll-tests
by Mirko Vukovic 20 Apr '10

20 Apr '10

Hi, I just installed the latest gsll and gsl (1.14) on red-hat/linux/64-bit sbcl 1.0.34 on . A couple observations on (what I think are) minor unit-tests errors and failures. *** CHOLESKY: The following error CHOLESKY: Function CHOLESKY-INVERT (gsl_linalg_cholesky_invert) is not available in the currently loaded release 1.14 of GSL; it was introduced in release 1.12. does not make sense since gsl_linalg_cholesky_invert is present in gsl1.14 (http://www.gnu.org/software/gsl/manual/html_node/Cholesky-Decomposition.html) - admittedly, I did not dig into the c code to verify if the code and documentation are out of line *** ELLIPTIC-FUNCTIONS: failure shows up when doing (lisp-unit:run-tests), but not when doing the individual tests: GSL> (lisp-unit:run-tests) ... ELLIPTIC-FUNCTIONS: (MULTIPLE-VALUE-LIST (JACOBIAN-ELLIPTIC-FUNCTIONS 0.2d0 0.81d0)) failed: Expected (0.19762082367187703d0 0.9802785369736752d0 0.9840560289645665d0 0.0d0 0.0d0 0.0d0) but saw (0.19762082367187703d0 0.9802785369736752d0 0.9840560289645665d0 0.5000000000000027d0 7.618282373747058d-16 2.5991577338697564d-13) ... GSL> (lisp-unit:run-tests elliptic-functions) ELLIPTIC-FUNCTIONS: 2 assertions passed, 0 failed. Does GSL set-up some of lisp-unit's precision variables *epsilon* or *significant-figures*? *** MATHIEU: failure can be eliminated with lower precision: GSL> (let ((lisp-unit::*epsilon* 1d-15)) (lisp-unit:run-tests mathieu)) produces two errors, but GSL> (let ((lisp-unit::*epsilon* 1d-13)) (lisp-unit:run-tests elliptic-functions)) ELLIPTIC-FUNCTIONS: 2 assertions passed, 0 failed. *** TDIST When doing the bulk test run, it produces three failures, two of which could be eliminated with slightly higher tolerances: TDIST: (MULTIPLE-VALUE-LIST (TDIST-PINV 0.6475836176504334d0 1.0d0)) failed: Expected (0.500000000000001d0) but saw (0.5000000000000003d0) TDIST: (MULTIPLE-VALUE-LIST (TDIST-QINV 0.3524163823495667d0 1.0d0)) failed: Expected (0.5d0) but saw (0.5000000000000002d0) But these two failures do not show up when doing an individual test run (lisp-unit:run-tests tdist) The one remaining error might be due to the reference data out of order: Expected ((0.14989366374481017d0 0.6794142879291215d0 -1.615833951108472d0 -1.6008862825783456d0 -1.7010935505767397d0 -0.04370959749808691d0 0.12761159276595174d0 -0.019731218255494867d0 -0.6534666117199732d0 0.2035771324523077d0 !!!1.77650300477611d0!!!)) but saw ((0.14989366374481017d0 0.6794142879291215d0 ***2.3228005857300897d0*** -1.615833951108472d0 -1.6008862825783456d0 -1.7010935505767397d0 -0.04370959749808691d0 0.12761159276595174d0 -0.019731218255494867d0 -0.6534666117199732d0 0.2035771324523077d0)) Third element in observed (marked with ***) is absent in the reference list. After that, the elements seem to agree pairwise (but offset by one location), until the last element. There the !!! element in the reference list is absent from the expected list. Cheers, Mirko

2 1

[Gsll-devel] Patch to export symbols for nlls fitting
by Russell Kliese 14 Apr '10

14 Apr '10

Hi, For some reason it seems like a message I posted a few days ago did not get emailed to list members, but it did get archived (http://common-lisp.net/pipermail/gsll-devel/2010q2/000458.html) Here it is again: I think some additional exports are required in order to make use of the non-linear least-squares fitting outside of the gsl package. Attached is a patch that achieves this. Cheers, Russell

1 0

[Gsll-devel] exporting grid::gref
by Mirko Vukovic 13 Apr '10

13 Apr '10

Any reason why grid::gref is not exported? Cheers, Mirko

2 2

[Gsll-devel] simulated-annealing
by James Wright 10 Apr '10

10 Apr '10

Hi, I've run into a couple of problems trying to get simulated-annealing-examples to run; they both have to do with the sample generic function. The first problem is that trivial-example-step calls sample with 'uniform as an argument instead of :uniform. I've attached a patch to fix this (although a patch is probably overkill since it's such a trivial fix). The second problem is trickier, and I don't quite know what to do about it. Basically, only the mpointer of the random-number-generator that is passed to simulated-annealing is passed through to simulated-annealing-int, which means that only the mpointer is passed to trivial-example-step. This results in an error when trivial-example-step tries to call sample on the passed-in mpointer, because sample only has methods defined for random-number-generators. I tried changing sa-step-function to wrap the mpointer in a random-number-generator before passing it through to the user-step-function, but that seems to cause memory problems (I think the wrappers free the underlying random number generator too many times when they get garbage-collected). Has this sort of problem been fixed elsewhere in the codebase? If not, does anyone have any ideas about how to fix this? Thanks, James

2 1

[Gsll-devel] OT: two dimensional interpolation library?
by Mirko Vukovic 02 Apr '10

02 Apr '10

I need to do some two-dimensional interpolations (with a bit of extrapolating as well). Can anyone recommend a library? Thanks, Mirko

1 0