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

[Gsll-devel] #m and *print-case*
by Leo 29 Mar '10

29 Mar '10

Hello, I notice that #m has two problems: 1. If (setf *print-case* :downcase), things like #m(1 2 3) fail. Here's the sldb buffer in slime: ---------------- Class named gsll::|vector-double-float| not found. [Condition of type simple-error] Restarts: 0: [continue] Try finding the class again 1: [retry] Retry SLIME REPL evaluation request. 2: [abort] Return to SLIME's top level. 3: [abort-break] Reset this thread 4: [abort] Kill this thread Backtrace: 0: (find-class gsll::|vector-double-float| t nil) Locals: ccl::name = gsll::|vector-double-float| ccl::errorp = t ccl::environment = nil ccl::cell = nil 1: (#<standard-method make-instance (symbol)> gsll::|vector-double-float| :initial-contents (1 2 3)) Locals: class = gsll::|vector-double-float| ccl::initargs = (:initial-contents (1 2 3)) ---------------- 2. #m (1 2 3) fails too Other reader macros does not err when there's a space follows it, for example: - ' (1 2 3) - # (1 2 3) This is a bit inconvenient because paredit.el automatically inserts a space behind m. Can these be fixed? Thanks. Leo -- H A P P Y H O L I D A Y S!

2 4

[Gsll-devel] how to make linear interpolation work?
by Mirko Vukovic 28 Mar '10

28 Mar '10

