[Gsll-devel] About the naming convention in gsll

[Zach]

Mirko,

I am in the same boat as you as I have rarely used GSLL for anything.

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 ... )

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.

Zach



> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20080516/28dd35fd/attachment.html>