September 21, 2003 Re: operator overloading philosophy | |
---|---|

Posted in reply to Walter | "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 |

September 21, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Walter | 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 |

September 21, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Antti Sykäri | ```
"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.
``` |

September 21, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Mike Wynn | ```
"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 ().
``` |

September 21, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Walter | ```
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)
``` |

September 21, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Antti Sykäri | "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 |

September 21, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Walter | ```
> > 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)
``` |

September 21, 2003 Re: operator overloading philosophy | |
---|---|

Posted in reply to Sean L. Palmer | ```
>
> 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 ?
``` |

September 22, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Mike Wynn | 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 |

September 22, 2003 Re: DMD 0.73 release | |
---|---|

Posted in reply to Daniel Yokomiso | ```
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
>
>
``` |