February 2010 - 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] 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] 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

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

[Gsll-devel] gmane.lisp.gsll
by Leo 20 Feb '10

20 Feb '10

Hello all, If you use gnus and gmane, I have requested the creation of newsgroup gmane.lisp.gsll for this mailing list. Best, Leo

2 2

[Gsll-devel] OT: foreign numeric vector library compilation on sbcl
by Mirko Vukovic 10 Feb '10

10 Feb '10

Hello This does not strictly apply to gsll, but it is not too far afield. After a several month hiatus I tried to load the `foreign-numeric-vector' library on sbcl1.034 on 64-bit linux in order to access some netlib and lapack routines (mainly the amos library for complex bessel functions). (My prior version of sbcl was 1.024) I got the following error when compiling the file `foreign-numeric-vector.lisp': >>> Unexpected offset. [Condition of type SIMPLE-ERROR] Restarts: 0: [TRY-RECOMPILING] Try recompiling foreign-numeric-vector 1: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {1003F6C941}> on #<ASDF:CL-SOURCE-FILE "foreign-numeric-vector" {1004056AF1}>. 2: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {1003F6C941}> on #<ASDF:CL-SOURCE-FILE "foreign-numeric-vector" {1004056AF1}> as having been successful. 3: [ABORT] Abort compilation. 4: [RETRY] Retry SLIME REPL evaluation request. 5: [ABORT] Return to SLIME's top level. --more-- >>> The error seems to be during the compilation of: ; compiling (MAKE-FNV-TYPED-VECTOR FLOAT ...) ; compiling (MAKE-FNV-TYPED-VECTOR DOUBLE ...) ; compiling (MAKE-FNV-TYPED-VECTOR COMPLEX-FLOAT ...) <----------------- ; compilation aborted after 0:03:00.518 ; ; compilation unit aborted ; caught 2 fatal ERROR conditions If I comment out (make-fnv-typed-vector complex-float ...) and (make-fnv-typed-vector complex-double ...), the file compiles cleanly. Unfortunately, I do need those routines. I tried this with the latest cffi. Any thoughts on what may be going on? Thanks Mirko

1 0

Re: [Gsll-devel] [iterate-devel] Fwd: iterate form evaluates but does not loadinto sbcl fasl
by Mirko Vukovic 09 Feb '10

09 Feb '10

On Tue, Feb 9, 2010 at 9:30 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Mirko, > > >Are you implying that instead of lambda forms one should define the > >functions and use function names. > No. Just look at the examples in the source code, incl. tests. > The key is to write #'(lambda ...) aka. (function (lambda ...)), not > (lambda ...) > Like this? (defclause-sequence matrix-row matrix-row-index :access-fn #'(lambda (grid index) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (grid:row grid index)) :size-fn #'(lambda (grid) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (first (grid:grid-dimensions grid))) :element-type t :sequence-type t :element-doc-string "(copied) rows of a matrix" :index-doc-string "index of the rows in a matrix") Unfortunately, that did not help improve things. Also, the iterate documentation has an example of `defclause-sequence' (bottom of p.26 of the pdf file). There is no #'(lambda ...), just plain (lambda ...) Thank you for your time, Mirko

2 2

Re: [Gsll-devel] [iterate-devel] Fwd: iterate form evaluates but does not load into sbcl fasl
by Mirko Vukovic 09 Feb '10

09 Feb '10

On Mon, Feb 8, 2010 at 9:57 PM, Kalyanov Dmitry <kalyanov.dmitry(a)gmail.com>wrote: > The iterate extension is clearly wrongly written. You cannot insert non- > externalisable value into the compiled file, in this case, functions > compiled > in compilation-environment. The code should be rewritten to use defuns to > declare functions and to use symbols in defclause-sequence. > Dmitry, Yesterday was the first time I encountered this externalisation issue (see emails by Yong). So, I am still wobbly with these concepts. Are you implying that instead of lambda forms one should define the functions and use function names. For example, in the following form (defclause-sequence matrix-row matrix-row-index :access-fn (lambda (marray index) (check-type marray gsl:matrix) (gsll:row marray index)) :size-fn (lambda (marray) (check-type marray gsl:matrix) (c-array:dim0 marray)) :element-type t :sequence-type t :element-doc-string "(copied) rows of a matrix" :index-doc-string "index of the rows in a matrix") all lambda expressions need to be replaced by function symbols. Correct? FWIW, I could not reproduce my problem on clisp. Mirko

