Mirko,
My philosophy is that specialty cases like these are best handled with iterate forms and the appropriate iterate extensions. I think too much effort is spent trying to make things "elegant" for unusual cases, and it's just not worth it. Of course you're free to define your own macros, but I don't find the form using the macro to be more transparent than an iterate form would be. Of course if I were thoroughly versed in the application and using similar constructs a lot, I might think otherwise.
So I guess I'm after easy of use/transparency for the common linear algebra and similar cases, and willing to let the users write their own iterate forms for unusual cases.
Liam
On Sat, Jan 16, 2010 at 9:44 PM, Mirko Vukovic mirko.vukovic@gmail.com wrote:
This is a follow up on the syntactic sugar for array referencing that I referred to in my wish list. Here is what I had in mind.
A few weeks ago, I needed the inverse of a tridiagonal matrix. I found an algorithm on the web. See the first page of the following pdf document.
I am looking for a cleaner and simpler way to transcribe equations (1.1) and the two below in lisp. Note a few things. In the equation for `theta', the index of `theta' varies from 0...n, while all the other ones are from 1...n.
Another problem of interest is the Yee algorithm for the numerical solution of time-dependent Maxwell equations. Take a look at the equations following (4.12) on the following page. The indices are, among other things, i+1/2. The notation stems from the fact that the algorithm uses two staggered grids, one for the electric, and the other for the magnetic fields. The 1/2 reflects the grid offset. Of course, in actual implementation, the fields are stored in matrics, and the indices are integers.
For both of these cases, one has to do some kind of index transformation, so that E_{i+1/2} becoms (aref E (some-function-of i)). With many equations, for scatterbrains like me, that is a recipe for a missed or miscalculated offset.
I came up with a macros that will transform code that contains symbols like E_i+1/2 into an appropriately referenced `aref' or `maref' by using symbol-macrolet.
For the theta equations, see the following code snippet on paste.lisp.org, where the with-_-indexing1 macro does the transforming. One thing to be aware of is that the macros expand into code of `finite' length. So, inserting this macro as follows (if (...) (with-_-indexing () (if clause) (else clause)) will be inaccurate. One has to move the `with-_-indexing' outside of the `if'.
When I clean up my routines, I will post them (somewhere, not yet sure where). And if anyone has a better idea how to name the macros, please let me know.
Mirko
On Tue, Jan 12, 2010 at 5:20 PM, Mirko Vukovic mirko.vukovic@gmail.com wrote:
Features that I would like:
Compatibility with GSLL and LAPACK (and NETLIB for that matter). When doing numerics, I would use grid (or xarray) and forget about cl-arrays. More forgiving interface in array creation: coerce supplied values to declared type syntactic sugar: refer to array subscripts using underscores: a_i_j or a_2:5_*
On that last point, I have a small utility that does the first example. I am not sure where to post it for your review. I think github is overkill to post three files (asd, package, and lisp).
I am intrigued by xarrays' generic interface, so that xarrays can interface with `any type of object'. I fail to see its use now, but that is just my lack of imagination.
On a `lack of imagination' topic, can someone give me an example of indexing that xarray has, and that the affine indexing cannot accomplish?
Thanks,
Mirko
On Sun, Jan 10, 2010 at 3:20 PM, Liam Healy lhealy@common-lisp.net wrote:
I don't think there's any doubt we all want one all-singing all-dancing interface that provides array utility for everything in CL that needs it. The reason there are two starts is because we both started in parallel without the being aware of the other's work. The reason that GSD only got as far as it did was because I had addressed the complaints on this mailing list and elsewhere (including me) and I had no more time. I do not think of it as complete.
So the real work here is going through both sets of code and figuring out how to unify them. I think all the help we can get would be welcome; I'm certainly willing to work toward the goal.
To get the ball rolling, start with a feature at a user's level that you need; I mean by this some very specific thing that you've coded in CL already and found to be clumsy. Then see how each package implements it or would implement it. Then post to the list your findings, together with your example if possible, to start a discussion. Anyone can do this; I don't think there's a need to restrict to a "third party"; we lack a first party at the moment. By picking single feature(s) and working from there, we will incrementally get to the goal we all seek. If we try to do everything at once or at the most abstract level, we're likely not going to get there as quickly.
Liam
On Sun, Jan 10, 2010 at 11:50 AM, A.J. Rossini blindglobe@gmail.com wrote:
My cursory look suggests a fair amount of similarity as well, and I find attractive features in both -- but want just one API!
A reasonable proposal, from my highly biased perspective, would be a 3rd party merge of the better components of each.
(I've spent time with the xarray interface, which is the source of my biases -- it mostly works for what I want to do, despite being a simplification of the lisp-matrix access approach -- which isn't bad, there are some lisp-matrix functionality which is strictly edge-case relevant...
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