Re: [Boost-users] proto for array expressions

Subject: Re: [Boost-users] proto for array expressions
From: John Phillips (phillips_at_[hidden])
Date: 2008-12-18 21:08:55

Eric Niebler wrote:
> James Sutherland wrote:
>>
>> On Dec 18, 2008, at 3:46 PM, Eric Niebler wrote:
>>
>>> Daniel Oberhoff wrote:
>>>> Now with proto I was wondering how hard it would be to build an et 
>>>> engine for array math. Basically I am interested in general tensor 
>>>> notation, and the resulting expressions should be iteratable 
>>>> efficiently. think (advanced example):
>>>> a_ij = b_i * (c_j - sum(d_ijk, k = [i-1,1])
>>>
>>> I don't understand your notation. What are a_ij et. al.?
>>>
>> Presumably Einstein notation:
>>   a_i  = vector
>>   a_ij  = 2D matrix
>>   a_ijk = 3D array
>> so that
>>   b_i c_j
>> is the outer product of two vectors, producing a matrix...
> 
> I guess I'm dense, but I still don't get it. What does this expression 
> mean?
> 
>   a_ij = b_i * (c_j - sum(d_ijk, k = [i-1,1])
> 
> At any rate, it requires a domain expert to say how hard it would be to 
> implement a given DSEL, and I'm not a linear algebra domain expert. I've 
> done my best to document Proto extensively, and I can answer questions 
> about Proto but not about linear algebra.
> 

   It looks like he is trying to produce a statement for the Einstein 
sum convention. It reduces the number of indices on a tensor, by summing 
over matching indices. That would make the rest of his equation make sense.

   I probably can count as well informed, if not expert on tensor 
algebra, and I'm not entirely sure whether it is viable. My problem is 
coming up with a reasonable grammar for describing the set of possible 
manipulations that is large enough to express the useful states while 
being clear enough that anyone could actually code with it.

   The next paragraph is mostly aimed at the tensor friendly in the 
audience, though I will try to explain if anyone wants me to.

   The basic problem is that tensor notation is intentionally very 
compact. Whether an index is a subscript or a superscript matters. 
Whether two indices in the same tensor match (and since an outer product 
makes one tensor, in the same outer product) matters. Inclusion of 
things like commas and semi-colons (which would obviously have to be 
replaced) matter. Other, not always locally obvious in the code factors 
also would matter (such as the metric tensor, in many cases).

   In all, it is great notation for some mathematical/physical work, but 
I haven't come up with an abstraction that I like. Maybe someone else 
can be more insightful and see a good way to do it, but I think that 
will be the crux of a good system, and a useful proto based implementation.

                        John