gsll-devel

gsll-devel@common-lisp.net

246 discussions

Start a nNew thread

[Gsll-devel] gsll repository
by ivan hohlov 07 Jun '10

07 Jun '10

Hello, http://repo.or.cz seems to be down for the second day. Is there any other reposiories or mirrors of gsll? Thanks

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] unicode in rng-types.lisp
by Leo 24 May '10

24 May '10

Hello, SBCL failed to start because of file rng-types.lisp contains some non ascii names. I am using 1.0.34 on linux. These default coding systems were tried to encode text in the buffer `rng-types.lisp': (us-ascii-unix (9359 . 252)) However, each of them encountered characters it couldn't encode: us-ascii-unix cannot encode these: ü Click on a character (or switch to this window by `C-x o' and select the characters by RET) to jump to the place it appears, where `C-u C-x =' will give information about it. Leo diff --git a/random/rng-types.lisp b/random/rng-types.lisp index cc3b83e..7dc12dd 100644 --- a/random/rng-types.lisp +++ b/random/rng-types.lisp @@ -182,7 +182,7 @@ (def-rng-type +ranlux+ ; FDL "The ranlux generator is an implementation of the original - algorithm developed by Lüscher. It uses a + algorithm developed by Luscher. It uses a lagged-fibonacci-with-skipping algorithm to produce ``luxury random numbers''. It is a 24-bit generator, originally designed for single-precision IEEE floating point numbers. This implementation is @@ -192,23 +192,23 @@ The period of the generator is about 10^171. The algorithm has mathematically proven properties and it can provide truly decorrelated numbers at a known level of - randomness. The default level of decorrelation recommended by Lüscher + randomness. The default level of decorrelation recommended by Luscher is provided by this generator, while *ranlux389* gives the highest level of randomness, with all 24 bits decorrelated. Both types of generator use 24 words of state per generator. For more information see, - M. Lüscher, ``A portable high-quality random number generator for + M. Luscher, ``A portable high-quality random number generator for lattice field theory calculations'', Computer Physics Communications, 79 (1994) 100--110. F. James, ``RANLUX: A Fortran implementation of the high-quality - pseudo-random number generator of Lüscher'', Computer Physics + pseudo-random number generator of Luscher'', Computer Physics Communications, 79 (1994) 111--114.") (def-rng-type +ranlux389+) (def-rng-type +ranlxs0+ "This generator is a second-generation version of the - *ranlux* algorithm of Lüscher, which produces ``luxury random + *ranlux* algorithm of Luscher, which produces ``luxury random numbers''. This generator provides single precision output (24 bits) at three luxury levels *ranlxs0*, *ranlxs1* and *ranlxs2*. It uses double-precision floating point arithmetic internally and can be -- CCL-USER> (if you fail to plan (plan to fail))

3 3

[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] grid:row and grid:column error when used in sequence on the same marray
by Sumant Oemrawsingh 23 May '10

23 May '10

Hi, Lately, I've been playing around a bit with GSL and slicing etc using GSD. I found that grid:row and grid:column don't work as expected: (defparameter *data* (make-marray double-float :inital-contents '((1 2) (3 4))) ; vector (1,3), works fine (grid:column *data* 0) ; vector (2,4), works fine (grid:column *data* 1) ; Errors (grid:row *data* 0) ; Invalid argument; vector length n must be positive integer in init_source.c at line 90 ; Same error (grid:row *data* 1) ; Invalid argument; vector length n must be positive integer in init_source.c at line 90 Now, if I rerun the defparameter, and run the grid:row functions first, they succeed, but the grid:column functions afterwards fail. I don't quite understand, because *data* is not modified by these functions. At the moment, I'm too lazy^H^H^H^Hbusy to look into the source code and discover the source of the problem on my own. Maybe I'm just doing it wrong, though. Any help is appreciated. -Sumant -- Sumant Oemrawsingh

3 6

[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] extra info in the example section
by Liam Healy 07 May '10

07 May '10

On Wed, Apr 28, 2010 at 4:02 AM, N J <raphexion(a)gmail.com> wrote: > On Wed, Apr 28, 2010 at 3:22 AM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> I'm not sure what you're looking for here, but I've never >> had "GSL libraries not loadable" (not sure what you mean >> here; not found in the path?). Doesn't the form >> (cffi:use-foreign-library libgsl) >> at the end of init/init.lisp fail with some kind of reasonable >> error message if it doesn't find the libraries? What else >> is needed? > > I am a beginner of both lisp and lisp packages and I remember that I > got a very puzzled when I just started using gsll. After testing > different combination of packages (stable and unstable) I finally > managed to installed all the packages successfully (gentoo). Then I > tried the > > (asdf:operate 'asdf:load-op :gsll) > > in sbcl. And I got tons of messages and error messages: > > *put last in email for readability Generally speaking in any programming language, you should look at the *first* error message and try to figure out what caused it. Granted, that's not always easy to find, but in your case it is actually coming from gcc, > error: ffi.h: No such file or directory which indicates that it can't find the path to the libffi header file, used by FSBV. This is a common problem unfortunately. I threw up my hands at trying to solve this in general. If anyone has any ideas, I'd like to know it. As for stopping the run-on error messages so that it's easier to find the first one, it would be nice, but again, I don't know how to do that. Perhaps the CFFI mailing list would help. > > And because there were so much information (compile messages and error > messages) I had no clue how to continue. Either I hadn't really > installed the packages correctly (gentoo) or I had a problem with > gsll. Then, when I finally got it to compile (with the help from here > by the way, thanks) it was not really obvious for me that everything > was successful. That does take some getting used to. Unfortunately that's more a product of the compiler and not really anything GSLL can do. Some compilers and environments are better than others. > > So, maybe it is redundant for most people but it would be very helpful > to have some sort of checklist / getting started, on the web page, to > be able to see what is working and not. Especially as there are 4-5 > packages that needs to be installed, and people are using different > systems (Ubuntu, Debian, Gentoo or just git) and will end up with > different versions. > > Or maybe, a summery at the very end of the (asdf:operate 'asdf:load-op > :gsll), saying that everything went as expected or which part that > went wrong. I'm not sure what you mean here. A checklist of what? "Getting started" in general is hard because of the tremendous variety of implementations and operating systems, where output looks very different. You can see on the web page I provided installation instructions, and I'm going to remove most of it because it is incomplete and too hard to make complete. It is also unwise to rely on features that may change or be unsupported because then it's a headache to maintain. I sympathize with the difficulty of interpreting output from an unfamiliar system, and distinguishing success from failure, but I don't see how GSLL can overcome that. I can't think of any other CL system that does something like think; if someone knows of something, we could copy it and adapt it to GSLL. Liam > > // NIK > > * > ; loading system definition from /usr/share/common-lisp/systems/c-array.asd > ; into #<PACKAGE "ASDF0"> > ; registering #<SYSTEM C-ARRAY {10026C51D1}> as C-ARRAY > ; compiling file "/usr/share/common-lisp/source/fsbv/init.lisp" > (written 01 MAR 2010 11:39:35 PM): > ; compiling (IN-PACKAGE :COMMON-LISP-USER) > ; compiling (DEFPACKAGE :FOREIGN-STRUCTURES-BY-VALUE ...) > ; compiling (CFFI:LOAD-FOREIGN-LIBRARY "libffi.so") > ; compiling (PUSHNEW :FSBV ...) > > ; /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/init.fasl > written > ; compilation finished in 0:00:00 > ; cc -m64 -fPIC -o > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c > > debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" > RUNNING {10023F6A01}>: > External process exited with code 1. > Command was: "cc" "-m64" "-fPIC" "-o" > "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix" > "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c" > Output was: > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:7:17: > error: ffi.h: No such file or directory > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c: > In function ‘main’: > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40: > error: ‘FFI_OK’ undeclared (first use in this function) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40: > error: (Each undeclared identifier is reported only once > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40: > error: for each function it appears in.) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:45: > error: ‘FFI_BAD_TYPEDEF’ undeclared (first use in this function) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:50: > error: ‘FFI_BAD_ABI’ undeclared (first use in this function) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:61: > error: ‘FFI_DEFAULT_ABI’ undeclared (first use in this function) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:66: > error: ‘FFI_SYSV’ undeclared (first use in this function) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:71: > error: ‘FFI_UNIX64’ undeclared (first use in this function) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:79: > error: ‘ffi_abi’ undeclared (first use in this function) > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:126: > error: invalid application of ‘sizeof’ to incomplete type ‘struct > _ffi_type’ > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:126: > warning: format ‘%i’ expects type ‘int’, but argument 3 has type ‘long > unsigned int’ > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:131: > error: dereferencing pointer to incomplete type > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:136: > error: dereferencing pointer to incomplete type > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:141: > error: dereferencing pointer to incomplete type > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:146: > error: dereferencing pointer to incomplete type > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c: > In function ‘print_double_for_lisp’: > /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:397: > warning: incompatible implicit declaration of built-in function > ‘memset’ > >> Liam >> >> On Tue, Apr 27, 2010 at 8:56 AM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: >> ... >>> >>> Good idea. Here is another one that would be useful even for the >>> pros. A gsll-probe, that would probe the system to make sure that >>> gsll is loadable. The main thing that comes to mind, and that can >>> look scary to a newbie is if the gsl libraries are not loadable. >>> >>> Along those lines, I was wandering if the gsll setup would be easier >>> if the user were required to set-up a feature *gsll-user* (or some >>> other such name. This symbol would have in its plist the gsl library >>> location. >>> >>> Mirko >> >

1 0

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

← Newer
1
...
8
9
10
11
12
13
14
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel