Regan Heath <regan@netwin.co.nz> wrote in news:opsajaypgc5a2sq9@digitalmars.com:


> What do you want a[4..12] = a[3..11] to do exactly?
> 
> It looks to me like you want to basically do a
> 
> memmove(&a[4],&a[3],typeof(a[0]).sizeof * 8);

Yes, exactly what b[4..12] = a[3..11] does right
now in D.  a[4..12] = a[3..11] won't work
because the memory areas overlap.

Stephen Waits wrote:

> My only suggestion is that these vector expressions be able to expand to handle non-trivial cases.  For example, think of calculating a vector cross product, or matrix multiplication, quaternion multiplication, etc.

I don't think, that would be a good idea: Plain vector operations cover *elementwise* operations. With a good concept, it should be possible to stay flexible and extensible enough, if this is put into the language.

The operations you are suggesting go far beyond that in complexity. Of course, you could great performance having matrix multiplications etc. built into the language and optimized by the compiler, but that would be far beyond what an extensible general purpose language should do.

The better way to go here would be to go for expression template programming which should just be handled in a cleaner way than in C++. There, you can implement your linear/quaternion or whatever algebra and hand-tune it for your needs.

Vector expressions would certainly help you some way, since they already eliminate much of the problems involving temporary objects, but beyond that meta-programming would be the way to go.

Ciao,
Nobbi

PS: Since you are talking about quaternions - have you ever heard about Geometric Algebra (as introduced by David Hestenes)? For handling geometry in mathematics and computation, this is even more powerful than quaternions. Takes a while to get used to that kind of mathematical language, but once you've understood the key concepts, geometry suddenly becomes so much clearer! (And code possibly more efficient as well - there is some promising research going on in that direction.)

Knud Sørensen wrote:

> Take a look at my array suggestions at
> http://dlanguage.netunify.com/56
> feel free to add to the wiki.

I think I've read these suggestions before. My feeling is that they are a bit too specialized to a certain kind of application, and that the simplicity of the syntax for the special cases you are listing would make it hard to grasp more general cases as well.

Specifically:
* The syntax you propose for "swizzling" and "write masking" collides badly
with the multidimensional array syntax that has already started to become
part of the language with the introduction of the new opIndex.

* The Einstein summation in mathematics is just laziness. It makes sense to drop the summation sign in rotationally (or in spacetime: relativistic) invariant expressions. But outside of geometry, indices may mean many other thing than tensor indices. Turning everything into a sum just because there are two identical indices appearing would be really annoying there.

I am thinking about a good syntax for index notation that would probably capture all the cases of use that you are mentioning. The result will probably need a bit more typing than your suggestions, but it should also be a lot more flexible.

On Sat, 03 Jul 2004 09:51:11 +0200, Norbert Nemec wrote:

> Stephen Waits wrote:
> 
>> My only suggestion is that these vector expressions be able to expand to handle non-trivial cases.  For example, think of calculating a vector cross product, or matrix multiplication, quaternion multiplication, etc.
> 
> I don't think, that would be a good idea: Plain vector operations cover *elementwise* operations. With a good concept, it should be possible to stay flexible and extensible enough, if this is put into the language.

Einstein notation would give you all this and much more.
it would also give you powerful vectorization and avoid temporaries.

agian I invite you to take a look at http://dlanguage.netunify.com/56

and tell me what you think.

Knud

Walter wrote:

> Why can't we make the current array operations serve this purpose?

They are not flexible enough. Consider this example in pseudo-syntax:

        for(int i=0;i<10;i++)
        for(int j=0;i<10;i++)
                B[i,j] = sin(A[i,j]);

How would you vectorize this?
        B[] = sin(A[]);
would only work if sin is defined on arrays. So either you define a fixed
set of functions in the language, or you define it in the library. But to
define it in the library, you would still need to do the operation inside
the function, and there you can only reside to a good-old-loop breaking all
the performance gain of vectorization.

