April 21, 2004
The problem down there just exemplifies what I mean:

If you use that mat3 multiplication:

        mat3 A,B;
        A = ...;
        B = ...;

now A*B is different from B*A. The language definition, though, allows the compiler to swap factors of a product.

Obviously, as long as you only use matrix*matrix operation, the compiler has no reason to swap them except for optimization purposes. So obviously, you never ran into problems with your code. Anyhow: a different compiler might just transform an A*B into a B*A randomly and your code will break down completely.

B.t.w: scalar*matrix=matrix*scalar, but p.e. matrix*columnvector does not, and actually columnvector*matrix does not even exist!



J Anderson wrote:

> Jan-Eric Duden wrote:
> Have you tried dig matrices yet.  They work this way.  I mean, with a
> matrix class you have access to both sides of the equation.   It's only
> with privative types that there is this problem.  Commute is more then
> possible for matrices.
> 
> //From dig:
>     /** Multiply matrices. */
>     mat3 opMul (mat3 mb)
>     {
>         mat3 mo;
>         float [] a = array ();
>         float [] b = mb.array ();
>         float [] o = mo.array ();
> 
>         for (int i; i < 3; i ++)
>         {
>             o [i + 0] = a [i] * b [0] + a [i + 3] * b [1] + a [i + 6] *
> b [2];
>             o [i + 3] = a [i] * b [3] + a [i + 3] * b [4] + a [i + 6] *
> b [5];
>             o [i + 6] = a [i] * b [6] + a [i + 3] * b [7] + a [i + 6] *
> b [8];
>         }
> 
>         return mo;
>     }
> 
> I'm afraid you've miss-understood what the documentation means.
> 
> Try it.  Send in a dig example that doesn't compute the correct result.
> 
> //(Untested)
> mat3 n, o;
> ...
> if (n * o == o * m)
> {
>     printf("multiplication is equal\n");
> }
> 

April 21, 2004
Jan-Eric Duden wrote:

>  :)  I like it if those issues pop up again and again.
> Maybe it convinces Walter that there is a good reason to change D in that
> aspect..
> 

Well, it will probably pop up again everytime somebody tries to implement a matrix class in D. I don't know whether Walter ever used Matrices in programming, but everybody who did will agree that it is not a minor request but an urgent recommendation no allow for noncommutative multiplication.

(Especially, since the gain by defining opMul commutative is neglectible.)
April 21, 2004
for example: :)
a:
[ 3    3    1]
[-3    2    2]
[ 5    2    3]
b:
[1    0    4]
[0    1    0]
[0    0    1]

a*b
[ 3    3     13]
[-3    2    -10]
[ 5    2     23]

b*a
[23    11    13]
[-3     2     2]
[ 5     2     3]


-- 
Jan-Eric Duden
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c65joj$92k$1@digitaldaemon.com...
> Jan-Eric Duden wrote:
>
> >>This example
> >>is not a problem for D, because you are multiplying a matrix by a
> >>matrix.
> >>
> >>
> >No.
> >think of following matrix operation:
> >Translate(-1.0,-1.0,-1.0)*RotateX(30.0)*Translate(1.0,1.0,1.0)
> >which is different from
> >Translate(1.0,1.0,1.0)*RotateX(30.0)*Translate(-1.0,-1.0,-1.0)
> >or
> >RotateX(30.0)*Translate(1.0,1.0,1.0)*Translate(-1.0,-1.0,-1.0)
> >
> >
> Have you tried dig matrices yet.  They work this way.  I mean, with a matrix class you have access to both sides of the equation.   It's only with privative types that there is this problem.  Commute is more then possible for matrices.
>
> //From dig:
>     /** Multiply matrices. */
>     mat3 opMul (mat3 mb)
>     {
>         mat3 mo;
>         float [] a = array ();
>         float [] b = mb.array ();
>         float [] o = mo.array ();
>
>         for (int i; i < 3; i ++)
>         {
>             o [i + 0] = a [i] * b [0] + a [i + 3] * b [1] + a [i + 6] *
> b [2];
>             o [i + 3] = a [i] * b [3] + a [i + 3] * b [4] + a [i + 6] *
> b [5];
>             o [i + 6] = a [i] * b [6] + a [i + 3] * b [7] + a [i + 6] *
> b [8];
>         }
>
>         return mo;
>     }
>
> I'm afraid you've miss-understood what the documentation means.
>
> Try it.  Send in a dig example that doesn't compute the correct result.
>
> //(Untested)
> mat3 n, o;
> ...
> if (n * o == o * m)
> {
>     printf("multiplication is equal\n");
> }
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/


