February 2009 - gsll-devel - mailman3.common-lisp.net

[Gsll-devel] inverse-matrix-product
by Dmitri Hrapof 25 Feb '09

25 Feb '09

Hello! Just cloned git repository. In both SBCL 1.0.23 and ClozureCL 1.2-r11583M on Linux PPC, with GSL 1.9-3: CL-USER> (gsll:invert-matrix #m((1 0 2) (-1 3 1) (1 1 0))) #<MATRIX-DOUBLE-FLOAT #2A((0.11111111111111116D0 -0.2222222222222222D0 0.6666666666666666D0) (-0.11111111111111109D0 0.22222222222222224D0 0.3333333333333333D0) (0.4444444444444444D0 0.1111111111111111D0 -0.3333333333333333D0))> CL-USER> (gsll:matrix-product * #m(3 2 1)) #<VECTOR-DOUBLE-FLOAT #(0.5555555555555557D0 0.44444444444444453D0 1.222222222222222D0)> CL-USER> (gsll:inverse-matrix-product #m((1 0 2) (-1 3 1) (1 1 0)) #m(3 2 1)) #<VECTOR-DOUBLE-FLOAT #(1D+-0 #| not-a-number |# -1D++0 1D++0)> Do I misunderstand something? Sincerely yours, Dmitri PS and to add insult to injury ;) nonsymmetric-generalized.lisp fails to compile, complaining about invalid function call: ("gsl_eigen_gen" "gsl_eigen_gen_QZ")

3 6

[Gsll-devel] lu solution followed by triangular matrix multiplication example
by Mirko Vukovic 24 Feb '09

24 Feb '09

Hello, Here is a snippet of LU decomposition code that illustrates the decomposition, solution, and then solution check via blas based routines for triangular matrix multiplication: ;; decompose (lu-decomposition mat per) ;; solve for x given b (lu-solve mat per b x) ;; check by multiplying mat by x. But mat is now a product of tridiagonal matrices L and U. ;; The LUx multiplication is done in two stages as L(Ux). For the upper multiplication we ;; specify the matrix-product-triangular using the Upper and :NonUnit diagonal. ;; For the lower, we specify :Lower and :Unit diagonal (matrix-product-triangular mat (matrix-product-triangular mat x 1 :Upper :NoTrans :NonUnit) 1 :Lower :NoTrans :Unit)) One can off course save the matrix mat before the decomposition and then use a direct matrix multiplication. Mirko

2 2

[Gsll-devel] Typo in ode-system.lisp's with-ode-integration macro
by Mirko Vukovic 23 Feb '09

23 Feb '09

The `with-ode-integration' macro uses the *step-rk8pd*. I believe it should be +step-rk8pd+ Mirko

2 1

[Gsll-devel] Change to callbacks
by Liam Healy 16 Feb '09

16 Feb '09

GSLL users, I have made a change to how GSLL uses callbacks. Callbacks are functions that are sent as arguments to GSL in other functions. Previously, there were several macros specific to each application that defined both the callback function(s) and the GSL structure needed to hold them. Now, there is a single macro (make-callback) that must be called at top level that defines the callback function(s) previously defined with ordinary CL function(s) (e.g. with a defun). After that, any function that requires callbacks will be called by passing the symbol or list of symbols naming those functions. The needed callback structure is created dynamically. This will require a change to your code if you are using callbacks. I have updated the documentation appropriately; I recommend looking at the examples to figure out how to use callbacks in your own application. If you desperately want to keep the old version of callbacks, you can check out the tag "defcbstruct" from git, but there won't be any further development on that version. >From a user's perspective, it would be nice to eliminate the need for the make-callback. However, some CL implementations (Clozure in my experience at least) require that callback declarations be at top level, so the callback can't be constructed on the fly like the GSL callback structure. It might be possible someday to eliminate this requirement for other lisps like SBCL which don't have this restriction. Feedback welcome as always. Liam

1 0

[Gsll-devel] Forget that last email
by Zach 15 Feb '09

15 Feb '09

Sorry, too high strung the morning, I sent when I wanted to discard. I wanted to look at the source before I posted, so sorry again, Zach

1 0

[Gsll-devel] A few suggestions
by Zach 15 Feb '09

15 Feb '09

Liam and other developers GSLL has improved quite a bit from the last time I pulled the source. Thank you very much. I have a few suggestions that that I think might find a place in GSLL. These are from my own set of GSL bindings I have been using for work. 1. Using Lisp functions as callbacks. Check this out:

1 0

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

15 Feb '09

There is now a local function #'next-step to replace the symbol macro make-next-step. This is in the refactoring-callbacks branch which will eventually be merged into master. (Please keep gsll-devel in the cc when following up threads from the list so that others can follow the conversation. Thank you.) Liam On Sun, Feb 1, 2009 at 10:02 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: > On Sun, Feb 1, 2009 at 9:51 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> 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. > > Give me a few days. I have a conference to organize, and I have been > having too much fun with lisp :-) > >> >> 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. > > Yes, I saw them. Most of them were due to precision errors (reducing > tolerances helped), but there were a few that completely failed > (basis-spline among them). I will try to take a look, but nothing > will happen soon. > >> >> Liam >> >

1 0

[Gsll-devel] fixed documentation to step-apply in stepping.lisp
by Mirko Vukovic 15 Feb '09

15 Feb '09

Hello, In the documentation to step-apply, I changed the string t+h to t+step-size. The diff file was generated by `git diff ...' Mirko

2 1

[Gsll-devel] documentation patch for ode-system.lisp
by Mirko Vukovic 15 Feb '09

15 Feb '09

Hello, I reworded the documentation string for make-ode-functions. Not sure if that is too wordy. The diff file shows some changes to the body of that function, but please disregard that. I was playing with naming conventions in the body of the code, and then tried to put things back the way there in the original git distro. Mirko

2 1

[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] 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