Norbert Nemec wrote:

>J Anderson wrote:
>  
>
>>It would cost something.  We would have C++ where operators are used for
>>anything.  Anyhow I've shown how this can be overcome.
>>    
>>
>
>If you look at "cost" in terms of language and compiler complexity, it would
>not cost anything. The comfort for the programmer would also stay the same,
>since current code would just work as now. As long as you don't use
>opMul_r, you don't have to worry about it. As long as you use only
>commuting objects, there will never be any reason for opMul_r.
>
>If you - as I understand your remark - consider "cost" the increased danger
>of abuse of language constructs (Meaning evil programmers defining "*"
>operators that have nothing to do with multiplication.) then the existance
>of opMul_r and opAdd_r will change little.
>
>Therefore I really don't understand why you say "Allowing opMul_r would cost
>something."
>
>So, if opMul_r does not cost anything, I don't see any reason to try to find
>out whether you can work around it in any case. If anybody ever needs to
>box a scalar or take the pains of using delegates or whatever means just
>because someone decided that opMul_r is "unnecessary", then clearly this
>decision was wrong.
>  
>

Problems arrives when you have operator clashes.  If you have op_r and op defined in both classes which one do you pick?  You've just killed both class operators.  Walter wants to avoid this problem (which is in C++) as much as possible.  The solution I presented doesn't suffer from that problem.

Sadly of the other operators will suffer from this problem.

-- 
-Anderson: http://badmama.com.au/~anderson/

> There is no point in elementwise multiplying two matrices.

I disagree. Maybe the misunderstanding is about vocabulary. If you think of the word "matrix" only in the linear algebra sense then sure you never element-wise multiply them but if you think of the word "matrix" as a 2D array of data (more like a spreadsheet or something) then you element-wise multiply all the time. I work at the MathWorks (makers of MATLAB) so I have seen lots and lots of code that does both. MATLAB uses * for matrix mult and .* for element-wise mult.

-Ben

J Anderson wrote:
> Problems arrives when you have operator clashes.  If you have op_r and op defined in both classes which one do you pick?  You've just killed both class operators.  Walter wants to avoid this problem (which is in C++) as much as possible.  The solution I presented doesn't suffer from that problem.

That is not a problem at all. "a op b" can be translated to "a.op(b)" or "b.op_r(a)". It can NOT be translated to "b.op(a)" or "a.op_r(b)".

And since there is a clear precedence rule between op and op_r (op comes first) there is no ambiguity at all.

Hauke

True, this is just about vocabulary.

For me, "Matrix" only refers to the mathematical object in the linear algebra sense. Everything else would be an array. Matlab mixes both and therefore needs different operators. The cleaner approach is to separate the data types and define the operators accordingly. For arrays, the sensible default are elementwise operations, for (mathematical) matrices these do not make much sense (except maybe somewhere inside the implementation of certain algorithms) and the plain old "*" operator should be used for linear algebra multiplications of all sorts, depending on the type of the objects (inner, outer and matrix product)

The strong point in object oriented programming is, that you can give semantics to objects. In Matlab, you just have a 2D-array of numbers that get their meaning only by the operations that you use on them. A specific linear algebra library gives the internal array far richer semantics. The first is better for quick and dirty programming, the second for more disciplined software design. (Like with weak vs. strong typing)

Ben Hinkle wrote:

> 
>> There is no point in elementwise multiplying two matrices.
> 
> I disagree. Maybe the misunderstanding is about vocabulary. If you think of the word "matrix" only in the linear algebra sense then sure you never element-wise multiply them but if you think of the word "matrix" as a 2D array of data (more like a spreadsheet or something) then you element-wise multiply all the time. I work at the MathWorks (makers of MATLAB) so I have seen lots and lots of code that does both. MATLAB uses * for matrix mult and .* for element-wise mult.
> 
> -Ben

J Anderson wrote:
> Problems arrives when you have operator clashes.  If you have op_r and op defined in both classes which one do you pick?  You've just killed both class operators.  Walter wants to avoid this problem (which is in C++) as much as possible.

That problem would already be cleanly solved by the three rules in the often
cited:
        http://www.digitalmars.com/d/operatoroverloading.html

If the compiler finds an expression a*b, it will