One first idea might be to just use every function element-wise in array expressions, but then you would still run into problems on cases like:

        for(int i=0;i<10;i++)
        for(int j=0;i<10;i++)
                D[i,j] = A[i,j]+C[i];


What is needed is a "vector expression" that uses index notation. A few ideas, I'm shuffling around:

        index i,j;   // declare i and j to be indices for a vector expression
        B[i,j] = sin(A[i,j]);
        D[i,j] = A[i,j] + C[i];

or

        B[] = [i=0..10,j=0..10](sin(A[i,j]));
        D[] = [i=0..10,j=0..10](A[i,j] + C[i]);

In the second notation you could do really powerful things like:

        real[8,8] E = [i=0..8,j=0..8]((i+j)%2); // initialize a chess-board
        real[8,8] F = [i=0..8,j=0..8](sin(i*j)); // initialize a 2D-sin wave
        real[8,8] G = [i=0..8,j=0..8]((i+j)%2 ? sin(i*j) : 0);
                                    // initialize a masked sine-wave

I'm not fully happy about the syntax yet. The ideas will probably just need some time to ripen.

In any case, I believe the current array expressions can be preserved as well. Both kinds of expressions would merge together well into one concept. Just use the index-free notation for simple cases and use indices when you need the full flexibility.

On Sat, 03 Jul 2004 10:06:59 +0200, Norbert Nemec wrote:

> Knud Sørensen wrote:
> 
>> Take a look at my array suggestions at
>> http://dlanguage.netunify.com/56
>> feel free to add to the wiki.
> 
> I think I've read these suggestions before. My feeling is that they are a bit too specialized to a certain kind of application, and that the simplicity of the syntax for the special cases you are listing would make it hard to grasp more general cases as well.
> 
> Specifically:
> * The syntax you propose for "swizzling" and "write masking" collides badly
> with the multidimensional array syntax that has already started to become
> part of the language with the introduction of the new opIndex.
> 
> * The Einstein summation in mathematics is just laziness.
Yes, it seams like laziness at first but I see it more like a mathematically refactoring.

> It makes sense to
> drop the summation sign in rotationally (or in spacetime: relativistic)
> invariant expressions.
> But outside of geometry, indices may mean many other
> thing than tensor indices. Turning everything into a sum just because there
> are two identical indices appearing would be really annoying there.
> 

You only make the summation when you make a multiplication so linear combinations of transformation is also possible. I have droped the co- and contra-variant notation as too domain specific so invariant transformation would have to be deal with explicit.


> I am thinking about a good syntax for index notation that would probably capture all the cases of use that you are mentioning. The result will probably need a bit more typing than your suggestions, but it should also be a lot more flexible.

Great, I look forward to it.

Knud

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:cc5rm4$2juo$1@digitaldaemon.com...
> Walter wrote:
>
> > Why can't we make the current array operations serve this purpose?
>
> They are not flexible enough. Consider this example in pseudo-syntax:
>
>         for(int i=0;i<10;i++)
>         for(int j=0;i<10;i++)
>                 B[i,j] = sin(A[i,j]);
>
> How would you vectorize this?
>         B[] = sin(A[]);
> would only work if sin is defined on arrays. So either you define a fixed
> set of functions in the language, or you define it in the library. But to
> define it in the library, you would still need to do the operation inside
> the function, and there you can only reside to a good-old-loop breaking
all
> the performance gain of vectorization.
>
> One first idea might be to just use every function element-wise in array expressions, but then you would still run into problems on cases like:
>
>         for(int i=0;i<10;i++)
>         for(int j=0;i<10;i++)
>                 D[i,j] = A[i,j]+C[i];
>
>
> What is needed is a "vector expression" that uses index notation. A few ideas, I'm shuffling around:
>
>         index i,j;   // declare i and j to be indices for a vector
expression
>         B[i,j] = sin(A[i,j]);
>         D[i,j] = A[i,j] + C[i];
>
> or
>
>         B[] = [i=0..10,j=0..10](sin(A[i,j]));
>         D[] = [i=0..10,j=0..10](A[i,j] + C[i]);
>
> In the second notation you could do really powerful things like:
>
>         real[8,8] E = [i=0..8,j=0..8]((i+j)%2); // initialize a
chess-board
>         real[8,8] F = [i=0..8,j=0..8](sin(i*j)); // initialize a 2D-sin
wave
>         real[8,8] G = [i=0..8,j=0..8]((i+j)%2 ? sin(i*j) : 0);
>                                     // initialize a masked sine-wave
>
> I'm not fully happy about the syntax yet. The ideas will probably just
need
> some time to ripen.
>
> In any case, I believe the current array expressions can be preserved as well. Both kinds of expressions would merge together well into one
concept.
> Just use the index-free notation for simple cases and use indices when you need the full flexibility.