1 0

[Gsll-devel] iterate form evaluates but does not load into sbcl fasl
by Mirko Vukovic 08 Feb '10

08 Feb '10

Hello, (I apologize for the wide email distribution. There is a small probability the issue described here is due to a mismatch between iterate or sbcl). The package gsd <http://repo.or.cz/w/gsd.git>, part of gsll<http://common-lisp.net/project/gsll/>uses iterate to loop over elements of vectors and matrices. I have attached the part of the package that extends iterate to this email. I am having the following issue on sbcl1.034 on RHEL5 64-bit linux, via slime. The following form evaluates OK at the REPL. (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float* ) (print c)) But, if I embed it into a function: (defun foo () (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float*) (print c))) it will evaluate OK in slime (C-x C-e), but will not compile (C-c C-c). The returned error is: >>> post-processing/xpdp-post-processing.lisp:75:3: error: Objects of type FUNCTION can't be dumped into fasl files. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE --> SB-KERNEL:%COERCE-CALLABLE-TO-FUN ==> #<FUNCTION (LAMBDA #) {1002DD7AD9}> note: The first argument never returns a value. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE ==> (SB-KERNEL:%COERCE-CALLABLE-TO-FUN #<FUNCTION # {1002DD7AD9}>) ... more stuff >>> So, it seems that sbcl can digest it, but for some reason cannot write it to a fasl. The macroexpansion of the code above is: (LET* ((#:SEQUENCE120 NIL) (#:LIMIT121 NIL) (C NIL) (#:INDEX119 NIL)) (BLOCK NIL (TAGBODY (PROGN (SETQ #:SEQUENCE120 GRID::*ARRAY-3-4-DOUBLE-FLOAT*) (SETQ #:LIMIT121 (FUNCALL # #:SEQUENCE120)) (SETQ #:INDEX119 -1)) LOOP-TOP-NIL (PROGN (SETQ #:INDEX119 (+ #:INDEX119 1)) (IF (>= #:INDEX119 #:LIMIT121) (GO LOOP-END-NIL)) (SETQ C (FUNCALL # #:SEQUENCE120 #:INDEX119)) (PRINT C)) (PROGN) (GO LOOP-TOP-NIL) LOOP-END-NIL (PROGN)) NIL)) Is this issue due to a malformed extension of iterate, or some misalignment between iterate and sbcl? Thank you, Mirko

1 0

[Gsll-devel] bug in grid/iterate?
by Mirko Vukovic 08 Feb '10

08 Feb '10

