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:
  1. Compatibility with GSLL and LAPACK (and NETLIB for that matter).  When doing numerics, I would use grid (or xarray) and forget about cl-arrays.
  2. More forgiving interface in array creation: coerce supplied values to declared type
  3. 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