antik-devel March 2013

antik-devel@common-lisp.net

3 participants
5 discussions

[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

Re: [Antik-devel] Matlisp, CLOS
by Nicolas Neuss 08 Mar '13

08 Mar '13

[I added some more people to the CC] Akshay Srinivasan <akshaysrinivasan(a)gmail.com> writes: > At Thu, 07 Mar 2013 10:35:46 +0100, > Nicolas Neuss wrote: >> >> Akshay Srinivasan <akshaysrinivasan(a)gmail.com> writes: >> >> > I wanted to polish the whole "static object" thing I'm doing write now, >> > by writing a thin layer over defclass itself. This seems awful lot like >> > MOP. >> > >> > What I'm doing right now is essentially that every tensor class has a set >> > of inlined functions associated with it, which are then used inside macros >> > everywhere to define type specific functions. >> > >> > From what I understand of MOP, I can possibly define a meta-class which holds >> > all these functions, and then possibly define the defmethod over instances of the >> > metaclass (which sort of does the equivalent of macroexpansion ?). Essentially >> > I don't really want to have runtime dispatch; can I define in some sense a >> > meta-version of defmethod/defgeneric on a class so that it wraps the code for the >> > method inside a symbol-macrolet to replace things like "+,-" with something >> > specialised for the class? >> >> Although I already can imagine what you want quite well - could you >> maybe sketch an example (as simple as possible)? >> >> > I can't find any real resource on MOP, so forgive me if this doesn't >> > make any sense whatsoever. >> >> The chapters 5 and 6 of the AMOP book should be freely available, see >> >> http://www.clisp.org/impnotes/mop-chap.html >> >> or google for "mop_spec.pdf". >> >> > Nicholas: I know this is probably more up your alley. Do you think this sort of >> > thing is possible with MOP ? >> >> I doubt a little that the MOP is sufficient for achieving this, but I >> also would not find using something like DEFMETHOD* instead of DEFMETHOD >> very bad and then you have all liberty you want. As I see it the MOP >> was created for achieving high flexibility, but not high performance, >> and so implementations like CMUCL or SBCL have a slightly similar but >> more lowlevel mechanism (compiler transforms, IIRC) how one can instruct >> the compiler to optimize operations with type information that is known >> at compile time. > Sigh. I was hoping to avoid doing all the superclass ordering and stuff, > oh well. I sort of want to do things like the macro generate-typed-copy! > in the file: > https://github.com/enupten/matlisp/blob/tensor/src/level-1/copy.lisp > without having to read things from a Hashtable everytime. Maybe writing a > new object system is overkill, and I should just use a macro like with-slots. What about doing a type-specialized compilation on-demand as I do in femlisp/src/matlisp/blas-basic.lisp? Alternatively, this could also be triggered when NO-APPLICABLE-METHOD is called. >> > Akshay >> >> Apropos: I am still trying to build and run your Matlisp without >> success. First, I had difficulties because f77 did not know the "exit" >> command used in "iladlr.f", for example. Using gfortran compiled at >> least the Fortran code, however after compilation I am left in a state >> with apparently nothing new available. > Is this the Intel compiler ? >From the Manpages on my system gfortran - GNU Fortran compiler f77=fort77 - invoke f2c Fortran translator transparently, like a compiler I think this has changed recently. Some time ago, f77 was the GNU Fortran compiler. >> [...] >> ; /home/neuss/.cache/common-lisp/sbcl-1.1.5.5-203e2ac-linux-x64/home/neuss/matlisp/src/sugar/ASDF-TMP-seq.fasl written >> ; compilation finished in 0:00:00.022 >> ; >> ; compilation unit finished >> ; printed 8 notes >> >> >> ** MATLISP is loaded. Type (HELP MATLISP) >> to see a list of available symbols. >> To use matlisp: >> >> (use-package "MATLISP") >> >> or >> >> (in-package "MATLISP-USER") >> >> * (help matlisp) >> ; in: HELP MATLISP >> ; (HELP MATLISP) >> ; >> ; caught STYLE-WARNING: >> ; undefined function: HELP >> ; >> ; caught WARNING: >> ; undefined variable: MATLISP >> ; >> ; compilation unit finished >> ; Undefined function: >> ; HELP >> ; Undefined variable: >> ; MATLISP >> ; caught 1 WARNING condition >> ; caught 1 STYLE-WARNING condition >> >> debugger invoked on a UNBOUND-VARIABLE in thread >> #<THREAD "main thread" RUNNING {10029D9833}>: >> The variable MATLISP is unbound. >> >> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. >> >> restarts (invokable by number or by possibly-abbreviated name): >> 0: [ABORT] Exit debugger, returning to top level. >> >> ((LAMBDA ())) >> 0] 0 >> >> * (apropos "matlisp") >> >> COMMON-LISP-USER::MATLISP >> :MATLISP (bound) >> :MATLISP-TESTS (bound) >> :MATLISP-USER (bound) >> *MATLISP-VERSION* (bound) >> MATLISP >> MATLISP-HERALD (fbound) >> MATLISP-NAME >> MATLISP-VERSION (fbound) >> SAVE-MATLISP (fbound) >> MATLISP-FFI::MATLISP-SPECIALIZED-ARRAY >> MATLISP-SYSTEM::MATLISP >> MATLISP-SYSTEM::MATLISP-CONDITIONS >> MATLISP-SYSTEM::MATLISP-CONFIG >> MATLISP-SYSTEM::MATLISP-PACKAGES >> MATLISP-SYSTEM::MATLISP-TESTS >> MATLISP-SYSTEM::MATLISP-UTILITIES > > Yes, the old help system isn't yet incorporated. I'm sorry that you've to > tread through my undocumented code. > > Assuming you want to test the GEMM, you'd want to do something like: > ----------------------------------------------------------------------------- > (in-package :matlisp) > > (let ((A (make-real-tensor 1000 1000)) > (B (make-real-tensor 1000 1000))) > ;;Slow and dynamic > (time > (mod-dotimes (idx (dimensions A)) > do (progn > (setf (tensor-ref A idx) (random 1d0) > (tensor-ref B idx) (random 1d0))))) > ;;Faster (although random slows it down quite a bit). > #+nil > (time > (let-typed ((sto-a (store A) :type real-store-vector) > (sto-b (store B) :type real-store-vector)) > (mod-dotimes (idx (dimensions A)) > with (linear-sums > (of-a (strides A) (head A)) > (of-b (strides B) (head B))) > do (progn > (real-typed.value-writer (random 1d0) sto-a of-a) > (real-typed.value-writer (random 1d0) sto-b of-b))))) > ;;Use lisp > (let ((*real-l3-fcall-lb* 1000)) > (time (gemm 1d0 A B nil nil))) > ;;Use fortran > (let ((*real-l3-fcall-lb* 0)) > (time (gemm 1d0 A B nil nil)))) > -------------------------------------------------------------------------------- > I realised I haven't actually added all my "test" files into the repository. > I'll add them to the repo today. > > On my computer the timings are something like: > Lisp: 3.2s > C (tests/mm.c): 2.2s > Goto: 0.2s > > Akshay OK, this works. Some further questions and remarks: - Do you have also a reader macro like [...] in old Matlisp? And could you illustrate how slicing works? - Looking at how complicated e.g. "gemm.lisp" is, I am not sure if doing this in CL is really worthwile. Optimizing for small matrices might be the wrong idea from the beginning. - I would be interested in the minimal amount of code necessary for adding some new LAPACK routine. If possible, the stub should be even smaller than in femlisp/src/matlisp/ggev.lisp and femlisp/src/matlisp/hgev.lisp (solutions of generalized eigenvalue problems). - I really am interested in single-float stuff too, because I will look more closely in generating high-performance code in the next future. In this domain, using single-float is often interesting, because it needs only half the memory and using it can lead to double efficiency in situations where memory bandwidth is the limiting factor. Nicolas -- Nicolas Neuss neuss(a)math.fau.de

2 1

[Antik-devel] CFFI release 0.11.0
by Liam Healy 03 Mar '13

03 Mar '13

CFFI 0.11.0 was released last week. This includes cffi-libffi, which makes FSBV obsolete. The new versions of Antik and GSLL now use cffi-libffi instead of FSBV. For most users of these systems, this is an internal detail and unimportant. However, for the past 6 months at least, I have been using and updating these versions and not the FSBV version. So, with these branches merged into the master branch, a number of patches and fixes have made there way into the master branch. I expect in the March update to quicklisp, all these changes will be in the new dist. Waiting for CFFI to be finalized blocked a number of projects. One is to split up Antik into different systems instead of making one system that loads everything (grid, physical quantities, etc.). Another is dataflow definitions (and coordination with org-mode) that I am just starting on. In GSLL, I've started to look at the definition of physical constants. I don't know when I'll have time to work on these or when they'll be complete, but I'll update when I have something. Liam

1 0

Re: [Antik-devel] Matlisp
by Akshay Srinivasan 01 Mar '13

01 Mar '13

At Thu, 28 Feb 2013 07:00:27 +0100, A.J. Rossini wrote: > > Regarding the auto-gen'd BLAS and LAPACK FFI stuff, it's cl-blapack > you want to look at. Rif did a pretty complete job of writing that. > I'd look at that for the CFFI stubs, though it would be nice to have > the alpha/beta status Fortran-CFFI stuff moved out of an experimental > state (I'm as guilty as everyone else for that problem). > > There's a lisp-matrix google group that should have some of Mark H / > Rif / Tamas' earlier discussions from the late 2000s that should be > reviewed. Did you review that list, Akshay? I think I've looked at the webpage that was put up by Mark on Berkeley's site. I think the tensor branch sort of satisfies all of them (except perhaps for the LAPACK bits?). Please though take a look at the code. Akshay > > > best, > -tony > > blindglobe(a)gmail.com > Muttenz, Switzerland. > "Commit early,commit often, and commit in a repository from which we > can easily roll-back your mistakes" (AJR, 4Jan05). > > Drink Coffee: Do stupid things faster with more energy!