April 21, 2004
Norbert Nemec wrote:

>The problem down there just exemplifies what I mean:
>
>If you use that mat3 multiplication:
>
>        mat3 A,B;
>        A = ...;
>        B = ...;
>
>now A*B is different from B*A. The language definition, though, allows the
>compiler to swap factors of a product.
>  
>
I think this is only on the primitive level.

>Obviously, as long as you only use matrix*matrix operation, the compiler has
>no reason to swap them except for optimization purposes. So obviously, you
>never ran into problems with your code. Anyhow: a different compiler might
>just transform an A*B into a B*A randomly and your code will break down
>completely.
>  
>
So now your arguing what the specs says is different from what the compiler does?

Walter is fully aware of how matrices work.  I don't think he would let this one fall down.

>B.t.w: scalar*matrix=matrix*scalar, but p.e. matrix*columnvector does not,
>and actually columnvector*matrix does not even exist!
>  
>
You should overload matrix to include columnvector ie like dig (vec3).

-- 
-Anderson: http://badmama.com.au/~anderson/
April 21, 2004
Maybe we should give Walter homework. :)
Everytime we can think of a use-case where D has drawbacks over other
languages, we formulate an excercise and Walter needs to solve elgantly it
with the current D compiler. :)

-- 
Jan-Eric Duden

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c65lgt$bd8$2@digitaldaemon.com...
> Jan-Eric Duden wrote:
>
> >  :)  I like it if those issues pop up again and again.
> > Maybe it convinces Walter that there is a good reason to change D in
that
> > aspect..
> >
>
> Well, it will probably pop up again everytime somebody tries to implement
a
> matrix class in D. I don't know whether Walter ever used Matrices in programming, but everybody who did will agree that it is not a minor request but an urgent recommendation no allow for noncommutative multiplication.
>
> (Especially, since the gain by defining opMul commutative is neglectible.)


April 21, 2004
Jan-Eric Duden wrote:

>for example: :)
>a:
>[ 3    3    1]
>[-3    2    2]
>[ 5    2    3]
>b:
>[1    0    4]
>[0    1    0]
>[0    0    1]
>
>a*b
>[ 3    3     13]
>[-3    2    -10]
>[ 5    2     23]
>
>b*a
>[23    11    13]
>[-3     2     2]
>[ 5     2     3]
>
>
>  
>
I don't know why I waste my time proving what you say is nonsense <g>

import std.c.stdio;
import net.BurtonRadons.dig.common.math;
import std.process;

void main()
{
   mat3 a= mat3.create(3, 3, 1, -3, 2, 2, 5, 2, 3);
   mat3 b = mat3.create(1, 0,  4,  0, 1, 0, 0, 0, 1);

   printf("a\n");
   a.print();
   printf("b\n");
   b.print();

   printf("a * b\n");
   mat3 c = a * b;
   c.print();
     printf("b * a\n");
   mat3 d = b * a;
   d.print();

  std.process.system("pause");
}

output:
a
[  3 3 1 ]
[ -3 2 2 ]
[  5 2 3 ]

b
[ 1 0 4 ]
[ 0 1 0 ]
[ 0 0 1 ]

a * b
[  3 3  13 ]
[ -3 2 -10 ]
[  5 2  23 ]

