gsll-devel November 2009

gsll-devel@common-lisp.net

3 participants
9 discussions

[Gsll-devel] clisp&cffi: broken foreign functions in saved images
by Sam Steingold 06 Jan '10

06 Jan '10

Hi, I do this: $ clisp -x '(asdf:operate 'asdf:load-op :gsll) (saveinitmem "gsll" :executable t)' $ ./gsll > > (gsll:make-chebyshev 1) FFI::FOREIGN-CALL-OUT: no dynamic object named "gsl_cheb_alloc" in library :DEFAULT this indicates a bug somewhere between cffi and gsll. specifically, the definition of the foreign function gsl_cheb_alloc should specify that it is to be found in "libgsl.so", not in :default. moreover, when I do the (not so) trivial thing: (ffi:default-foreign-language :stdc) (ffi:open-foreign-library "libgslcblas.so") (ffi:def-call-out gsl_cheb_alloc (:library "libgsl.so") (:arguments (n ffi:int)) (:return-type ffi:c-pointer)) (gsl_cheb_alloc 10) ;; ==> #<FOREIGN-ADDRESS #x0000000005503380> (saveinitmem "foo" :executable t) (quit) ./foo (ffi:open-foreign-library "libgslcblas.so") (gsl_cheb_alloc 10) #<FOREIGN-ADDRESS #x0000000001D9F4C0> i.e., if the foreign function definition includes the correct library name, the function will work automatically[*] even in the saved image. So, since I am not quite sure where the bug is hiding, I am reporting this to both gsll and cffi lists. Thanks. Sam. [*] apparently, libgsl.so cannot be loaded before libgslcblas.so is. how do people specify such dependencies?!

2 7

[Gsll-devel] ODE apply-step: argument passing problem
by Mirko Vukovic 04 Dec '09

04 Dec '09

Hi, I am trying to solve a second order ODE by calling a stepper for a number of fixed-size steps. I am getting an error about conversion to foreign type c-pointer. I modeled my call to `apply-step' based on `apply-evolution'. Looking at the source files, that is likely not to work because `apply-evolution' uses c-pointers, and `apply-step' makes direct variable references. But I don't know how to deal with those - my C and CFFI knowledge are non-existent. Anyway, here is a sample code that I hope someone can improve: ;;;; Example of a simple time-stepper (defun sin-ode (time y z) "Define ODE for a sinusoid y''=-y or as a system: y'=z z'=-y with initial conditions: y0=0 z0=1 " (declare (ignore time)) (values z (- y))) (defun sin-ode-jacobian (time y z) (declare (ignore time y z)) (values 0d0 0d0 0d0 1d0 -1d0 0d0)) #| (let ((time 0d0) (delta-t 0.1d0) (stepper-type +step-rk2+)) (let ((stepper (make-ode-stepper stepper-type 2 #'sin-ode #'sin-ode-jacobian)) (dep (make-marray 'double-float :dimensions 2)) (dydt-in (make-marray 'double-float :dimensions 2)) (dydt-out (make-marray 'double-float :dimensions 2)) (yerr (make-marray 'double-float :dimensions 2))) (setf (maref dep 0) 0d0 (maref dep 1) 1d0) (dotimes (i 10) (incf time delta-t) (apply-step stepper time dep delta-t yerr dydt-in dydt-out)))) |# BTW, once this is working, I will submit it as a patch to the ode-examples.lisp file Thanks, Mirko

2 4

[Gsll-devel] solve-tridiagonal example
by Mirko Vukovic 14 Nov '09

14 Nov '09

Hi Liam, here is a file with an example for the tridiagonal matrix solver (it may eventually contain more examples, thus its name). Since the output of the example is defined as a sequence of squares, you may add it as a test. BTW, I don't feel comfortable yet modifying the master repo, thus the email. Mirko

2 1

Re: [Gsll-devel] Added evaluate-integral-example
by Liam Healy 13 Nov '09

13 Nov '09

Thanks Mirko. I've committed those patches, and then made some simplifications and added a test based on that function. One of the simplifications I made was the :acceleration argument for all spline functions now defaults to (make-acceleration). Liam On Wed, Nov 11, 2009 at 8:39 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: > Hi Liam, > > I em enclosing the results of `git format-patch origin' > > Mirko > > On Wed, Nov 11, 2009 at 9:18 AM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> >> Hi Mirko, >> >> Thank you for the contribution. There are a couple ways you can make >> your patches available. You can email them using format-patch; see >> http://book.git-scm.com/5_git_and_email.html and git help >> format-patch, or you can fork the repository somewhere public like >> repo.or.cz or github and I can pull your commit(s). In the latter >> case of course send an email to the list alerting everyone to the URL >> and what it is you've done. >> >> In the case of small separate changes/additions like this, email >> probably makes the most sense. For more extended development, a >> separate repository would be easier. >> >> Contributions are very welcome, and anyone who would like to submit >> something is invited to do so in one of these ways. >> >> Liam >> >> >> On Wed, Nov 11, 2009 at 7:46 AM, Mirko Vukovic <mirko.vukovic(a)gmail.com> >> wrote: >> > Hi, >> > >> > I have added the following example of `evaluate-integral' to >> > spline-example.lisp: >> > >> > (defun evaluate-integral-example (&optional (intervals 4)) >> > "Evaluate integral of sin(x) in interval 0-pi. sin(x) is tabulated >> > over a 0-2pi interval and interpolated with >> > +periodic-cubic-spline-interpolation+" >> > (let* ((nodes (1+ intervals)) >> > (max-node (1- nodes)) >> > (xarr >> > (loop >> > with step = (/ (* 2.0 pi) intervals) >> > for i from 0 upto max-node >> > collect (* i step))) >> > (xmarr (make-marray 'double-float :initial-contents xarr)) >> > ;; cannot use (loop for x on (cl-array xmarr)...) -- c function >> > gives >> > error >> > (ymarr >> > (make-marray 'double-float :initial-contents >> > (loop for x in xarr >> > collect (sin x)))) >> > (acc (make-acceleration)) >> > (spline (make-spline +periodic-cubic-spline-interpolation+ xmarr >> > ymarr))) >> > (evaluate-integral spline 0d0 (coerce pi 'double-float) :acceleration >> > acc))) >> > >> > Right now it is sitting in the `master' branch on my laptop. How would >> > you >> > like me to upload it. As a master, or something else? >> > >> > Mirko >> > >> > _______________________________________________ >> > Gsll-devel mailing list >> > Gsll-devel(a)common-lisp.net >> > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel >> > >> > > >

