gsll-devel February 2013

gsll-devel@common-lisp.net

3 participants
5 discussions

[GSLL-devel] Fixing up make-grid-data for clisp (was making copy-to working in clisp+grid: fix to element-type)
by Mirko Vukovic 26 Dec '13

26 Dec '13

This is a follow up on my posted fix to copy-to. For some reason this has triggered another error. I do not understand how that other error is triggered. The error and the fix are discussed at the bottom of the email On Fri, Jan 4, 2013 at 10:39 AM, Mirko Vukovic <mirko.vukovic(a)gmail.com>wrote: > The following works in sbcl+grid: > > (copy-to (make-array 2 :element-type 'double-float :initial-contents > '(1.0d0 2.0d0)) 'grid:foreign-array) > > But it does not work in clisp+grid. > > The root cause lies in the function grid/array.lisp/element-type. It uses > `(array-element-type grid)'. > > But this can present a problem. Quoting hyperspec: > > (Because of *array* <http://26_glo_a.htm#array> *upgrading*, this *type > specifier* <http://26_glo_t.htm#type_specifier> can in some cases denote > a *supertype* <http://26_glo_s.htm#supertype> of the *expressed array > element type* <http://26_glo_e.htm#expressed_array_element_type> of the * > array*.) > > In CLISP, array-element-type returns `T' when passed #(1d0 2d0) > > It returns T even when passed a simple array: > > (array-element-type (make-array 2 :element-type 'double-float > :initial-contents > '(1.0d0 2.0d0) > :adjustable nil > :fill-pointer nil > :displaced-to nil) ) > > The proposed fix is > > (defmethod element-type ((grid array)) > (type-of (row-major-aref grid 0)) > #+skip(array-element-type grid)) > > Now copy-to works in clisp as well. > > Mirko > > > After finishing this, I recompiled afresh, and got another error that I traced to make-grid-data and make-array In clisp, make-array will return an array of NIL's even if the element-type is specified as double float. In SBCL make-array will return an array filled with 1d0. I had to add some clisp specific code to make-grid-data in order for it to initialize properly. First, a helper function: (defun default-element (element-type) "Return a default element depending on element-type " (let ((a-list '((double-float . 1d0) (symbol . T)))) (let ((match (cdr (assoc element-type a-list)))) (assert match () "Default element type undefined for element-type ~a" element-type) match))) And second, a bit of set-up code in make-grid-data. I broke apart the (let* statement to provide an explicit initial element if it has not been specified already: (defmethod make-grid-data ((type (eql 'array)) dimensions rest-spec &key (initial-element nil initial-element-p) (initial-contents nil initial-contents-p)) (let ((element-type (top-spec-type rest-spec))) #+clisp (unless (or initial-element-p initial-contents-p) (setf initial-element (default-element element-type) initial-element-p t)) (let ((array ... UNCHANGED Summary: To fix to copy-to, I modified (defmethod element-type ((grid array)) For some unknown reason, that triggered an error in the array initialization routine. To fix that, I had to add code to make-grid-data, so that it fills double-float arrays with 0d0 instead of NIL's I will continue using this code to see if there are additional problems. BTW, I realize that CLISP is not a preferred platform for speedy computation, but that is what I use on Windows, until SBCL gets officially ported to it. And in addition, it is a nice cross-check on portability. Mirko

2 2

[GSLL-devel] making copy-to working in clisp+grid: fix to element-type
by Mirko Vukovic 26 Dec '13

26 Dec '13

The following works in sbcl+grid: (copy-to (make-array 2 :element-type 'double-float :initial-contents '(1.0d0 2.0d0)) 'grid:foreign-array) But it does not work in clisp+grid. The root cause lies in the function grid/array.lisp/element-type. It uses `(array-element-type grid)'. But this can present a problem. Quoting hyperspec: (Because of *array* <26_glo_a.htm#array> *upgrading*, this *type specifier*<26_glo_t.htm#type_specifier>can in some cases denote a *supertype* <26_glo_s.htm#supertype> of the *expressed array element type*<26_glo_e.htm#expressed_array_element_type>of the *array*.) In CLISP, array-element-type returns `T' when passed #(1d0 2d0) It returns T even when passed a simple array: (array-element-type (make-array 2 :element-type 'double-float :initial-contents '(1.0d0 2.0d0) :adjustable nil :fill-pointer nil :displaced-to nil) ) The proposed fix is (defmethod element-type ((grid array)) (type-of (row-major-aref grid 0)) #+skip(array-element-type grid)) Now copy-to works in clisp as well. Mirko

2 1

Re: [GSLL-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

[GSLL-devel] Physics-constants library?
by Mirko Vukovic 26 Feb '13

26 Feb '13

I did not find a library with physics constants on cliki or quicklisp. There is one available from within GSLL, but loading GSLL just for physics constants is an overkill. Are there any other ones? I have one of my own (somewhat incomplete) that works for me, and I can clean it up and push it to quicklisp if nothing meaningful is out there. Mirko

2 2

[GSLL-devel] LinkedIn'deki ağıma katılın.
by Leo Liu, LinkedIn aracılığıyla 11 Feb '13

11 Feb '13

LinkedIn ------------ Leo Liu, sizi LinkedIn'de bağlantı olarak eklemek istiyor: ------------------------------------------ Sizi LinkedIn'deki profesyonel ağıma eklemek istiyorum. Leo Liu adlı kullanıcıdan gelen davetiyeyi kabul et http://www.linkedin.com/e/-8a34oq-hd1lsvdo-5z/ZinPG-VgE-rKjpgcnEb9mzEQSFxBy… Leo Liu adlı kullanıcının profilini görüntüle http://www.linkedin.com/e/-8a34oq-hd1lsvdo-5z/rso/231655244/zieP/name/21066… ------------------------------------------ Davet e-postaları alıyorsunuz Bu e-posta Steve Stevenson için tasarlanmıştır. Bunun neden eklendiğini öğrenin: http://www.linkedin.com/e/-8a34oq-hd1lsvdo-5z/plh/http%3A%2F%2Fhelp%2Elinke… (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043 USA

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel February 2013