Apologies for cross posting, but I am not sure where this problem belongs (iterage or gsll). I use slime (updated a few days ago) on sbcl 1.031 on linux. I have problems compiling the following file: >>> (in-package :grid) (defun foo () (iter:iter (iter:for e :Matrix-row grid::*array-3-4-double-float*) (princ e) (princ " "))) <<< (the code is from the iterate.lisp file of the distribution) Now in slime, I have problems. Evaluation works: I can do C-x C-e to compile `foo' I can also do C-M-x But compilation does not. Both C-c C-c and C-c C-k will flag a compiler error: note: The first argument never returns a value. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE ==> (SB-KERNEL:%COERCE-CALLABLE-TO-FUN #<FUNCTION # {10030285A9}>) Same story in raw sbcl. I looked at the iterate.lisp source code and see nothing obvious. But, I am not sure what to make of the following: If I macro-expand the above code (iter:iter ... (iter:for ... :matrix-row ...(...))) I get the following expansion. The puzzling thing is thta the first argument to `funcall' is a single hash character `#': (let* ((#:sequence208 nil) (#:limit209 nil) (e nil) (#:index207 nil)) (block nil (tagbody (progn (setq #:sequence208 *array-3-4-double-float*) (setq #:limit209 (funcall # #:sequence208)) ;; <----- (setq #:index207 -1)) loop-top-nil (progn (setq #:index207 (+ #:index207 1)) (if (>= #:index207 #:limit209) (go loop-end-nil)) (setq e (funcall # #:sequence208 #:index207)) ;; <----- (princ e) (princ " ")) (progn) (go loop-top-nil) loop-end-nil (progn)) nil)) Instead of the single hash mark, I would have expected the :access-fn and :size-fn `lambda's from the (defclause-sequence matrix-row matrix-row-index ...) in iterate.lisp. So, lots of puzzles. Not sure where this bug belongs: iterate or grid? Thanks, Mirko

2 2

[Gsll-devel] GSLL on CCL
by Leo 07 Feb '10

07 Feb '10

Hello, When I run (make-multi-dimensional-root-solver-f +powells-hybrid+ 3 #m(0 0 0)), CCL enters debug mode with the following msg on the terminal it runs in. ? Unhandled exception 10 at 0x0, context->regs at #xb0e30b1c Exception occurred while executing foreign code ? for help [57048] Clozure CL kernel debugger: More debug info are attached. Any idea how to fix this? I am running Clozure Common Lisp Version 1.4-r13357M (DarwinX8632). Thanks. Leo

2 2

[Gsll-devel] Bug? Conflict between grid & gsll: iterate.lisp present in both systems
by Mirko Vukovic 07 Feb '10

07 Feb '10

The latest versions of gsd and gsll both contain a file iterate.lisp gsll's iterate.lisp will cause grid's iterate macros to fail on cl-arrays as it uses c-array:dim0 and c-array:dim1 The iteration on cl-arrays problem is resolved if on recompiles grid's iterate.lisp after loading gsll. Mirko

2 1

[Gsll-devel] grid tranpose & diagonal compatibility with marray's
by Mirko Vukovic 07 Feb '10

07 Feb '10

I am converting some of my code to use grid. The following is on clisp & cygwin (my sbcl & linux is behind a firewall, so it takes a bit for me to transfer stuff to them) It seems that while `transpose' can handle both arrays and marrays, diagonal can handle only arrays. I traced the execution to `make-specification' in specification.lisp: SYSTEM::LIST-ACCESS: NIL is not a pair. GSL> #m(1 2 3 ^ 4 5 6 ^ 7 8 9) #<MATRIX-DOUBLE-FLOAT #2A((1.0d0 2.0d0 3.0d0) (4.0d0 5.0d0 6.0d0) (7.0d0 8.0d0 9.0d0))> GSL> (grid:transpose #m(1 2 3 ^ 4 5 6 ^ 7 8 9)) #<MATRIX-DOUBLE-FLOAT #2A((1.0d0 4.0d0 7.0d0) (2.0d0 5.0d0 8.0d0) (3.0d0 6.0d0 9.0d0))> GSL> (grid:diagonal #m(1 2 3 ^ 4 5 6 ^ 7 8 9)) ; Evaluation aborted. GSL> (grid:transpose (cl-array #m(1 2 3 ^ 4 5 6 ^ 7 8 9))) #2A((1.0d0 4.0d0 7.0d0) (2.0d0 5.0d0 8.0d0) (3.0d0 6.0d0 9.0d0)) GSL> (grid:diagonal (cl-array #m(1 2 3 ^ 4 5 6 ^ 7 8 9))) #(1.0d0 5.0d0 9.0d0) GSL> FWIW, in the test suite (tests/compose.lisp), the diagonal tests are on arrays, and not marrays. Thanks, Mirko

2 2

[Gsll-devel] How to install grid to use the iterate feature?
by Mirko Vukovic 07 Feb '10

07 Feb '10

On my slime+sbcl, I have to explicitly asdf-load `alexandria' and `iterate' before `grid', in order for the `iteration' feature to be included. Is that the intended behavior? Thanks, Mirko

2 1