December 2012 - antik-devel - mailman3.common-lisp.net

[Antik-devel] Bug in antik/.../sample/low-discrepancy-sequence.lisp ?
by Mirko Vukovic 17 Apr '13

17 Apr '13

Hello, this is on clisp 2.48 on cygwin. The function low-discrepancy-sample could not compile because iterate could not digest loop ***** Iterate, in clause (COLLECT (APPLY MAKE-FUNCTION (APPEND FIXED-PARAMETERS (MAPCAN (LAMBDA (X SEQ) (LIST (FIRST X) (VAL-FROM-RANGE (GREF V SEQ) (SECOND X) (THIRD X)))) SWEEP-PARAMETERS (LOOP FOR I FROM 0 BELOW (LENGTH SWEEP-PARAMETERS) COLLECT I))))): Iterate does not know how to handle the special form (MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-ERROR))) (BLOCK NIL (LET ((I 0) (#:LIMIT-273656 (LENGTH SWEEP-PARAMETERS))) (PROGN (LET ((#:ACCULIST-VAR-273657 NIL)) (MACROLET ((LOOP-FINISH NIL '(GO SYSTEM::END-LOOP))) (TAGBODY SYSTEM::BEGIN-LOOP (WHEN (COMMON-LISP:>= I #:LIMIT-273656) (LOOP-FINISH)) (PROGN (SETQ #:ACCULIST-VAR-273657 (CONS I #:ACCULIST-VAR-273657))) (PSETQ I (COMMON-LISP:+ I 1)) (GO SYSTEM::BEGIN-LOOP) SYSTEM::END-LOOP (MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-WARN) '(GO SYSTEM::END-LOOP))) (RETURN-FROM NIL (SYSTEM::LIST-NREVERSE #:ACCULIST-VAR-273657)))))))))) It will not be walked, which means that Iterate clauses inside it will not be seen. ***** If I replaced the loop form with the much more verbose (let (res) (dotimes (i (length sweep-parameters) (nreverse res)) (push i res))) the code compiled cleanly. The same error can be seen with a much simpler: (iter:iter (iter:for v iter:in '(1 2 3 4)) (iter:collect (loop for i in v))) Another alternative is to use iter instead of loop (iter:iter (iter:for i from 0 below (length sweep-parameters)) (iter:collect i)) It compiles cleanly, but I did not test the function accuracy. Mirko

2 1

[Antik-devel] Fix for complex foreign arrays in LispWorks
by Martin Simmons 23 Dec '12

23 Dec '12

Hi, The patch below is needed to make Antik work in LispWorks (no specialized complex Lisp array types). I was testing Antik by running the GSLL unit tests with the quicklisp version. --- antik-20120909-git/foreign-array/foreign-array.lisp~ 2012-12-17 13:24:03.256699471 +0000 +++ antik-20120909-git/foreign-array/foreign-array.lisp 2012-12-17 14:39:54.931815902 +0000 @@ -90,7 +90,7 @@ (coerce-value initial-element element-type)))) (if (and (member :static-vectors *features*) ;; CCL does not support complex element types as static vectors - #+ccl (not (subtypep element-type 'complex)) + #+(or ccl lispworks) (not (subtypep element-type 'complex)) (or (= 1 (length dimensions)) (eql linearization :row-major))) ;; Make a CL image array if the implementation supports it and -- Martin Simmons LispWorks Ltd http://www.lispworks.com/

2 1

[Antik-devel] FLAME and possible next library ports using grids
by Liam Healy 08 Dec '12

08 Dec '12

On this and other mailing lists, there have been recent discussions of "numerical lisp" which in one aspect or another has been the vision of many of us, some for many years. My approach is to write libraries I think will form a piece of the overall solution, with the hope that others will join in and write compatible libraries that form another piece. So, I initially wrote GSLL and then split the grid part out into Antik (which has other features I adapted from my personal libraries). The grid functions can use enhancement, but they are usable now for developing library ports. I have thought about and had discussions with others about what would be a good candidate library for the next port. These thoughts have revolved mainly around an FFT library (like fftw) or a linear algebra library (like *lapack) because those are widely used and, since GSL already provides some of that capability, offers a good opportunity to compare features and make a unified interface. Recently, I came across the FLAME linear algebra library (http://z.cs.utexas.edu/wiki/flame.wiki/FrontPage) It is designed with an intriguing modularity concept. I think it would be a good library to port to grid/Antik. Unfortunately, I don't have the time to work on this, but if anyone (particularly someone who needs linear algebra capability like this) wants to take it up, I encourage that and will help as much as I can. A big challenge I foresee in any foreign library interface is the allocation of arrays. If it is a "closed box," it makes it hard to use e.g. static-vectors and therefore the arrays have to be copied back and forth between the foreign side and the CL side. GSL has the advantage that there are functions that allow building GSL arrays out of supplied C arrays, so regular CL arrays can be allocated with a C pointer passed to these functions to wrap them with GSL metadata. I'm not sure many other libraries are that flexible; many (e.g. C++ libraries) consider it a virtue to seal off the raw storage (C arrays) from the user, and force you to go through a foreign interface to do the allocation. Since there are almost no CLs that permit construction of CL arrays using foreign data, copying is the only option left. So, if anyone has thoughts on FLAME or any other library, I'll be happy to contribute my ideas if it will help. Liam

2 2