On Fri, May 16, 2008 at 5:02 PM, Liam Healy lhealy@common-lisp.net wrote:
My naming scheme was somewhat arbitrary, but I was attempting to use "normal" names, rather than truncated C-like names with boilerplate identifiers prepended (like gsl_). I am certainly amenable to changing it, but I think Zach's suggestion about packages is what I intended: you shouldn't really program in the GSLL package; make your own package like gsll-user and you can do whatever you want.
I keep forgetting about packages and the gsll-user type option. I agree with it.
But the larger question is what are the "usable" functions. GSLL is fairly low-level now, of necessity. You have to start somewhere in building a lisp-natural interface, and it was necessary to get it good enough to be usable and to establish the common definitions that it could be put out for others to join in and work on higher level interfaces.
So I'm willing to change things, certainly. However, the example you gave I am not sympathetic to; you don't like GSLL taking #'solve-tridiagonal because you do a mass copying of arrays and you want that mandatory and built-in. I don't think copying should be part of the library call because the user is compelled to pay a copying penalty which may (and should) be minimized by working in foreign arrays throughout the computation. What if the array came from another GSLL calculation; would you build in a copying to CL at the end and then copy it back to C? What if there were several, or several thousand, such chained calculations? There were some spots where I struggled with whether to copy or not; in some cases it copies but in places where I felt chaining was likely it does not.
Can you give me advice on how to handle that? maybe a pointer to some documentation? I tried divining from hyperlisp on numeric types, but did not get far.
I am not familiar with the concept of foreign array. I'll try to read up on that.
As a side point, I am working on incorporating foreign-friendly arrays, and there is a separate function (currently called make-array*) that creates arrays, similar to make-array, but the type specification is mandatory. If you are using SBCL, the C array is the CL array; if not, the right thing will always happen (once debugged...).
I am unclear on what the point of the macro is; if it were a function it would do the same thing. There is no passing by value in any case as far as I know; do you mean a copying of arrays? You're going to get that anyway; there's no way to avoid it in ANSI standard CL.
I was trying to avoid passing by value. The way I understood macros, the macro would be expanded into a let form during compilation, and thus the original variables would be used.
Liam
Thanks
Mirko
On Fri, May 16, 2008 at 4:28 PM, Mirko Vukovic mirko.vukovic@gmail.com wrote:
On Fri, May 16, 2008 at 3:20 PM, Zach elzacho@gmail.com wrote:
Mirko,
I am in the same boat as you as I have rarely used GSLL for anything.
I hope to use it more for numerics and data analysis, within nlisp. But I am (even after a few months) just starting with lisp, and my synapses are still lacking.
However, name conflicts in CL can be dealt with by the package system, right? As in,
(defpackage :gsll-wrapper (:use :cl) (:export #:letm #:vector-double-float #:data ;; And the rest of the GSLL names you like ) (:shadow #:solve-tridiagonal) ) ; shadow GSLL's function and replace it
(in-package :gsll-wrapper)
;; Define your SOLVE-TRIDIAGONAL (defun solve-tridiagonal (args*) your definition ... (gsll:solve-tridiagonal ...) more stuff ... )
Your suggestion seems very sensible.
Then, just use your custom wrapped version of GSLL instead.
Perhaps I am wrong, but it seems that GSLL is shaping up to be a relatively low level binding to GSL. Luckily, the issue you raise is easily corrected. In my opinion, you are right that much work can be done in the direction of abstracting away the foreign feel of GSLL.
That seems correct. That is why I felt that the functions generated by GSLL should correspond closely to GSLL names, since they are essentially wrappers. One would hope that with time, there would be a superset package with a more lispy interface.
One concern I have is that if we wrap a GSLL within a function, then we may end up passing variables by value from the top level down, which is inefficient. I *hope* that if the second level wrappers are written as macros this dissapears.
For example I defined the following macro: (defmacro solve-tridiag (d e f b) `(letm ((d* (vector-double-float ,d)) (e* (vector-double-float ,e)) (f* (vector-double-float ,f)) (x* (vector-double-float (make-array (length ,d) :element-type 'double-float :initial-element 0d0))) (b* (vector-double-float ,b))) (solve-tridiagonal d* e* f* b* x*) (data x*)))
I am not too strong with macros, but I am hoping that since the macro is expanded at compile time, there is no passing by value of variables d,e,f,b.
Zach
I hope the GSLL's author, Liam, takes these comments in stride, since he did awesome work, and what we are discussing here is the "dressing" on an otherwise a very cool package.
Mirko
I find the naming convention in gsll inconvenient. For example the routine solve-tridiagonal is a wrapper for gsl_linalg_solve_tridiag. To use it to solve a system defined by vectors d e f b, one needs to use a letm block to this effect:
(letm ((d* (vector-double-float d)) (e* (vector-double-float e)) (f* (vector-double-float f)) (x* (vector-double-float (make-array (length d) :element-type 'double :initial-element 0d0)) (b* (vector-double-float b))) (solve-tridiagonal d* e* f* b* x*) (data x*))
Using the routine solve-tridiagonal is still not convenient, because one still needs to convert the argument vectors via the vector-double-float, obscuring the code. If I have multiple calls, I will have to repeat these, or define my own interface function. And here is the problem: *the very nice name solve-tridiagonal is taken*. I could name it solve-tridiag, but sooner or later, I will make a mistake and call the wrong function with the incorrect arguments.
Ideally, once we have gsll, one would just need to do (solve-tridiagonal d e f b). To accomplish that, gsll would need to use the following convention:
- the c-code wrapper would be named the same as the c-code, except
with the underscores replaced with dashes. Thus we would have (defmfun gsl-linalg-solve-tridiag (diag e f b x) "gsl_linalg_solve_tridiag" (((pointer diag) gsl-vector-c) ((pointer e) gsl-vector-c) ((pointer f) gsl-vector-c) ((pointer b) gsl-vector-c) ((pointer x) gsl-vector-c)) :invalidate (x)... etc)
- Users/contributors can define interface routines that would link to
the gsll routine: (defun solve-tridiag (d e f b) (letm ((d* (vector-double-float d)) (e* (vector-double-float e)) (f* (vector-double-float f)) (x* (vector-double-float (make-array (length d) :element-type 'double :initial-element 0d0)) (b* (vector-double-float b))) (solve-tridiagonal d* e* f* b* x*) (data x*))
(I have not tried it, but maybe macros should be better to remove the pass-by-value cost of calling the routine).
So, what am I missing?
Thanks,
Mirko _______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel