[Gsll-devel] About the naming convention in gsll

[Mirko Vukovic]

On Fri, May 16, 2008 at 3:20 PM, Zach <elzacho at 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 at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>
>