Sounds great! But the syntax really shouldn't look like that,
the "[i=0..8,j=0..8]" part looks like an array litteral, even if they
aren't declared like this.

When i think about it again , it could work like that if array litterals had
some
other syntax. :)

Knud Sørensen wrote:

> On Sat, 03 Jul 2004 09:51:11 +0200, Norbert Nemec wrote:
> 
>> Stephen Waits wrote:
>> 
>>> My only suggestion is that these vector expressions be able to expand to handle non-trivial cases.  For example, think of calculating a vector cross product, or matrix multiplication, quaternion multiplication, etc.
>> 
>> I don't think, that would be a good idea: Plain vector operations cover *elementwise* operations. With a good concept, it should be possible to stay flexible and extensible enough, if this is put into the language.
> 
> Einstein notation would give you all this and much more.
> it would also give you powerful vectorization and avoid temporaries.
> 
> agian I invite you to take a look at http://dlanguage.netunify.com/56
> 
> and tell me what you think.

See my other message about it. Just one point for clarification:

Something like:
        a[i,j] = sum(k){b[i,k]*c[k,j]};  // Pseudo-syntax!
is called *index-notation* - this is exactly the core of my concept for
vector operations. (I have no idea yet how to do aggregators like "sum",
but they will definitely be needed) It was used in mathematics long before
Einstein was born.

The term "Einstein-Notation" on the other hand only refers to dropping the "sum" in the above expression, saying this sum is implicitly to be understood if one index appears twice. Einstein introduced that convention because he was lazy and because it really saves on writing in relativistic calculations. In contexts outside of relativity, geometry and linear algebra, this convention does not make much sense, though and actually even gets in the way.

Therefore: index-notation makes perfect sense in D, Einstein-notation (i.e. summing over indices implicitly) would just be extremely confusing and counterproductive in many areas.

Knud Sørensen wrote:

>> * The Einstein summation in mathematics is just laziness.
> Yes, it seams like laziness at first but I see it more like a mathematically refactoring.

Of course - in analytic mathematics, it really hits the point. In a correct (i.e. invariant) expression, all the indices have to pair up exactly.

Anyhow: linear algebra is just one use for indices in a computer language. There are many other uses as well where indices behave completely different.

Ivan Senji wrote:

> Sounds great! But the syntax really shouldn't look like that,
> the "[i=0..8,j=0..8]" part looks like an array litteral, even if they
> aren't declared like this.
> 
> When i think about it again , it could work like that if array litterals
> had some
> other syntax. :)

For one, there are no array literals at all. There are array initializers, but that's something different.

Apart from that, it's just a first idea. The exact syntax of course has to be fit into the language much cleaner.

In general, I'm not really sure, whether I like the idea of using brackets for both array literals and array indexing. Maybe, using braces for both array and struct literals might be a better idea. But that again might collide with block delimiters. It really is a pity that we have only three kinds of paired delimiters to choose from. :-(