1 0

Re: [Antik-devel] Matlisp
by Liam Healy 01 Mar '13

01 Mar '13

Hi Akshay, Thank you for your work and your email. I think a lot of people have had very similar thoughts to yours, and have started down the road meeting the needs of users they've identified. There are a lot of good and partially overlapping ideas within this loosely organized group of people. There was a similar discussion started in the context of common lisp stats (which I'm not a member of) a few months ago. Where I was participating, I cc'ed the antik-devel mailing list; see for example http://lists.common-lisp.net/pipermail/antik-devel/2012q4/000019.html and the archives in general http://lists.common-lisp.net/pipermail/antik-devel/2012q4/thread.html with the subject "numerical lisp". My feeling is that we need to break the desired functions into relatively narrow, compatible libraries. I started Antik as a split out of GSLL to handle "grids" (generalized arrays) to start down that road. It needs to be split up further, because it now includes other things such as calculations with physical dimensions. I've started that further split, but haven't done any work on it recently. I am interested in the work you've done; it's been a while since I looked at Matlisp. At the time, it did not meet my needs, but it seems you have done significant work on it and has a lot of potential to be part of the compatible family of libraries as I've described. I think a good first step is to identify the different areas (for example, generalized arrays as I've indicated, or statistics functions) and canvas the current state of software for features and capabilities. I've added Tamas Papp and Mirko Vukovic onto this email because they've been very active in thinking about these things. Also I've added the Antik and GSLL mailing lists for good measure. Liam On Wed, Feb 27, 2013 at 1:04 AM, Akshay Srinivasan <akshaysrinivasan(a)gmail.com> wrote: > Hello All, > I'm sort of the active developer of Matlisp these days (mostly whilst procrastinating > from doing more "academic" work). I know all of you have created your independent system for > scientific computing on Common Lisp, and it is really a pity that all of them (including the > old Matlisp) are not particularly usable when compared with something like SciPy or Matlab even; > more so since Lisp is so much nicer a language. > I think the version of Matlisp I'm developing has a lot of promise, and is taking a very > good shape (atleast I'd like to think so). I'm personally trying to use it for my work in Control > theory and such; but it's still not something which is particularly usable yet. The improvements over > the old version of Matlisp are: > - Use of a hacky static object system, so that functions can be generated for any user-defined "field". > There is some code demonstrating the use of Maxima to work with "symbolic-tensors", there isn't > code for integer matrices yet, but getting this to work is fairly trivial. > - The tensor (multi-array) structures can now be sliced inplace very easily like SciPy. > - Automatic fortran callback generation (see dlsode.lisp). There are plans to extend this to C, so > that we can make use of GSL. > - Lisp implementations of BLAS functions, and support for seamlessly switching between the Lisp and > Fortran versions of these routines. The lisp version of GEMM (and others) is nearly as fast as the > F77 reference BLAS one, on SBCL. > - The FFI has moved to CFFI, if you haven't noticed that yet; builds on CCL and CMUCL. > The basic structure of BLAS is out there, but the LAPACK wrappers are missing. However I do think that > the general structure of the code is in place. > > I just wanted to throw out the idea into the open, about the feasibility of merging all your > projects into Matlisp (and calling it by some other name, if that is an issue) ? Would any of you > be willing to take the time to go through my code and merge yours in ? I'm writing to you now > before I take time and polish things, because then there'd be little room to make architectural > changes later on. The code is here if you'd like to give it a try: > git://matlisp.git.sourceforge.net/gitroot/matlisp/matlisp tensor > or if you just want to browse the code: > https://github.com/enupten/matlisp > You may want to look at the (ugly) code in tests/ folder to get an idea about the code behaviour. > You'd also want to work in #:matlisp package (despite what the herald says). > > Getting the maxima bits to work is kind of tricky, but you don't really need it for numerical routines > to work. > > Akshay

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

antik-devel March 2013