1. first try to interpret it as a.opMul(b)
2. if that does not exist, try b.opMul_r(a)
3. if that also does not exist, try b.opMul(a)

and if that does not exist, give up issueing an error.

For noncommuting operators like "/", step 3 would be skipped.

Currently, for commuting operators like "*", step 2 is skipped for no good reason.

My request would only be to reintroduce (2.) for "*" and "+". For any
existing code, opMul_r does not exist, so this change would not matter. For
any truely commuting objects, b.opMul_r(a) and b.opMul(a) are identical, so
if the programmer really implements b.opMul_r(a) it is just redundant.

As you see, the problem of the ambiguity was already solved be putting the three rules into the language spec. It is just a matter of actually allowing programmers to implement opMul_r where it is appropriate.

> The solution I presented doesn't suffer from
> that problem.
> 
> Sadly of the other operators will suffer from this problem.

Sorry, I lost overview over which solution you mean. In any case, by simply allowing opMul_r and opAdd_r, there is no ambiguity and nobody feels a difference unless they really implement it, in which case it just works in a straightforward way.

Hauke Duden wrote:

> J Anderson wrote:
>> Problems arrives when you have operator clashes.  If you have op_r and op defined in both classes which one do you pick?  You've just killed both class operators.  Walter wants to avoid this problem (which is in C++) as much as possible.  The solution I presented doesn't suffer from that problem.
> 
> That is not a problem at all. "a op b" can be translated to "a.op(b)" or
> "b.op_r(a)". It can NOT be translated to "b.op(a)" or "a.op_r(b)".
> 

Well, YES, actually for op="*", it will be translated to b.opMul(a) in step 3. of the precedence rules.

Norbert Nemec wrote:
>>That is not a problem at all. "a op b" can be translated to "a.op(b)" or
>>"b.op_r(a)". It can NOT be translated to "b.op(a)" or "a.op_r(b)".
>>
> 
> 
> Well, YES, actually for op="*", it will be translated to b.opMul(a) in step
> 3. of the precedence rules.
> 

I meant that these would be the reasonable rules for non-commutative operators. I.e. that it is no problem to define something unambiguous.

Sorry for not making it clear.

Hauke

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c660ah$uef$1@digitaldaemon.com...
> Actually, no. I thought so myself (that's why I started the thread) but
>         http://www.digitalmars.com/d/operatoroverloading.html
> explicitely states the rules after which the compiler determines which
code
> to use. Writing
>         A*B
> then first A.opMul(B) is checked. Only if this does not exist, B.opMul(A)
is
> called. This solves the problem, if the library author takes care not to forget any definitions. Only in that case the compiler might swap factors without a warning.
>
> The only thing that may still be discussed, and will probably pop up over and over again until Walter gives in, is the question of opMul_r and opAdd_r. I believe it would make sense to allow those and check them
before
> commuting factors, but I can live without them.

You're right, and they're in.

Walter wrote:

> 
> "Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c660ah$uef$1@digitaldaemon.com...
>> Actually, no. I thought so myself (that's why I started the thread) but
>>         http://www.digitalmars.com/d/operatoroverloading.html
>> explicitely states the rules after which the compiler determines which
> code
>> to use. Writing
>>         A*B
>> then first A.opMul(B) is checked. Only if this does not exist, B.opMul(A)
> is
>> called. This solves the problem, if the library author takes care not to forget any definitions. Only in that case the compiler might swap factors without a warning.
>>
>> The only thing that may still be discussed, and will probably pop up over and over again until Walter gives in, is the question of opMul_r and opAdd_r. I believe it would make sense to allow those and check them
> before
>> commuting factors, but I can live without them.
> 
> You're right, and they're in.

Wow - you really have your newgroup well-sorted! Having somebody answer to ~9 months old messages happens rarely these days...

Anyway: I had already noticed from the specs that you had changed that detail. Thanks a lot!

"Norbert Nemec" <Norbert@Nemec-online.de> wrote in message news:ctjilv$1fck$1@digitaldaemon.com...
> Wow - you really have your newgroup well-sorted! Having somebody answer to ~9 months old messages happens rarely these days...

Well, it was a long & important thread, and I thought it needed a bit of closure for the archives.

> Anyway: I had already noticed from the specs that you had changed that detail. Thanks a lot!

You're welcome.