I hope this post does not offend the creator of gsll, as this is not the intent. There are two ways to read this post: One is that it may raise a valid point, and the other that I am missing something already provided, or a mode of using the routines that would make this comment unnecessary.
So, in effect, I think (as a newbie) I am missing something. But what?
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
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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
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
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.
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.
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.
Liam
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
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
On Fri, May 16, 2008 at 5:33 PM, Mirko Vukovic mirko.vukovic@gmail.com wrote:
On Fri, May 16, 2008 at 5:02 PM, Liam Healy lhealy@common-lisp.net wrote:
...
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.
Unfortunately, there isn't a huge amount of documentation. Basically, for most implementations, the array needs to exist on the foreign (C) side for GSL to have access to it, and an identical copy needs to exist the CL side for your Lisp functions to access it. Keeping them in sync is requires copying. That is what you are doing with the letm binding of say a* to a: you are copying a (CL) to a* (C). At the end, if you do a #'data of the result, you are copying back.
Once ffa is incorporated, I hope it will all be there under the hood without anyone having to worry about it. But that unfortunately is not going to happen in the next few weeks anyway.
...
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.
You are not ever going to pass by value. I don't know of any language in which arrays are passed by value (maybe C if you put it in a struct and pass the struct by value). Perhaps what you mean is that you are trying to avoid evaluation? If that is so, you are not doing this; it is still evaluating (as it must), it is just doing the evaluation after the macro expansion.
Liam
On Fri, May 16, 2008 at 05:02:18PM -0400, Liam Healy wrote:
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 would agree. Putting gsll: before function names is the way to go.
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
I second that. In a lot of calculations, many matrices are intermediate results and will be discarded anyhow, there is little sense in copying them.
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 looking forward to that...
Tamas
Mirko,
I was unsure of what you meant when you first mentioned a macro. It should be pointed out that unlike in the C world, a lisp macro is not a forced inline version of a function. The is an inline declaration statement that (on efficiency minded compilers) inlines functions in your code. Macros are used for different things that functions. 99.9% (perhaps 100%) of the time, using a macro as you have described is not a good idea as you can get better functionality by defining an function (inlined if necessary).
Also, I am happy to see that Liam has posted a reply clearing up the comment on passing arrays by value. In most languages (including CL) certain objects are passed by value (in Lisp, numbers and characters), and some are passed by pointer, err, reference, don't know what exactly to call it (in Lisp, pretty much everything else). This was a point of confusion in my head when I first learned Lisp; it took me a while to realize that Lisp's implicit behavior is exactly the same as C's explicit behavior (with the exception of C's struct copying).
Foreign Friendly Arrays (FFA) is a library. You will not find info on it in the hyperspec. Look at the author's website (I believe this is your work, Tamas, right?) or the archives of this mailing list for that matter.
Zach
On Fri, May 16, 2008 at 3:44 PM, Tamas K Papp tpapp@princeton.edu wrote:
On Fri, May 16, 2008 at 05:02:18PM -0400, Liam Healy wrote:
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 would agree. Putting gsll: before function names is the way to go.
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
I second that. In a lot of calculations, many matrices are intermediate results and will be discarded anyhow, there is little sense in copying them.
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 looking forward to that...
Tamas _______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
On Fri, May 16, 2008 at 04:20:48PM -0600, Zach wrote:
Also, I am happy to see that Liam has posted a reply clearing up the comment on passing arrays by value. In most languages (including CL) certain objects are passed by value (in Lisp, numbers and characters), and some are passed by pointer, err, reference, don't know what exactly to call it (in Lisp, pretty much everything else). This was a point of confusion in my head when I first learned Lisp; it took me a while to realize that Lisp's implicit behavior is exactly the same as C's explicit behavior (with the exception of C's struct copying).
I learned to like the CL approach. My philosophy is that I only copy arrays when they are modified, everywhere else I just pass the "reference".
Foreign Friendly Arrays (FFA) is a library. You will not find info on it in the hyperspec. Look at the author's website (I believe this is your work, Tamas, right?) or the archives of this mailing list for that matter.
The original announcement is here: http://tkpapp.blogspot.com/2007/12/announcement-ffa.html
It is asdf-installable, but one can also get the source from my website.
What ffa does is that it tries to make a Lisp array available to C functions if the implementation and the array type permits (eg pinning in SBCL), and if not, it will be copied back and/or forth as needed. The package has a tutorial which I think explains things well. I prefer to keep my arrays in Lisp, hence this package.
Tamas
-
Liam Healy -
Mirko Vukovic -
Tamas K Papp -
Zach