gsll-devel April 2010

gsll-devel@common-lisp.net

8 participants
17 discussions

[Gsll-devel] grid: map-n-grids example
by Mirko Vukovic 20 Jul '10

20 Jul '10

Hello, I just spent a few minutes on figuring out how to use map-n-grids as there are no examples in the distribution or documentation. Here is one example, here is one that accomplishes the following (in pseudo-code): (map 'grid #'(lambda (x1 x2) (- x1 x2)) grid1 grid2) (map-n-grids :sources `((,*array-3-4-double-float* ,(affi *array-3-4-double-float*)) (,*array-3-4-double-float* ,(affi *array-3-4-double-float*))) :combination-function #'(lambda (i x1 x2) (print i) (- x1 x2))) In this example, I am not sure of the role of the first variable (I did not have more time to stare at map.list) Mirko

2 1

[Gsll-devel] make-marray, :cl-array keyword
by ivan hohlov 06 Jun '10

06 Jun '10

Hi all! There is a keyword :cl-array for the gsll:make-marray function. Can I use it to convert native lisp array into marray? I'm trying to do this: (defparameter *m* (make-array '(3 3) :element-type 'single-float :initial-contents '((1.0 2.0 3.0) (4.0 5.0 6.0) (7.0 8.0 9.0)))) (gsll:make-marray 'single-float :dimensions '(3 3) :cl-array *m*) leads to error "Invalid initialization argument: :cl-array". (sbcl, of course) Am I right, using :cl-array in such a way? I have searched for examples with thes key, but found nothing. Also, if I use :data key instead of :cl-array, it works, but tue resulting marray couldn't be used in common routines, such as matrix multiplication, because it isn't simple-array. To generalize the problem - Is it possible to convert lisp array to gsll marray without copying data? Thanks

3 3

[Gsll-devel] Proposed modification of libgsl locations on linux' (RedHat in particular)
by Mirko Vukovic 26 May '10

26 May '10

Hello, I propose to add the /usr/local/lib and /usr/local/lib64 directories to the libgsl search path. As RedHat states (http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-filesyst…): "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable among a group of hosts, but not found in /usr." For example, the `official' RedHat gsl that comes with software updates from RedHat thas the version 1.10 and lives in /usr/lib64. I need to install the latest ones into /usr/local/lib64. Here is the modified libgsl definition: (cffi:define-foreign-library libgsl (:darwin (:or "/opt/local/lib/libgsl.dylib" "/sw/lib/libgsl.dylib" "/usr/local/lib/libgsl.dylib")) (:cygwin (:or "/bin/cyggsl-0.dll")) (:unix (:or "/usr/local/lib64/lib/libgsl.so.0" "/usr/local/lib64/lib/libgsl.so" ;;<--- New "/usr/local/lib/libgsl.so.0" "/usr/local/lib/libgsl.so" ;; <--- New "/usr/lib/libgsl.so.0" "/usr/lib/libgsl.so" "/usr/lib64/libgsl.so.0" "/usr/lib64/libgsl.so" )) (t (:default "libgsl"))) Note that I put the most specific case first. Otherwise the system libraries get loaded. Generalizing this approach to multiple systems (i.e. Debian, RedHat, others) can result in unmanageable loading rules (I am not familiar with other linux/unix file system conventions). In that case, it may prove useful for the user to set-up a red-hat or debian `feature', and to customize these for their particular setup. Mirko

3 4

[Gsll-devel] Find gsl automatically
by Leo 23 May '10

23 May '10

Hello, GSL provides a tool gsl-config to facilitate finding its install location etc. I have been using the attached patch on OSX to automatically find gsl libs and headers. I think it can be extended to any system that gsl-config is available. This will free user from the nightmare of installing gsl to a non-standard location. Leo

2 3

[Gsll-devel] extra info in the example section
by N J 07 May '10

07 May '10

Hey, I have a suggestion that might be obvious for all experts but nonetheless a little help for newbies like myself. Especially since gsll might be the first lisp package they (like me) want to try out. In the example section in the web page, would it be possible to add a small "getting started". Maybe it can be combined with the first example. For example. Getting started Make sure that your are able to load the system. (asdf:operate 'asdf:load-op :gsll) This should load up the system without errors. The last lines should be looking something like: ; registering #<SYSTEM GRID {1003EC1961}> as GRID ; loading system definition from /usr/share/common-lisp/systems/c-array.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM C-ARRAY {1002D0F471}> as C-ARRAY NIL * Then make sure that you use the gsll package, run the following (in-package :gsl) This should tell you that the gsll package is ready with the following line: #<PACKAGE "GSLL"> Now you are ready to try out one of the many gsl functions (jacobian-elliptic-functions 0.2d0 0.81d0) which should give you something like this: 0.19762082367187703d0 0.9802785369736752d0 0.9840560289645665d0 If the above steps have worked successful, you are ready to jump into the amazing world of gsll.

3 5

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

30 Apr '10

No problem. Thanks for the update. Liam On Wed, Apr 28, 2010 at 6:06 PM, Russell Kliese <russell(a)kliese.id.au> wrote: > Hi Liam, > > Just a quick note to let you know that I tested the changes and all > looks good. Your additional changes have made the interface better. > Thank you! > > Cheers, > > Russell > > On Thu, 2010-04-29 at 08:02 +1000, Russell Kliese wrote: >> OK, I've applied your patch and made some further changes. I have >> generally followed a policy of making objects that are to be returned >> by the function be optional arguments, with the correctly sized object >> being made by default, thereby sparing the programmer from having to >> think about it. Toward this end, the covariance argument to >> ls-covariance is now an optional argument. In order to extract the >> dimension, I needed to pass in the solver object as the first argument >> to ls-covariance, so it calls #'jacobian instead of the programmer >> having to. So I've unexported it, as that's now all taken care of. I >> converted the example so that it no longer creates the covariance >> matrix. The test passes. There is probably more improvements that >> can be made along these lines, but I'll let this go for now. >> >> [Note: for entirely independent reasons, you'll have to do fresh pull >> of GSD when you pull the new GSLL, if you are a SBCL user.] >> >> Liam >> >> On Fri, Apr 23, 2010 at 10:35 PM, Russell Kliese <russell at kliese.id.au> wrote: >> > Yes, I was thinking the same thing. I created a new patch and tested the >> > example. >> > >> > There is also the issue of the ls-covariance function requiring a raw >> > pointer to the Jacobin matrix. I just exported the jacobian function in >> > the attached patch. >> > >> > Cheers, >> > >> > Russell >> > >> > On Thu, 2010-04-22 at 22:45 -0400, Liam Healy wrote: >> >> 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 at 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 at 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 >> > >> > >

1 0

[Gsll-devel] chebyshev.lisp/coefficients returns pointer. How to get to the vector?
by Mirko Vukovic 26 Apr '10

26 Apr '10

Hello, According to the documentation, `gsl_cheb_coeffs' returns a pointer to the vector with coefficients: (http://www.gnu.org/software/gsl/manual/html_node/Auxiliary-Functions-for-Ch…) The corresponding gsll functions `coefficients' declares the c-return as sizet (I am not sure if that is correct), and does not return a vector but an integer. GSL> (coefficients (make-chebyshev 40 'chebyshev-step 0d0 1d0)) 6543008 GSL> I am assuming it is the pointer to the vector. I could not figure out how to make it return the actual coefficients vector. Thanks, Mirko

2 1

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

26 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 26 Apr '10

26 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 26 Apr '10

26 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel April 2010