b * a
[ 23 11 13 ]
[ -3  2  2 ]
[  5  2  3 ]


-- 
-Anderson: http://badmama.com.au/~anderson/
April 21, 2004
Sorry about the complaints concerning commuting operators. I just reread the language definition and found I misunderstood a detail:

The compiler actually is only allowed to swap operands if there is no routine defined doing the operation in the right order. With this restriction, it is actually possible to write a correct matrix library.

One has to take care, of course, not to leave out any combination, because the compiler would produce wrong code instead of complaining, but is something I can live with.

Ciao,
Nobbi
April 21, 2004
Norbert Nemec wrote:

>Sorry about the complaints concerning commuting operators. I just reread the
>language definition and found I misunderstood a detail:
>
>The compiler actually is only allowed to swap operands if there is no
>routine defined doing the operation in the right order. With this
>restriction, it is actually possible to write a correct matrix library.
>
>One has to take care, of course, not to leave out any combination, because
>the compiler would produce wrong code instead of complaining, but is
>something I can live with.
>
>Ciao,
>Nobbi
>  
>
Much better then C++, because you only need to overload 8 rather then 28 operators (in general).

-- 
-Anderson: http://badmama.com.au/~anderson/
April 21, 2004
Uhm. That depends how you interpret the matrices - as row vectors or as
column vectors.
In any case, your program proofs as well that b*a != a*b !

-- 
Jan-Eric Duden
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c65mvr$e8h$1@digitaldaemon.com...
> Jan-Eric Duden wrote:
>
> >for example: :)
> >a:
> >[ 3    3    1]
> >[-3    2    2]
> >[ 5    2    3]
> >b:
> >[1    0    4]
> >[0    1    0]
> >[0    0    1]
> >
> >a*b
> >[ 3    3     13]
> >[-3    2    -10]
> >[ 5    2     23]
> >
> >b*a
> >[23    11    13]
> >[-3     2     2]
> >[ 5     2     3]
> >
> >
> >
> >
> I don't know why I waste my time proving what you say is nonsense <g>
>
> import std.c.stdio;
> import net.BurtonRadons.dig.common.math;
> import std.process;
>
> void main()
> {
>     mat3 a= mat3.create(3, 3, 1, -3, 2, 2, 5, 2, 3);
>     mat3 b = mat3.create(1, 0,  4,  0, 1, 0, 0, 0, 1);
>
>     printf("a\n");
>     a.print();
>     printf("b\n");
>     b.print();
>
>     printf("a * b\n");
>     mat3 c = a * b;
>     c.print();
>
>     printf("b * a\n");
>     mat3 d = b * a;
>     d.print();
>
>    std.process.system("pause");
> }
>
> output:
> a
> [  3 3 1 ]
> [ -3 2 2 ]
> [  5 2 3 ]
>
> b
> [ 1 0 4 ]
> [ 0 1 0 ]
> [ 0 0 1 ]
>
> a * b
> [  3 3  13 ]
> [ -3 2 -10 ]
> [  5 2  23 ]
>
> b * a
> [ 23 11 13 ]
> [ -3  2  2 ]
> [  5  2  3 ]
>
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/


April 21, 2004
As far as I understand the docs, this is not correct:
opAdd and opMul are supposed to be commutative. There is no opAdd_r or
opMul_r.
see http://www.digitalmars.com/d/operatoroverloading.html : Overloadable
Binary Operators

-- 
Jan-Eric Duden

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c65n80$er1$1@digitaldaemon.com...
> Sorry about the complaints concerning commuting operators. I just reread
the
> language definition and found I misunderstood a detail:
>
> The compiler actually is only allowed to swap operands if there is no routine defined doing the operation in the right order. With this restriction, it is actually possible to write a correct matrix library.
>
> One has to take care, of course, not to leave out any combination, because the compiler would produce wrong code instead of complaining, but is something I can live with.
>
> Ciao,
> Nobbi