gsll-devel

gsll-devel@common-lisp.net

246 discussions

Start a nNew thread

Make her pleased every night
by Rolf Oconnor 11 Apr '13

11 Apr '13

Check new prices http://sotimex.com/acid.html

1 0

[GSLL-devel] Loading Foreign Libraries in MacOSX
by David Hodge 01 Apr '13

01 Apr '13

Hi I am using SBCL on MacOSX and when I try to load the latest GSLL it can't find the foreign libraries for libgslcblas and libgsl. Looking at the source from an earlier version I see that the "lib/"prefix has been omitted from the library names. One possible workaround would be to use "gsl-config --libs" and extract the library directory from that. if you are interested I can supply a patch. cheers

1 0

[GSLL-devel] CFFI release 0.11.0
by Liam Healy 04 Mar '13

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

[GSLL-devel] added basic fft to my dataframes
by Mirko Vukovic 14 Jan '13

14 Jan '13

In preparation for experiments that start tomorrow, I added today real-array fft and power spectrum capabilities to my dataframe code. It uses GSLL's fft functions (search for file fft.lisp). The classes, generic functions, and methods are still a bit rough, and will be refined. You can read more about it: https://github.com/mirkov/data-table/blob/master/user/example1/README.org That same directory contains examples-w-fft.lisp that shows the code usage. I annotated the code. The png files show sunspot data and two power spectra. The example shows how I create one data-table with raw data, and then another one with slightly massaged data. I do the fft on the latter one. The example also shows that the current syntax is `functional' vs `declarative'. I explicitly build the second data table, instead of declaring its dependency on the first table. I think that the latter approach is preferable from a user's point of view. But I will refrain from trying to design and implement this declarative approach. I need more real-world experience before trying to do this. I may add windowing capability to the fft code later on. Mirko

1 0

[GSLL-devel] Error installing GSLL
by Patrick M. Groulx 03 Jan '13

03 Jan '13

Hi all, I have been trying to install GSLL for the past couple of days on Ubuntu and Debian, both running SBCL, and I keep encountering the same problem. I install Quicklisp without any difficulty but when I attempt to install GSLL I get the output that I have included below. It appears that the error is in static-vectors and the use of the component "CFFI-GROVEL-FILE." I'm not seeing where in the source files that I have the component defined anywhere, so I am at a loss as to what it does. I have included the output of (list-all-packages) at the very bottom in case I am missing something. I'm hoping that someone with a more in-depth understanding of the different components can help me out. Thanks, Patrick * (ql:quickload "gsll") ; Loading system definition from ; /usr/share/common-lisp/source/cl-cffi/cffi-grovel.asd into #<PACKAGE "ASDF2"> ; Registering #<SYSTEM "cffi-grovel"> ; Loading system definition from ; /usr/share/common-lisp/source/alexandria/alexandria.asd into ; #<PACKAGE "ASDF2"> ; Registering #<SYSTEM "alexandria"> ; Loading system definition from /usr/share/common-lisp/source/cl-cffi/cffi.asd ; into #<PACKAGE "ASDF2"> ; Registering #<SYSTEM "cffi"> ; Loading system definition from /usr/share/common-lisp/source/babel/babel.asd ; into #<PACKAGE "ASDF2"> ; Registering #<SYSTEM "babel"> ; Loading system definition from ; /usr/share/common-lisp/source/trivial-features/trivial-features.asd into ; #<PACKAGE "ASDF2"> ; Registering #<SYSTEM "trivial-features"> ; Loading system definition from ; /home/pgroulx/quicklisp/dists/quicklisp/software/asdf-system-connections-201 01006-darcs/asdf-system-connections.asd ; into #<PACKAGE "ASDF1"> ; Registering #<SYSTEM "asdf-system-connections"> To load "gsll": Load 1 ASDF system: gsll ; Loading "gsll" debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #<THREAD "initial thread" RUNNING {AAE5749}>: Error while trying to load definition for system antik from pathname /home/pgroulx/quicklisp/dists/quicklisp/software/antik-20120909-git/antik.as d: Error while trying to load definition for system static-vectors from pathname /home/pgroulx/quicklisp/dists/quicklisp/software/static-vectors-1.4/src/stat ic-vectors.asd: don't recognize component type CFFI-GROVEL-FILE Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system static-vectors after reinitializing the source-registry. 1: Retry finding system antik after reinitializing the source-registry. 2: [ABORT ] Give up on "gsll" 3: Exit debugger, returning to top level. ((FLET #:LAMBDA2060) #<LOAD-SYSTEM-DEFINITION-ERROR {B6E6AD9}>) 0] 0 .......; ; compilation aborted because of fatal error: ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 4208 (line 102, column 38) on #<SB-SYS:FD-STREAM ; for "file /home/pgroulx/quicklisp/dists/quicklisp/software/antik-20120909-git/foreign- array/foreign-array.lisp" ; {C1CA541}>: ; package "STATIC-VECTORS" not found ; debugger invoked on a ASDF:COMPILE-ERROR in thread #<THREAD "initial thread" RUNNING {AAE5749}>: Error while invoking #<COMPILE-OP (:VERBOSE NIL) {B53E519}> on #<CL-SOURCE-FILE "antik" "foreign-array" "foreign-array"> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry compiling #<CL-SOURCE-FILE "antik" "foreign-array" "foreign-array">. 1: [ACCEPT] Continue, treating compiling #<CL-SOURCE-FILE "antik" "foreign-array" "foreign-array"> as having been successful. 2: [ABORT ] Give up on "gsll" 3: Exit debugger, returning to top level. ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:COMPILE-OP (:VERBOSE NIL) {B53E519}> #<ASDF:CL-SOURCE-FILE "antik" "foreign-array" "foreign-array">) 0] 2 ; ; compilation unit aborted ; caught 2 fatal ERROR conditions ("gsll") (#<PACKAGE "AFFI"> #<PACKAGE "ANTIK-USER"> #<PACKAGE "GRID"> #<PACKAGE "ANTIK"> #<PACKAGE "ITERATE"> #<PACKAGE "SPLIT-SEQUENCE"> #<PACKAGE "FOREIGN-STRUCTURES-BY-VALUE"> #<PACKAGE "DRAKMA"> #<PACKAGE "PURI"> #<PACKAGE "CL-BASE64"> #<PACKAGE "CHUNGA"> #<PACKAGE "CL-PPCRE"> #<PACKAGE "USOCKET"> #<PACKAGE "CL+SSL"> #<PACKAGE "FLEXI-STREAMS"> #<PACKAGE "TRIVIAL-GRAY-STREAMS"> #<PACKAGE "BORDEAUX-THREADS"> #<PACKAGE "PURI-SYSTEM"> #<PACKAGE "CL-BASE64-SYSTEM"> #<PACKAGE "CL-PPCRE-ASD"> #<PACKAGE "TRIVIAL-GRAY-STREAMS-SYSTEM"> #<PACKAGE "FLEXI-STREAMS-SYSTEM"> #<PACKAGE "CL+SSL-SYSTEM"> #<PACKAGE "ASDF-SYSTEM-CONNECTIONS-SYSTEM"> #<PACKAGE "CFFI-GROVEL"> #<PACKAGE "CFFI-FEATURES"> #<PACKAGE "CFFI"> #<PACKAGE "CFFI-SYS"> #<PACKAGE "BABEL"> #<PACKAGE "BABEL-ENCODINGS"> #<PACKAGE "ALEXANDRIA.0.DEV"> #<PACKAGE "DRAKMA-ASD"> #<PACKAGE "TRIVIAL-GARBAGE"> #<PACKAGE "QL-SBCL"> #<PACKAGE "SB-BSD-SOCKETS"> #<PACKAGE "SB-BSD-SOCKETS-SYSTEM"> #<PACKAGE "SB-BSD-SOCKETS-INTERNAL"> #<PACKAGE "SB-POSIX-SYSTEM"> #<PACKAGE "SB-GROVEL-SYSTEM"> #<PACKAGE "SB-GROVEL"> #<PACKAGE "SB-POSIX"> #<PACKAGE "QL-MKCL"> #<PACKAGE "QL-ECL"> #<PACKAGE "QL-LISPWORKS"> #<PACKAGE "QL-SCL"> #<PACKAGE "QL-CMUCL"> #<PACKAGE "QL-CLISP"> #<PACKAGE "QL-CCL"> #<PACKAGE "QL-ABCL"> #<PACKAGE "QL-ALLEGRO"> #<PACKAGE "QUICKLISP-CLIENT"> #<PACKAGE "QL-DIST-USER"> #<PACKAGE "QL-DIST"> #<PACKAGE "QL-CDB"> #<PACKAGE "QL-GUNZIPPER"> #<PACKAGE "QL-MINITAR"> #<PACKAGE "QL-HTTP"> #<PACKAGE "QL-PROGRESS"> #<PACKAGE "QL-NETWORK"> #<PACKAGE "QL-IMPL-UTIL"> #<PACKAGE "QL-IMPL"> #<PACKAGE "QL-CONFIG"> #<PACKAGE "QL-SETUP"> #<PACKAGE "QL-UTIL"> #<PACKAGE "ASDF"> #<PACKAGE "COMMON-LISP-CONTROLLER"> #<PACKAGE "COMMON-LISP-USER"> #<PACKAGE "SB-LOOP"> #<PACKAGE "SB-EVAL"> #<PACKAGE "SB-WALKER"> #<PACKAGE "SB-UNIX"> #<PACKAGE "SB-SEQUENCE"> #<PACKAGE "SB-PROFILE"> #<PACKAGE "SB-PRETTY"> #<PACKAGE "SB-MOP"> #<PACKAGE "SB-THREAD"> #<PACKAGE "SB-GRAY"> #<PACKAGE "SB-FORMAT"> #<PACKAGE "SB-FASL"> #<PACKAGE "SB-DISASSEM"> #<PACKAGE "SB-DEBUG"> #<PACKAGE "SB-C"> #<PACKAGE "SB-BIGNUM"> #<PACKAGE "SB-ASSEM"> #<PACKAGE "SB-ALIEN"> #<PACKAGE "SB-PCL"> #<PACKAGE "SB-ALIEN-INTERNALS"> #<PACKAGE "SB-DI"> #<PACKAGE "KEYWORD"> #<PACKAGE "SB-IMPL"> #<PACKAGE "SB-SYS"> #<PACKAGE "SB-KERNEL"> #<PACKAGE "SB-VM"> #<PACKAGE "SB-INT"> #<PACKAGE "SB-EXT"> #<PACKAGE "COMMON-LISP">)

1 0

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

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel