gsll-devel January 2009

gsll-devel@common-lisp.net

2 participants
5 discussions

[Gsll-devel] GSLL release preview
by Liam Healy 13 Feb '09

13 Feb '09

GSLL users, I have set up a new repository for GSLL using git. This repository contains the latest version, which has undergone considerable change since the latest version in the subversion repository. I intend to release it soon. Changes include: - All objects are memory managed (garbage collected), which means they can have indefinite extent like any other lisp object. There is no need to put the object creation in a letm; in fact letm doesn't exist anymore. Use let, or defparameter, etc. - All array (vector and matrix) element types that are supported by the platform, CL implementation, CFFI, and GSL, are supported by GSLL. - Arrays on SBCL are native, meaning that they are not copied between the Lisp side and the C side, but both sides use the same memory locations. Thanks to Tamas Papp's foreign-friendly arrays for the inspiration. Before making a formal release, I will need to write some documentation. However, I thought some people might want to get going early, so I have set up the repository and anyone can clone it or download the tarball. You'll find what is in the documentation directory partially updated but not totally; however, if you do (examples) you will see a list of categories, and if you do (examples name) where name is one of the categories you will get a list of examples. Each of those examples is correctly constructed, though some are designed to give errors. Please note that the interface for many functions has changed. This is the repository project page: http://repo.or.cz/w/gsll.git To check out your own copy, do git clone git://repo.or.cz/gsll.git and periodically update with git pull origin The page http://common-lisp.net/project/gsll/ will continue to be the project web page, but for the time being still refers to the old version. As always, please use this mailing list to let everyone know how it is working and any problems. Posting examples, especially working ones, is very welcome. I will be checking in revisions so you should periodically update. Liam

2 2

[Gsll-devel] Correction for integral-evaluate-spline
by Mirko Vukovic 29 Jan '09

29 Jan '09

