View mode: basic / threaded / horizontal-split · Log in · Help
September 21, 2003
Re: operator overloading philosophy
"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
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
"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
"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
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
"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
> > 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
>
> 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
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
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
>
>
3 4 5 6 7 8
Top | Discussion index | About this forum | D home