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