1 0

[Gsll-devel] Added evaluate-integral-example
by Mirko Vukovic 11 Nov '09

11 Nov '09

Hi, I have added the following example of `evaluate-integral' to spline-example.lisp: (defun evaluate-integral-example (&optional (intervals 4)) "Evaluate integral of sin(x) in interval 0-pi. sin(x) is tabulated over a 0-2pi interval and interpolated with +periodic-cubic-spline-interpolation+" (let* ((nodes (1+ intervals)) (max-node (1- nodes)) (xarr (loop with step = (/ (* 2.0 pi) intervals) for i from 0 upto max-node collect (* i step))) (xmarr (make-marray 'double-float :initial-contents xarr)) ;; cannot use (loop for x on (cl-array xmarr)...) -- c function gives error (ymarr (make-marray 'double-float :initial-contents (loop for x in xarr collect (sin x)))) (acc (make-acceleration)) (spline (make-spline +periodic-cubic-spline-interpolation+ xmarr ymarr))) (evaluate-integral spline 0d0 (coerce pi 'double-float) :acceleration acc))) Right now it is sitting in the `master' branch on my laptop. How would you like me to upload it. As a master, or something else? Mirko

2 1

[Gsll-devel] Possible use of user-supplied vector sizes and offsets for FFT
by Sumant Oemrawsingh 05 Nov '09

05 Nov '09