The following snippet: (let ((v1 #m(1d0 2d0 3d0)) (v2 #m(3d0 2d0 1d0))) (let ((interpolation (make-interpolation +linear-interpolation+ v1 v2)) (accel (make-acceleration))) (evaluate interpolation 2d0 :ya v2 :x1 v1 :acceleration accel))) throws an error on SBCL (1.0.34): There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION C-ARRAY:ORIGINAL-ARRAY (1)> when called with arguments (NIL). [Condition of type SIMPLE-ERROR] spline interpolation works. So, what am I missing? Mirko

2 1

[Gsll-devel] grid:map.lisp -- example code fails
by Mirko Vukovic 28 Mar '10

28 Mar '10

The following two examples from grid:map.lisp produce an error on clisp/cygwin ;;; Extract the diagonal, inject into a vector of length 6, with the ;;; first three elements set to a default value (map-grid :source *array-3-4-double-float* :source-affi (affi:diagonal (affi *array-3-4-double-float*)) :destination-affi (affi:make-affi '(6) 3) :default-value -77.7d0) ;;; Extract the diagonal, inject at index 3 into a vector of length 6, ;;; adding to the vector elements (map-grid :source *array-3-4-double-float* :source-affi (affi:diagonal (affi *array-3-4-double-float*)) :destination-affi (affi:make-affi '(6) 3) :default-value -77.7d0 :combination-function '+) The reported error is: ROW-MAJOR-AREF: index NIL for #2A((#1=0.0d0 1.0d0 2.0d0 3.0d0) (10.0d0 11.0d0 12.0d0 13.0d0) (20.0d0 21.0d0 22.0d0 23.0d0)) is not of type `(INTEGER 0 (,ARRAY-DIMENSION-LIMIT)) [Condition of type SIMPLE-TYPE-ERROR] I can make it work by using the destination-affi (make-affi '(3)), but not (make-affi '(4)) or larger. Mirko

2 1

[Gsll-devel] Correction to data/iterate.lisp file
by Mirko Vukovic 14 Mar '10

14 Mar '10

Liam, In order for gsll's iterate extensions to compile on sbcl, one needs to quote all the lambda expressions in the iterate.lisp file. Best, Mirko

2 2

[Gsll-devel] grid:make-grid bug?
by Mirko Vukovic 14 Mar '10

14 Mar '10

The following throws my clisp into an infinite loop: (grid:MAKE-GRID '((gsl:marray 3 3) DOUBLE-FLOAT) :INITIAL-CONTENTS #(0.5d0 1.5d0 2.5d0 3.5d0 0.1d0 1.1d0 10.5d0 11.5d0 12.5d0 13.5d0 10.1d0 11.1d0 20.5d0 21.5d0 22.5d0 23.5d0 20.1d0 21.1d0)) Am I misusing make-grid, or is this a bug? Thanks, Mirko

2 1

[Gsll-devel] Compilation error in fsbv/libffi-unix.c
by N J 03 Mar '10

03 Mar '10

Hey, When I run (asdf:operate 'asdf:load-op :gsll) in sbcl I get: ; loading system definition from /usr/share/common-lisp/systems/c-array.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM C-ARRAY {10026C51D1}> as C-ARRAY ; compiling file "/usr/share/common-lisp/source/fsbv/init.lisp" (written 01 MAR 2010 11:39:35 PM): ; compiling (IN-PACKAGE :COMMON-LISP-USER) ; compiling (DEFPACKAGE :FOREIGN-STRUCTURES-BY-VALUE ...) ; compiling (CFFI:LOAD-FOREIGN-LIBRARY "libffi.so") ; compiling (PUSHNEW :FSBV ...) ; /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/init.fasl written ; compilation finished in 0:00:00 ; cc -m64 -fPIC -o /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" RUNNING {10023F6A01}>: External process exited with code 1. Command was: "cc" "-m64" "-fPIC" "-o" "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix" "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c" Output was: /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:7:17: error: ffi.h: No such file or directory /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c: In function ‘main’: /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40: error: ‘FFI_OK’ undeclared (first use in this function) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40: error: (Each undeclared identifier is reported only once /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40: error: for each function it appears in.) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:45: error: ‘FFI_BAD_TYPEDEF’ undeclared (first use in this function) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:50: error: ‘FFI_BAD_ABI’ undeclared (first use in this function) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:61: error: ‘FFI_DEFAULT_ABI’ undeclared (first use in this function) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:66: error: ‘FFI_SYSV’ undeclared (first use in this function) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:71: error: ‘FFI_UNIX64’ undeclared (first use in this function) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:79: error: ‘ffi_abi’ undeclared (first use in this function) /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:126: error: invalid application of ‘sizeof’ to incomplete type ‘struct _ffi_type’ /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:126: warning: format ‘%i’ expects type ‘int’, but argument 3 has type ‘long unsigned int’ /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:131: error: dereferencing pointer to incomplete type /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:136: error: dereferencing pointer to incomplete type /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:141: error: dereferencing pointer to incomplete type /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:146: error: dereferencing pointer to incomplete type /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c: In function ‘print_double_for_lisp’: /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:397: warning: incompatible implicit declaration of built-in function ‘memset’ My packages and gits are: git://repo.or.cz/gsll.git 4fef622be12cf318e015b2ba5aba6c63d4296f1e master git://repo.or.cz/fsbv.git dd8025f51fd8272b725bd73bc0b1875bae2bcf5b master cffi-0.10.5 Thank you guys for any help NIK

4 6

[Gsll-devel] sbcl 1.0.35 & 1.0.36 fail to load 64-bit libgslcblas
by Mirko Vukovic 01 Mar '10

01 Mar '10

Hello, I just tried moving up from sbcl 1.0.34 on 64-bit linux to 1.0.36. Well, both 1.0.35 and 1.0.36 fail to load libgslcblas. Before I take this to the cffi & sbcl lists, I wonder if anyone else has observed this behavior? Thanks, Mirko

1 0

Re: [Gsll-devel] Introducing "Grid Structured Data"
by Liam Healy 21 Feb '10

21 Feb '10

The timing is unfortunate; I started on GSD a while ago, once I re-discovered Tamas's AFFI, and was wrapping it up when he announced xarray. I have looked over xarray to figure out what we have in common, but not in depth. I think any help from interested/energetic/knowledgeable volunteers who could help figure out a merge strategy would be most welcome in this area. One of the things I did to integrate GSD with GSLL was to pull out the foreign-array access as the system "c-array", with type conversion between languages. This was motivated by the work of a colleague, who essentially tore off pieces of GSLL in order to make a port to a robotics library in C++, and who had requested certain array construction features in GSLL. Now it should be easier to built an interface to a new library, and I hope eventually to smoothly change array objects to make them compatible with different libraries. Unfortunately I haven't had the time I thought I would in January to pursue this, but there is certainly much more work to be done in this area. I pushed to the GSLL master branch because that all worked as before, and GSD are usable. I think all of our goals are basically the same. Per Tamas's points: 1 - Exactly the same, present in GSD "grid" now 2 - Not yet in GSD, but that is the goal as I say 3 - Not there; would be nice to integrate with GSL's views as we have discussed 4 - Present in GSD; see "compose.lisp". Perhaps not all everyone is looking for, but with some thought and knowledge of AFFI, they're not too hard to write. The general function to make most of the array composition functions possible is map-grid and map-n-grids. One thing I would like to have but isn't there is reduction over an axis, as for instance with dot product and matrix multiplication. Also, I would like to be able to treat a scalar as a grid but that isn't possible yet. Liam On Sun, Jan 10, 2010 at 2:39 AM, Tamas Papp <tkpapp(a)gmail.com> wrote: > Hi Mirko, > > I only had a cursory look at Liam's library. Slices seem to be based > on affine indexing, which in theory is faster than xarray's views, but > it is less general. > > At the moment, xarray does four things: > > 1. rank/dimension query and element access. If it is an array-like > object, you can just write methods and access it via a general > interface. Essentially redoing CL's array interface, but with generic > functions. > > 2. object conversion framework. You can use (take 'array object) to > convert your object to a Lisp array. TAKE is a generic function, you > just specialize if you introduce new classes. It takes options (like > element-type for arrays, etc). Think of R's as.* functions. > > 3. views. This is the only part I blogged about, but it may be the > least important. It is just that the rest is still under development. > > 4. convenience functions for generating, mapping, manipulating > array-like objects. If your objects have a basic xarray interface > (basically xdims and xref), xarray can take outer products, map into > other objects, etc. You can specialize methods for speed, too. > > There are a few details I am still ironing out, but basically > everything is functional now. I consider 1. and 2. above the most > important features of xarray. > > My goal is to arrive at a state like R, where I don't have to think > about whether my matrix is R's standard matrix, or implemented by the > Matrix library, if I don't want to. Things should "just work", and I > should only have to think about details when I optimize my code. > > Caveat: xarray is still experimental. 1. above should be stable, > 2. more or less, 3. might change, and 4. too. I want to get it right. > Discussion about people's needs/preferences would be welcome. > > Best, > > Tamas > > PS.: I am on the GSLL list, so no need to cc me. My Princeton e-mail > is deprecated now. > > > On Sat, 09 Jan 2010, Mirko Vukovic wrote: > >> Any comments on how that compares to Tamas Papp's xarray? >> >> I am very excited, happy and grateful with the availability of numerical >> libraries in CL. But I am concerned that we may end up with several >> non-conformant libraries for array accessing. >> >> In an ideal world, we would have a common library for array manipulation, >> and also a common architecture for accessing libraries such as gsl (C), >> netlib (fortran), and others (sundials for example). >> >> Respectfully, >> >> Mirko >> >> On Sun, Dec 27, 2009 at 10:31 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> >> > Based on several expressed wishes for the ability to create, compose >> > and extract array-like objects and pieces of such objects, I have >> > introduced the "Grid Structured Data" collection at >> > http://repo.or.cz/w/gsd.git, and rewritten GSLL to be built on top of >> > that. The GSLL interface is the same as before, but now it is >> > possible to do subarrays, concatenation, slices, transpose, etc. on >> > arrays (both CL arrays and GSLL marrays). There is some documentation >> > for gsd in gsd/documentation/grid/index.html which describes how it >> > works. There is more work to be done, but as it is now, it provides >> > functions that people have asked for to create and manipulate marrays. >> > If you don't need that, you can go on as before and everything is the >> > same. >> > >> > Liam >> > >> > _______________________________________________ >> > Gsll-devel mailing list >> > Gsll-devel(a)common-lisp.net >> > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel >> > >

4 7

[Gsll-devel] Array indexing syntactic sugar (was: Introducing "Grid Structured Data")
by Mirko Vukovic 21 Feb '10

21 Feb '10

This is a follow up on the syntactic sugar for array referencing that I referred to in my wish list. Here is what I had in mind. A few weeks ago, I needed the inverse of a tridiagonal matrix. I found an algorithm on the web. See the first page of the following pdf document<http://www.mat.uc.pt/preprints/ps/p0516.pdf> . I am looking for a cleaner and simpler way to transcribe equations (1.1) and the two below in lisp. Note a few things. In the equation for `theta', the index of `theta' varies from 0...n, while all the other ones are from 1...n. Another problem of interest is the Yee algorithm for the numerical solution of time-dependent Maxwell equations. Take a look at the equations following (4.12) on the following page<http://www.nmr.mgh.harvard.edu/%7Eadunn/papers/dissertation/node32.html>. The indices are, among other things, i+1/2. The notation stems from the fact that the algorithm uses two staggered grids, one for the electric, and the other for the magnetic fields. The 1/2 reflects the grid offset. Of course, in actual implementation, the fields are stored in matrics, and the indices are integers. For both of these cases, one has to do some kind of index transformation, so that E_{i+1/2} becoms (aref E (some-function-of i)). With many equations, for scatterbrains like me, that is a recipe for a missed or miscalculated offset. I came up with a macros that will transform code that contains symbols like E_i+1/2 into an appropriately referenced `aref' or `maref' by using symbol-macrolet. For the theta equations, see the following code snippet<http://paste.lisp.org/display/93525>on paste.lisp.org, where the with-_-indexing1 macro does the transforming. One thing to be aware of is that the macros expand into code of `finite' length. So, inserting this macro as follows (if (...) (with-_-indexing () (if clause) (else clause)) will be inaccurate. One has to move the `with-_-indexing' outside of the `if'. When I clean up my routines, I will post them (somewhere, not yet sure where). And if anyone has a better idea how to name the macros, please let me know. Mirko On Tue, Jan 12, 2010 at 5:20 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com>wrote: > Features that I would like: > > 1. Compatibility with GSLL and LAPACK (and NETLIB for that matter). > When doing numerics, I would use grid (or xarray) and forget about > cl-arrays. > 2. More forgiving interface in array creation: coerce supplied values > to declared type > 3. syntactic sugar: refer to array subscripts using underscores: a_i_j > or a_2:5_* > > On that last point, I have a small utility that does the first example. I > am not sure where to post it for your review. I think github is overkill > to post three files (asd, package, and lisp). > > I am intrigued by xarrays' generic interface, so that xarrays can interface > with `any type of object'. I fail to see its use now, but that is just my > lack of imagination. > > On a `lack of imagination' topic, can someone give me an example of > indexing that xarray has, and that the affine indexing cannot accomplish? > > Thanks, > > Mirko > > > On Sun, Jan 10, 2010 at 3:20 PM, Liam Healy <lhealy(a)common-lisp.net>wrote: > >> I don't think there's any doubt we all want one all-singing >> all-dancing interface that provides array utility for everything in CL >> that needs it. The reason there are two starts is because we both >> started in parallel without the being aware of the other's work. The >> reason that GSD only got as far as it did was because I had addressed >> the complaints on this mailing list and elsewhere (including me) and I >> had no more time. I do not think of it as complete. >> >> So the real work here is going through both sets of code and figuring >> out how to unify them. I think all the help we can get would be >> welcome; I'm certainly willing to work toward the goal. >> >> To get the ball rolling, start with a feature at a user's level that >> you need; I mean by this some very specific thing that you've coded in >> CL already and found to be clumsy. Then see how each package >> implements it or would implement it. Then post to the list your >> findings, together with your example if possible, to start a >> discussion. Anyone can do this; I don't think there's a need to >> restrict to a "third party"; we lack a first party at the moment. By >> picking single feature(s) and working from there, we will >> incrementally get to the goal we all seek. If we try to do everything >> at once or at the most abstract level, we're likely not going to get >> there as quickly. >> >> Liam >> >> On Sun, Jan 10, 2010 at 11:50 AM, A.J. Rossini <blindglobe(a)gmail.com> >> wrote: >> > My cursory look suggests a fair amount of similarity as well, and I >> > find attractive features in both -- but want just one API! >> > >> > A reasonable proposal, from my highly biased perspective, would be a >> > 3rd party merge of the better components of each. >> > >> > (I've spent time with the xarray interface, which is the source of my >> > biases -- it mostly works for what I want to do, despite being a >> > simplification of the lisp-matrix access approach -- which isn't bad, >> > there are some lisp-matrix functionality which is strictly edge-case >> > relevant... >> > >> >> _______________________________________________ >> Gsll-devel mailing list >> Gsll-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel >> > >

2 1

[Gsll-devel] How to pass a null pointer to apply-step
by Leo 20 Feb '10

20 Feb '10

Hello, I am solving two coupled ODEs, one with respect to time, another to z. An element in the solution of the first ODE is used in the second one. So I have to use the lower-level apply-step function: (apply-step stepper time y step-size yerr dydt-in dydt-out) The gsl manual says dydt-in can be a null pointer. I wonder how to use null pointer in apply-step? Thank you. Leo -- H A P P Y H O L I D A Y S!

2 2