gsll-devel

gsll-devel@common-lisp.net

246 discussions

[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 15 Nov '09

15 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

[Gsll-devel] GSLL utility development
by Malcolm Reynolds 19 Oct '09

19 Oct '09

Hi all, I've exchanged a few emails with Liam about trying to add some functionality to GSLL that goes beyond what is found in GSL, to try and make a more useful overall platform for working with Matrices and Vectors. My personal aim is to make CL a viable alternative to MATLAB which in my field (Machine Learning / Computer Vision) is a de facto standard for quickly messing around with data. I plan to use GSLL for as much of my work as I can, and when I end up having to write any general utilities, try to get them into the main codebase. Liam said there was some related chat on #lisp so it seems sensible to take our discussion to the mailing list where maybe more people will have ideas / want to contribute. My current efforts to this end are found in http://github.com/malcolmreynolds/GSLL - look in the branch malcolm-utils and then the utils/ directory. Nothing earthshaking, just some matrix looping macros and concatenation functions, but I plan to continue adding things here. I apologise in advance for my code, I'm still pretty new to CL, so if you read something and say 'ewww', please tell me how I could do it better! Hopefully at some point this will be incorporated into the main GSLL tree, but for the time being I'll continue hacking on this as and when I think of something I should add. Ideas welcome! Cheers, Malcolm

2 2

[Gsll-devel] gsll compilation with sbcl 1.0.30
by Simon Holgate 17 Sep '09

17 Sep '09

Hello, this is my first post to the list. I've tried the archives but not found an answer. Apologies if this has come up before. I've successfully installed gsll previously under SBCL, with a system-wide SBCL install, and everything worked just fine. On my current system I've had to install everything under my local user directory and SBCL (1.0.30) has been installed there too, compiled from source. I've installed all the dependencies but I get a problem on compilation. I've pasted all the output below. The issue seems to be with CFFI-GROVEL and I guess that it can't find libgsl. That is also installed locally under $HOME/lib and is exported in my LD_LIBRARY_PATH. Is there some other way to point to libgsl or have I got the wrong end of the stick? BTW when first compiling I also got an error (which isn't replicated below) about not being able to find "gsl_version" and something to do with a missing "ALIEN-..."? The host system is SUSE (SLED 10). Any help would be much appreciated. Thanks, Simon Output from SBCL was: * (require 'asdf) ("ASDF") * (asdf:operate 'asdf:load-op :gsll) ; loading system definition from /login/simonh/.sbcl/systems/gsll.asd into ; #<PACKAGE "ASDF0"> ; loading system definition from /login/simonh/.sbcl/systems/fsbv.asd into ; #<PACKAGE "ASDF1"> ; loading system definition from /login/simonh/.sbcl/systems/cffi-grovel.asd ; into #<PACKAGE "ASDF2"> ; registering #<SYSTEM CFFI-GROVEL {AD3DDD9}> as CFFI-GROVEL ; loading system definition from /login/simonh/.sbcl/systems/alexandria.asd ; into #<PACKAGE "ASDF2"> ; registering #<SYSTEM :ALEXANDRIA {B18FCA1}> as ALEXANDRIA ; loading system definition from /login/simonh/.sbcl/systems/cffi.asd into ; #<PACKAGE "ASDF2"> ; registering #<SYSTEM CFFI {B37BD09}> as CFFI ; loading system definition from /login/simonh/.sbcl/systems/babel.asd into ; #<PACKAGE "ASDF2"> ; registering #<SYSTEM BABEL {B4E9BA9}> as BABEL ; loading system definition from ; /login/simonh/.sbcl/systems/trivial-features.asd into #<PACKAGE "ASDF2"> ; registering #<SYSTEM TRIVIAL-FEATURES {AA30489}> as TRIVIAL-FEATURES ; registering #<SYSTEM :FSBV {AD0E019}> as FSBV ; registering #<SYSTEM "gsll" {AFA1949}> as gsll ; loading system definition from /login/simonh/.sbcl/systems/cl-utilities.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM CL-UTILITIES {B18FD31}> as CL-UTILITIES ; loading system definition from ; /login/simonh/.sbcl/systems/trivial-garbage.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM TRIVIAL-GARBAGE {A939841}> as TRIVIAL-GARBAGE ; registering #<SYSTEM TRIVIAL-GARBAGE-TESTS {AA79521}> as TRIVIAL-GARBAGE-TESTS debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {A9007A9}>: The value NIL is not of type PACKAGE. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [TRY-RECOMPILING] Try recompiling libgsl 1: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {AFFFC71}> on #<CFFI-GROVEL:GROVEL-FILE "libgsl" {BAFB3D1}>. 2: [ACCEPT ] Continue, treating #<ASDF:COMPILE-OP NIL {AFFFC71}> on #<CFFI-GROVEL:GROVEL-FILE "libgsl" {BAFB3D1}> as having been successful. 3: [ABORT ] Exit debugger, returning to top level. ((LABELS CFFI-GROVEL::PROCESS-FORM) (IN-PACKAGE :GSL)) 0] 0 debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {A9007A9}>: The value NIL is not of type PACKAGE. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [TRY-RECOMPILING] Try recompiling libgsl 1: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {AFFFC71}> on #<CFFI-GROVEL:GROVEL-FILE "libgsl" {BAFB3D1}>. 2: [ACCEPT ] Continue, treating #<ASDF:COMPILE-OP NIL {AFFFC71}> on #<CFFI-GROVEL:GROVEL-FILE "libgsl" {BAFB3D1}> as having been successful. 3: [ABORT ] Exit debugger, returning to top level. ((LABELS CFFI-GROVEL::PROCESS-FORM) (IN-PACKAGE :GSL)) 0] 3 ; ; compilation unit aborted ; caught 1 fatal ERROR condition * (quit) -- **x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x**x** Dr. Simon Holgate, Permanent Service for Mean Sea Level, Proudman Oceanographic Laboratory, Joseph Proudman Building, 6 Brownlow Street, Liverpool L3 5DA, England Tel: +44 (0) 151 795 4900 (direct), +44 (0) 151 795 4800 (switchboard) FAX: +44 (0) 151 795 4801 http://www.pol.ac.uk/home/staff/?user=HolgSimo == -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

1 1

← Newer
1
...
13
14
15
16
17
18
19
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel