gsll-devel

gsll-devel@common-lisp.net

246 discussions

[Gsll-devel] inverse of cl-array
by Niitsuma Hirotaka 12 Feb '09

12 Feb '09

I can not find convert function #A(...) -> #m(...) ( cl-array is conversion #m -> #a ) Thus I write the following ,but that looks slow. -------------- (defun coerce-array-to-list (in-array) (map 'list #'identity (make-array (array-total-size in-array) :element-type (array-element-type in-array) :displaced-to in-array))) ;borrow from http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/a925ca60… (defun appropriate-name (element-type ar) (make-marray element-type :dimensions (array-dimensions ar) :initial-contents (coerce-array-to-list ar)) ) --------------- usage: ( appropriate-name 'double-float #2A((1.0d0 2.0d0) (2.0d0 5.0d0))) -> #m((1.0d0 2.0d0) (2.0d0 5.0d0)))

3 4

[Gsll-devel] Fwd: [clisp-list] Is this a bug, or does it violate the standard?
by Mirko Vukovic 02 Feb '09

02 Feb '09

See below for words of wisdom regarding loop and macros. I have seen that mentioned before. ---------- Forwarded message ---------- From: Pascal J. Bourguignon <pjb(a)informatimago.com> Date: Sun, Feb 1, 2009 at 9:59 PM Subject: Re: [clisp-list] Is this a bug, or does it violate the standard? To: clisp-list <clisp-list(a)lists.sourceforge.net> Cc: Mirko Vukovic <mirko.vukovic(a)gmail.com> On Feb 2, 2009, at 3:20 AM, Mirko Vukovic wrote: > > Indeed, the style "looked" bad, having a simple form in the middle of > compound forms.. The example was a distillation of a code from a > package that was compiling OK on SBCL, but failed on CLISP. > > I like the idea of macrolet. And I will remember the (progn ...) trick as well. Which reminds me to mention that LOOP shouldn't be used in the expansion of macros because of this kind of problems... When writting macros, it's safer to use DO, DO*, DOLIST, DOTIMES or even TAGBODY/GO in the expansion. -- __Pascal Bourguignon__ http://www.informatimago.com

1 1

Re: [Gsll-devel] with-ode-integration macro problem on clisp
by Liam Healy 02 Feb '09

02 Feb '09

On Sun, Feb 1, 2009 at 9:17 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: > According to folks on the clisp mailing list and hyperspec > (http://www.lispworks.com/documentation/HyperSpec/Body/06_aaaa.htm), > the bodies of simple loops can contain only *compound forms*. So, the > original code was out of spec. Live and learn :-) So it is. Who knew. If you have a git patch you can email, go ahead and send it, I will apply it (I've never applied a git patch from email, but I'll figure it out) and check it in. While you're chasing down CLISP problems, I noticed a bunch of them when running the tests. If those problems turn out to be in GSLL we should try to patch them up. Liam

1 0

Re: [Gsll-devel] with-ode-integration macro problem on clisp
by Liam Healy 02 Feb '09

02 Feb '09

On Sun, Feb 1, 2009 at 7:26 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: > On Sat, Jan 31, 2009 at 10:23 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> Mirko, >> >> It looks like there is a bug there in CLISP; symbol-macrolet is a part >> of the standard and it should work. I have given up on testing in >> CLISP because I encounter so many errors that seem to be a problem on >> their side. If you can get a useful answer out of CLISP, that's >> great, but you should switch to SBCL or CCL if you can because I do >> test on these. > > Liam, I use SBCL at work on my linux box. But at home I have a > windows laptop where I use clisp on cygwin. I have not ventured yet > into using the windows version of SBCL -- if you have heard of user > stories about that I would love to hear them. > > If I do find `fixable' problems on CLISP, do you want me to post them here? If the problem is not due to a bug in CLISP, by all means, post it here. If it is some grey area where CLISP has a problem with some arguably-acceptable construct in GSLL, I will consider changing it if it reasonably straightforward to do so. Maybe using a flet or labels is a workaround for the present problem, but from your description symbol-macrolet is being incorrectly compiled in CLISP. By the way, I put in the :cygwin feature switch in init.lisp for you. Does that work OK? > > >> >> As to whether it should be a symbol-macro or a function call I think >> it is a style issue. I'm not terribly happy with the macro as it is, >> I think it requires rethinking anyway, I just hacked through it to get >> something out that would get rid of the with-c-double. I'll return to >> it at some point but I have other things I'm working on first. > > I may need to use it in the next few weeks. If I come up with > something more `elegant', I will post it. > > Maybe something like > > (with-ode-stepper (stepper ...) > ... > (do-ode-steps (stopping-test) > (post-step-form)) > ... > ) That looks OK. > > I will post the offending example code on the clisp group to get their feedback. OK. > Mirko > Liam

1 0

[Gsll-devel] with-ode-integration macro problem on clisp
by Mirko Vukovic 01 Feb '09

01 Feb '09

Liam, The file `ode-example.lisp' could not compile on clisp+cygwin+windows. The error occurred in `integrate-vanderpol', which uses the `with-ode-integration' macro. I traced the problem to the symbol-macrolet generated macro `make-next-step'. It looks like the loop body cannot digest symbols created with symbol-macrolet (again clisp only, not sbcl). I was able to fix the problem by changing make-next-step into a function via labels. I am attaching a file that illustrates the problem, fix and verification. It has has several items: 1) illustration with a simple code on where clisp fails when loop uses a symbol-macrolet based symbol 2) the modified with-ode-integration macro 3) a version of integrate-vanderpol based on the modified macro 4) an example of a test-suite where I compared the outputs of your macro with the modified macro, using your examples of integrating vanderpol. This issue is not a major show-stopper for me, since I have a working version now. I can see why make-next-step should be defined as a symbol-macro -- it is so simple. On the other hand, strictly visually, its appearance as a symbol in the body of the loop between two forms is a bit jarring. Also, make-next-step is an `internal' symbol to the with-ode-integration macro, and maybe should not be visible to the user. But all of the above are really, minor, minor points, because the user is free to write their own version of `with-ode-integration' :-) The major point is really that sooner or later someone else will try to compile on clisp and hit the same problem. Mirko

2 1

[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 26 Jan '09

26 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

[Gsll-devel] gsll+clisp+cygwin
by Mirko Vukovic 27 Dec '08

27 Dec '08

Hello, I was able to load gsll on cygwin by pointing to cygwin's gsll libraries in gsll/init/init.lisp file. I am attaching the modified version. It also makes a note for making gsll loadable from within slime+emacs_NT (tested with cygwin+clisp) Mirko

2 3

← Newer
1
...
18
19
20
21
22
23
24
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel