"Walter" <walter@digitalmars.com> wrote in message news:bkim0p$30sm$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bki5gj$2apn$1@digitaldaemon.com...
> > If ++x is converted to x += 1 automatically, then what if you overload operator + to take something besides int type?
> >
> > And if you do mapp ++x to x += 1, then you should also automatically map
> x++
> > to temp = x, x += 1, temp, and similarly for x--
> >
> > 99% of the time what I do want to use overloading for IS a mathematical type.  But I've seen some really neat stuff done with operator
> overloading,
> > things that the inventors would never have considered.
>
> There is always that risk that perhaps this shuts the door on something.
But
> although I don't agree with using arithmetic operator overloading for non-arithmetic purposes, that's a purely stylistic issue. Sorry if my opinions come on a little strong about it sometimes. What the arithmetic operator overloading rules do, however, is make it much easier to make a user-defined arithmetic type and integrate it into the language. For example, only one comparison operator needs to be written, rather than the
8
> in C++.

I'm not really against it in some cases.  I'm just not sure ++ == +1 is a good one.  It seems unbalanced.

Sean

In article <bkfejk$27cl$3@digitaldaemon.com>, Walter wrote:
> 
> "Jeroen van Bemmel" <someone@somewhere.com> wrote in message news:bkfcts$238q$1@digitaldaemon.com...
>> Walter,
>>
>> In http://www.digitalmars.com/d/operatoroverloading.html surely the
> boolean
>> comparison operators <, >, <= and >= are not commutative?
> 
> Sure they are!
>     a < b
> and
>     b > a

The mathematical term would be "anticommutative".

"An operator * for which

a * b = -b * a

is said to be anticommutative"

http://mathworld.wolfram.com/Anticommutative.html

-Antti

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbmr5a2.qqp.jsykari@pulu.hut.fi...
> The mathematical term would be "anticommutative".
>
> "An operator * for which
>
> a * b = -b * a
>
> is said to be anticommutative"
>
> http://mathworld.wolfram.com/Anticommutative.html

I didn't know that! Thanks for the pointer.

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bkj2q9$g5u$1@digitaldaemon.com...
> without proper property syntax,
> what happens with a property or function that returns a class that
> overloads opCall ?

You'll need to have an extra ().

Walter wrote:
> "Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message
> news:slrnbmr5a2.qqp.jsykari@pulu.hut.fi...
> 
>>The mathematical term would be "anticommutative".
>>
>>"An operator * for which
>>
>>a * b = -b * a
>>
>>is said to be anticommutative"
>>
>>http://mathworld.wolfram.com/Anticommutative.html
> 
> 
> I didn't know that! Thanks for the pointer.
> 
> 

isn't that -... realy the inverse of ... for op *

and is it
a * b = inv(b) * a
or is it  a * b = inv (b*a)
(the latter is true for subtraction and division)

"Antti Sykäri" <jsykari@gamma.hut.fi> escreveu na mensagem news:slrnbmr5a2.qqp.jsykari@pulu.hut.fi...
> In article <bkfejk$27cl$3@digitaldaemon.com>, Walter wrote:
> >
> > "Jeroen van Bemmel" <someone@somewhere.com> wrote in message news:bkfcts$238q$1@digitaldaemon.com...
> >> Walter,
> >>
> >> In http://www.digitalmars.com/d/operatoroverloading.html surely the
> > boolean
> >> comparison operators <, >, <= and >= are not commutative?
> >
> > Sure they are!
> >     a < b
> > and
> >     b > a
>
> The mathematical term would be "anticommutative".
>
> "An operator * for which
>
> a * b = -b * a
>
> is said to be anticommutative"
>
> http://mathworld.wolfram.com/Anticommutative.html
>
> -Antti


Hmmm, I think the correct definition would be "antisymmetric", for the cmp operation. We can just assume cmp behaving as a infinite matrix and the parameters are the possible indices (or something like that ;)

http://mathworld.wolfram.com/Antisymmetric.html


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18/9/2003

> > without proper property syntax,
> > what happens with a property or function that returns a class that
> > overloads opCall ?
>
> You'll need to have an extra ().
>
>

This is a reason why IMHO it would be better to have a property keyword. That way it would be possible to forward call to an inner class with changing the class interface in the same way that in C++ we can chain operator->.

An example:

class A {
    void opCall(int i);
}

class B {
    property A prop_name() { return a }

    A a;
}

// used that way:

B b;
b.prop_name(5);

// instead of

B b;
b.prop_name()(5);

This make it possible to replace a function by
a class without needing the client code to be
aware of it...

But thinking of it, it would probably caused ambiguities
if we allows both syntax (function call vs property)

>
> I'm not really against it in some cases.  I'm just not sure ++ == +1 is a good one.  It seems unbalanced.
>
> Sean
>
>

I would say that it should be possible to define ++ or -- if += or -= is not
defined for a type (like it would be the case for an iterator in C++ STL
that is not a random iterator). In those case, we might prefer to have
only ++ and/or -- defined.

OTOH, always defining ++ from += (if that one is defined), is not a good
idea either... For example, the following will loop infinitly and it might
not
be desirable that the code compile than way:

for (double d = 1e16; d < 1.01e16; ++d)
{
    // Do something with d...
}

Also for some type like an enum (or a class that would emulate it if it does not apply), it is simpler to implement increment by one that by an arbitrary number...

IMO, if we support both eq and cmp for a class at the same time, why for ++ and +=, they must always be defined one in the term of the other ?

On that issues, if cmp is implemented for a type but not eq, will eq, == and != be implemented in terms of cmp ?

In article <bkkt1b$112p$1@digitaldaemon.com>, Mike Wynn wrote:
> Walter wrote:
>> "Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbmr5a2.qqp.jsykari@pulu.hut.fi...
>> 
>>>The mathematical term would be "anticommutative".
>>>
>>>"An operator * for which
>>>
>>>a * b = -b * a
>>>
>>>is said to be anticommutative"
>>>
>>>http://mathworld.wolfram.com/Anticommutative.html

It seems I was kind of tired when I posted that (not that the situationis much better now). On the second thought, the term does not apply. I recall We were having a < b == b > a and here < and > are different operators (relations, actually) but the anticommutativity only talks about one. And still it wouldn't work, except in some weird boolean algebra where "-" means not and where "a = b" never holds.  What is anticommutative, though, is the cmp() function.

>> I didn't know that! Thanks for the pointer.
>> 
>> 
> 
> isn't that -... realy the inverse of ... for op *
> 
> and is it
> a * b = inv(b) * a
> or is it  a * b = inv (b*a)
> (the latter is true for subtraction and division)

With subtraction and division, the operator just makes its right side into its inverse under the operation and then does the normal operation (addition for -, multiplication for /). So at least the latter identity is true (at least as long if the normal operation commutes). But I think we're talking about a pretty thin abstraction here, if you can use the term in mathematics. Something that can be derived from the ring axioms (or was it something less than that? Semi-ring? Group? Too tired for that..)

(Anticommutativity might be more interesting... interestingly, the keyword finds only two pages in MathWorld, Lagrange Brackets and Poisson Brackets.  Stuff that I recall having studied once at the theoretical physics course)

-Antti

AFAIK:

< and > are not ordinal operators, are strict ordinal operators.

The right term for <= and >= is "antisimetric" ( OK, with bad english )
i.e.:

a<=b AND b<=a => a=b (necessarily).

So, an op is antisimetric if "a OP b" and "b OP a" involves "a=b"



In article <bklaa0$1iue$1@digitaldaemon.com>, Daniel Yokomiso says...
>
>"Antti Sykäri" <jsykari@gamma.hut.fi> escreveu na mensagem news:slrnbmr5a2.qqp.jsykari@pulu.hut.fi...
>> In article <bkfejk$27cl$3@digitaldaemon.com>, Walter wrote:
>> >
>> > "Jeroen van Bemmel" <someone@somewhere.com> wrote in message news:bkfcts$238q$1@digitaldaemon.com...
>> >> Walter,
>> >>
>> >> In http://www.digitalmars.com/d/operatoroverloading.html surely the
>> > boolean
>> >> comparison operators <, >, <= and >= are not commutative?
>> >
>> > Sure they are!
>> >     a < b
>> > and
>> >     b > a
>>
>> The mathematical term would be "anticommutative".
>>
>> "An operator * for which
>>
>> a * b = -b * a
>>
>> is said to be anticommutative"
>>
>> http://mathworld.wolfram.com/Anticommutative.html
>>
>> -Antti
>
>
>Hmmm, I think the correct definition would be "antisymmetric", for the cmp operation. We can just assume cmp behaving as a infinite matrix and the parameters are the possible indices (or something like that ;)
>
>http://mathworld.wolfram.com/Antisymmetric.html
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.520 / Virus Database: 318 - Release Date: 18/9/2003
>
>