Hello, In order to use integral-evaluate-spline, I had to modify its definition. The one below works, but I am not sure if there is a better way. Here is the definition: (defmfun integral-evaluate-spline (spline xa ya low high acceleration) "gsl_spline_eval_integ" (((mpointer spline) :pointer) ((c-pointer xa) :pointer) ((c-pointer ya) :pointer) (low :double) (high :double) ((mpointer acceleration) :pointer)) :c-return :double :documentation ; FDL "Find the numerical integral of an interpolated function over the range [low, high], using the spline object spline, data arrays xa and ya and the accelerator acceleration.") I removed a reference to a double-float `x' and added the x&y array pointers into the arguments, as they are necessary for gsl's `gsl_interp_eval_integ'. (I am really not sure what is the purpose of the ..._e functions). Here is a bit of test code that exercises the defintion by integrating pi*sin(pi x) between 0 & 0.5 which should equal 1.0: (let* ((acc (make-acceleration)) (xarr (make-marray 'double-float :initial-contents (loop for i from 0.0d0 below 1d0 by 0.2d0 collect i))) (yarr (make-marray 'double-float :initial-contents (loop for x across (cl-array xarr) collect (sin (* x pi))))) (spline (make-spline *cubic-spline-interpolation* xarr yarr))) (* pi (integral-evaluate-spline spline xarr yarr 0d0 0.5d0 acc))) I wonder if there is a way for `make-spline' to "remember" xarr and yarr so they don't have to be passed to `integral-evaluate-spline'. As always, thank for the heavy lifting :-) Mirko

2 3

[Gsll-devel] integral-evaluate-spline crashes for xarr containing containing negative numbers
by Mirko Vukovic 28 Jan '09

28 Jan '09

Hello. To illustrate the problem consider the following routine (defun spline-integration-example (&optional (lower-limit 0d0)) "Integral of pi * sin (pi x) between 0 and 0.5. Should come close to 1.0" (let* ((acc (make-acceleration)) (xarr (make-marray 'double-float :initial-contents (loop for i from lower-limit below 1d0 by 0.2d0 collect i))) (yarr (make-marray 'double-float :initial-contents (loop for x across (cl-array xarr) collect (sin (* x pi))))) (spline (make-spline *cubic-spline-interpolation* xarr yarr))) (* pi (integral-evaluate-spline spline xarr yarr 0d0 0.5d0 acc)))) Doing (spline-integration-example) gives 1.0000108... Doing (spline-integration-example -0.1d0) causes an error: Unhandled memory fault at #x0. [Condition of type SB-SYS:MEMORY-FAULT-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT] Exit debugger, returning to top level. What is interesting are is the environment prior to the call to integral-evaluate-spline (#7 below): Backtrace: 0: (SB-SYS:MEMORY-FAULT-ERROR) 1: ("foreign function: #x41A9A2") 2: ("foreign function: #x41AA80") 3: ("foreign function: #x2AE6C85E1D1B") 4: ("foreign function: #x2AE6C85E4683") 5: ("foreign function: #x2AE6C85E541A") 6: ("foreign function: #x2AE6C85E5F93") 7: (INTEGRAL-EVALUATE-SPLINE ..) Locals: SB-DEBUG::ARG-0 = #<SPLINE {10039177D1}> SB-DEBUG::ARG-1 = #<VECTOR-DOUBLE-FLOAT #(-0.1d0 0.1d0 0.30000000000000004d0 0.5d0 0.7d0 ..)> SB-DEBUG::ARG-2 = #<VECTOR-DOUBLE-FLOAT #(-0.3090169943749474d0 0.3090169943749474d0 ..)> SB-DEBUG::ARG-3 = 0.5d0 SB-DEBUG::ARG-4 = 3.395932351202108d-313 SB-DEBUG::ARG-5 = #<ACCELERATION {1003910A71}> 8: (SPLINE-INTEGRATION-EXAMPLE -0.1d0) 9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SPLINE-INTEGRATION-EXAMPLE -0.1d0) #<NULL-LEXENV>) --more-- Arguments 3 & 4 are incorrect !. They should be 0d0 and 0.5d0. I don't have a clue how that happens. btw, I am using my definition of integral-evaluate-spline, which I posted earlier today: (defmfun integral-evaluate-spline (spline xa ya low high acceleration) "gsl_spline_eval_integ" (((mpointer spline) :pointer) ((c-pointer xa) :pointer) ((c-pointer ya) :pointer) (low :double) (high :double) ((mpointer acceleration) :pointer)) :c-return :double :documentation ; FDL "Find the numerical integral of an interpolated function over the range [low, high], using the spline object spline, data arrays xa and ya and the accelerator acceleration.") Thanks to the properties of integrals, this problem is not a show-stopper. Just shifting the integration axis will do the job. But it is annoying :-) Hope Liam can help finding the fix. Mirko

2 2

[Gsll-devel] spline-example fails
by Mirko Vukovic 27 Jan '09

27 Jan '09

Hello, I downloaded the latest snapshot of gsll, and I cannot get spline-example to work. Currently, the :dimensions argument to make-marray is a lisp array, while it requests a list of dimensions. I made some progress by definining xarr and yarr using make-marray, (multiple-value-bind (xarr yarr) (let ((xarr (make-marray 'double-float :dimensions '(10))) (yarr (make-marray 'double-float :dimensions '(10)))) (loop for i from 0 below 10 do (setf (maref xarr i) (+ i (* 0.5d0 (sin (coerce i 'double-float)))) (maref yarr i) (+ i (cos (expt (coerce i 'double-float) 2))))) (values xarr yarr)) (let* ((acc (make-acceleration)) (spline (make-spline *cubic-spline-interpolation* xarr yarr))) (loop for xi from (maref xarr 0) below (maref xarr 9) by 0.01d0 collect (list xi (evaluate-spline spline xi acc))))) but then evaluate-spline gives an error: The value #<SPLINE {10038D9FB1}> is not of type SB-SYS:SYSTEM-AREA-POINTER. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (EVALUATE-SPLINE #<SPLINE {10038D9FB1}> 3.395929557952573d-313 #<ACCELERATION {10038D9711}>) 1: ((LAMBDA ())) 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV ..) --more-- And that is a bit too deep for me :-( Any ideas? Thank you, Mirko

2 1

[Gsll-devel] Using gsll's lisp-unit extensions for the nlisp project
by Mirko Vukovic 27 Jan '09

27 Jan '09

Hello Liam, I believe that I am allowed to use your files `additional-definitions.lisp' for our purposes. Correct? I will off course keep all attributions to your work, and forward you any suggestions and additions. Thank you, Mirko

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel January 2009