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

[Liam Healy]

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 at 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 at 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 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
>>
>
>
> _______________________________________________
> Gsll-devel mailing list
> Gsll-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>
>