Hi Liam, As I briefly indicated on #lisp and contrary to our earlier belief, there _is_ at least one case in which a user would like to supply the stride, vector size n and offset to the FFT functions. Namely, this is for the 2-dimensional (more generally of course, N-dimensional) Fourier transform. GSL only provides one-dimensional FFTs. Naturally, an N-dimensional FFT can be easily implemented from a one-dimensional function. From saying this, you can probably already immediately see what I mean, but nevertheless, to be sure there's no mistake here, I'll give a more concrete example. Let us approach the problem in C, and consider a 2D array of size a x b, where a is the number of rows and b is the number of columns. This is a linear, contiguous array in C (a "raw" C array). A 2D FFT can be performed by first FFT'ing one dimension and then the other. Thus, we first FFT each row, and then each column. The order actually doesn't matter. In C, this would be handled by first performing a times the (forward) FFT, thus applying an FFT to each row, where the vector size n = b, the stride = 1 and each consecutive FFT call supplies the vector with an offset with a multiple of b. Next up is the FFT of each column. In C we perform b times the (forward) FFT, thus applying an FFT to each column where the vector size n = a, the stride = b, and each consecutive FFT call supplies the vector with an offset equal to the column number. For N-dimensional arrays, simply lather, rinse and repeat. This shows the necessity of the optional (keyword?) argument that indicates the size of the vector to be FFT'd, the stride (which is already in there) and also the offset (which is missing at the moment). This also shows that the Fourier transform environment that is in fft-interface.lisp is very nice to have, when dealing with non-radix-2 array lengths. Each consecutive call when FFT-ing in one direction only needs to allocate the workspace and wavetable once and, more importantly, calculate the wavetable once, while the FFT is repeated on each row (or column). I have to admit that I haven't looked at how multi-dimensional marrays or more correctly, marrays representing tensors of rank > 1, from the GSLL point of view. As I understand, the interface allows for a truly multi-rank approach (using maref with multiple indices), as with the normal CL arrays and aref. In my opinion, a nice approach would be to make the whole FFT by default work on the entire marray, thus performing multi-dimensional FFTs when marrays have higher ranks. That way, we can hide the messing about with strides, sizes and offsets from the user. Just think, loading an image into a marray, and just calling forward-fourier-transform, and instantly (depending on the speed of your computer...) have a Fourier-space image! On the other hand, while such an interface would be nice for the casual user (and probably for most normal users) I don't know if there are "power users" that (would want to use GSL's FFT functions, and) would require direct control over such parameters. As I may have mentioned before on #lisp, I have used GSL's FFT some time ago, as well as FFTW briefly. FFTW has functions for higher-dimensional FFTs, and deducing from that interface, I would say that an FFT function that "does the right thing (TM)" depending on the rank of the marray would not be so bad. Anyway, sorry for the long post. I hope my explanations/considerations/ideas are useful and I would not mind implementing some/most of this in an experimental interface, possibly with some help with respect to some of the fancy internals of GSLL. Please let me know what you think (and any suggestions from users of GSLL and FTT, I'm looking at you, Mirko...) are greatly appreciated! Thanks, Sumant

2 3

[Gsll-devel] Irregular function names in FFT
by Liam Healy 01 Nov '09

01 Nov '09

Sumant, I think this is the way to go for the irregular function names that are used for the FFT functions: (defmfun forward-fourier-transform ((vector vector) &key (stride 1) (n (expt 2 (floor (log (size vector) 2))))) (double-float "gsl_fft_real_radix2_transform" single-float "gsl_fft_real_float_radix2_transform" complex-double-float "gsl_fft_complex_radix2_forward" complex-single-float "gsl_fft_complex_float_radix2_forward") (((c-pointer vector) :pointer) (stride sizet) (n sizet)) :definition :generic :element-types :float-complex :inputs (vector) :outputs (vector) :return (vector) :documentation "Forward FFT for a real radix-2 vector") Check the expansion to see if it is doing the right thing. Note the example eigenvalues-gensymm in eigensystems/generalized.lisp for another case with irregular names in GSL. Liam

1 0

[Gsll-devel] Repository corruption
by Liam Healy 01 Nov '09

01 Nov '09

I have found today that trying to clone or fetch from the "push" URL ssh://repo.or.cz/srv/git/gsll.git gives me an error: git clone ssh://repo.or.cz/srv/git/gsll.git Initialized empty Git repository in /tmp/gsll/.git/ error: git-upload-pack: git-pack-objects died with error. remote: fatal: exec pack-objects failed. fatal: git-upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed I don't seem to have a problem cloning from http://repo.or.cz/r/gsll.git but I can't push to that. Also I can clone/fetch from either URL at the mirror site http://common-lisp.net/gitweb?p=projects/gsll/gsll.git;a=summary but I'm not sure how pushing to that would work, since it's set up to mirror repo.or.cz. Is anyone enough of a git expert to know what to do here? My last-resort move would be to delete the whole repository and re-push it to repoo.or.cz and see if that will fix the problem (provided repo.or.cz lets me do that), but that seems rather drastic. Thanks, Liam

2 3

[Gsll-devel] fast-fourier-transform branch in repo.or.cz
by Sumant Oemrawsingh 01 Nov '09

01 Nov '09

Hey guys, As discussed on #lisp with LiamH, I have pushed a branch containing some preliminary stuff to get GSL's FFTs working. Unsurprisingly, the branch is called fast-fourier-transform, and should actually be easily merged with master without causing things to break. I just thought to make a branch out of it in case I totally, completely and utterly break stuff, since these are my first contributions to GSLL and my first non-trivial experience with git. What is implemented: All complex FFT (double and single floats) are implemented. What works/is tested: radix 2 and mixed radix stuff is working and tested with the examples in the manual. I will push the examples translated to lisp as well when I clean it up. What isn't tested: The decimation-in-frequency functions are implemented, but I have no idea what they are supposed to do. Over the next days, I will be implementing the real transforms as well, test all the functions with respect to their C counterparts and finally make some nicer wrapper functions around them (unless people are radically opposed to that). Thanks, Sumant Oemrawsingh (Sikander on #lisp)

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel November 2009