[Gsll-devel] Array indexing syntactic sugar (was: Introducing "Grid Structured Data")

[Mirko Vukovic]

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<http://www.mat.uc.pt/preprints/ps/p0516.pdf>
.

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<http://www.nmr.mgh.harvard.edu/%7Eadunn/papers/dissertation/node32.html>.
 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<http://paste.lisp.org/display/93525>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 at 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 at 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 at 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 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/20100116/f25ad1ba/attachment.html>