On Sun, 12 Nov 2006 15:14:01 +0200, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> Anders F Björklund wrote:
>> Kristian Kilpi wrote:
>>
>>> So the original question remains: why 'opEquals' returns int?
>>  Walter says it is for performance reason, when e.g. sorting...
>>  http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html
>
> I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool.
>
> Stewart.
>

Yep. Lets consider the following simple loop, which proves the point, I think:

  for(i = 0; i < Y; i++)
     X;

1) If 'X' is complex, then the speed up gained by using 'int' instead of 'bool' is meaningless. E.g. it does not matter if the loop takes 10h 2s instead of 10h 1s.

2) If 'X' is not complex, then the loop is finished in the blink of an eye. Of course, if Y is very large, then the looping takes time and using 'int' could speed up the loop a little (lets say 5%). However, it's very unlikely that Y will ever be large enough. Even million is a small number for Y. We talking about hundred millions here. How often you have such a loop in your program? Maybe if you're doing graphics, but then you wouldn'use the object comparision in the loop. :)

Kristian Kilpi wrote:
> On Sun, 12 Nov 2006 15:14:01 +0200, Stewart Gordon <smjg_1998@yahoo.com> wrote:
<snip>
>> I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool.
<snip>
> Yep. Lets consider the following simple loop, which proves the point, I think:
> 
>   for(i = 0; i < Y; i++)
>      X;
> 
> 1) If 'X' is complex, then the speed up gained by using 'int' instead of 'bool' is meaningless. E.g. it does not matter if the loop takes 10h 2s instead of 10h 1s.
> 
> 2) If 'X' is not complex, then the loop is finished in the blink of an eye. Of course, if Y is very large, then the looping takes time and using 'int' could speed up the loop a little (lets say 5%). However, it's very unlikely that Y will ever be large enough. Even million is a small number for Y. We talking about hundred millions here. How often you have such a loop in your program? Maybe if you're doing graphics, but then you wouldn'use the object comparision in the loop. :)

That's an illustration of how a general expression of type int can be more efficient than the same expression converted to a bool.  But it tells me nothing about how _opEquals_ can be more efficient if it's of type int.

My point is this.  An opEquals of type int will necessarily return 0 for non-equal or non-0 for equal.  But what can this non-0 be that can possibly be more efficient than simply returning 1 if they're equal, and thereby removing the need for the overhead of converting it to bool?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Anders F Björklund wrote:
>> Kristian Kilpi wrote:
>>
>>> So the original question remains: why 'opEquals' returns int?
>>
>> Walter says it is for performance reason, when e.g. sorting...
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html
> 
> I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool.
> 
> Stewart.
> 

Even more so due to the SETE instruction (which gcc uses) and makes converting to a bool after a comparison just as fast as getting an int. I wish Walter would comment on that, because, in the point that the discussion was left using a bool would be just as fast as an int, and I would like a lot of those functions like opEquals to return a bool.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Stewart Gordon wrote:
> 
>> Anders F Björklund wrote:
>>
>>> Kristian Kilpi wrote:
>>>
>>>> So the original question remains: why 'opEquals' returns int?
>>>
>>>
>>> Walter says it is for performance reason, when e.g. sorting...
>>>
>>> http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html
>>
>>
>> I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool.
>>
>> Stewart.
>>
> 
> Even more so due to the SETE instruction (which gcc uses) and makes converting to a bool after a comparison just as fast as getting an int. I wish Walter would comment on that, because, in the point that the discussion was left using a bool would be just as fast as an int, and I would like a lot of those functions like opEquals to return a bool.

I think it was already pointed out that instruction count doesn't tell you anything cycle counts.  SETE maybe one instruction, but that doesn't necessarily mean it's any faster.  I may be.  I don't know.  Just it isn't a given.  Also I you're free to make your own classes return bool from opCmp, it's just Object opCmp that returns int.  And note that it's only for _value_ comparison of objects.

Personally I think Object.opCmp returning int is an oddity, but it pales in comparison with the mixins/imports problem, the ambiguity of auto, and the major bugs left in variadic templates.

--bb

On Mon, 13 Nov 2006 20:16:12 +0200, Bill Baxter <wbaxter@gmail.com> wrote:

> Bruno Medeiros wrote:
>> Stewart Gordon wrote:
>>
>>> Anders F Björklund wrote:
>>>
>>>> Kristian Kilpi wrote:
>>>>
>>>>> So the original question remains: why 'opEquals' returns int?
>>>>
>>>>
>>>> Walter says it is for performance reason, when e.g. sorting...
>>>>
>>>> http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html
>>>
>>>
>>> I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool.
>>>
>>> Stewart.
>>>
>>  Even more so due to the SETE instruction (which gcc uses) and makes converting to a bool after a comparison just as fast as getting an int. I wish Walter would comment on that, because, in the point that the discussion was left using a bool would be just as fast as an int, and I would like a lot of those functions like opEquals to return a bool.
>
> I think it was already pointed out that instruction count doesn't tell you anything cycle counts.  SETE maybe one instruction, but that doesn't necessarily mean it's any faster.  I may be.  I don't know.  Just it isn't a given.  Also I you're free to make your own classes return bool from opCmp, it's just Object opCmp that returns int.  And note that it's only for _value_ comparison of objects.
>
> Personally I think Object.opCmp returning int is an oddity, but it pales in comparison with the mixins/imports problem, the ambiguity of auto, and the major bugs left in variadic templates.
>
> --bb

You're absolutely right. :) I think, also, that template/mixin/import problems should be resolved as soon as possible. Then bugs (e.g. in varidiac templates) should be fixed.

(BTW, you were referring 'opCmp' instead of 'opEquals'. And yes, instruction count tells nothing, it's the cycle counts that, well, counts. And I'd imagine that converting an int to bool should take relative small amount of cycles.)

Kristian Kilpi wrote:
> On Mon, 13 Nov 2006 20:16:12 +0200, Bill Baxter <wbaxter@gmail.com> wrote:
>>
>> Personally I think Object.opCmp returning int is an oddity, but it 

>>> 
> (BTW, you were referring 'opCmp' instead of 'opEquals'. And yes,  

Doh!  you're right.  I just finished reading the page on operator overloading[1] where Walter makes the same mistake and Stewart Gordon's correction on the associated wiki4d page[2].  So I guess opCmp was on the brain.

Fix that page, Walter!

[1] http://www.digitalmars.com/d/operatoroverloading.html
[2] http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/OperatorOverloading

--bb

Bill Baxter wrote:
>                 Also I you're free to make your own classes return bool from opCmp, it's just Object opCmp that returns int.

[You mean opEquals, of course]

Maybe you forgot that a "bool opEquals" doesn't override Object.opEquals :( .
This means that any object ever compared as [1], well, an Object will still need to define "int opEquals" or run into a potentially hard-to-spot bug.


[1]: or /to/, if your "bool opEquals"'s parameter isn't an Object but something else (such as a more derived type, typically that of your class).

Frits van Bommel wrote:
> Bill Baxter wrote:
> 
>>                 Also I you're free to make your own classes return bool from opCmp, it's just Object opCmp that returns int.
> 
> 
> [You mean opEquals, of course]
> 
> Maybe you forgot that a "bool opEquals" doesn't override Object.opEquals :( .
> This means that any object ever compared as [1], well, an Object will still need to define "int opEquals" or run into a potentially hard-to-spot bug.
> 
> 
> [1]: or /to/, if your "bool opEquals"'s parameter isn't an Object but something else (such as a more derived type, typically that of your class).

Yes, I thought that it was uncommon for derived classes to be concerned with comparing against base Objects by value.

--bb

Bill Baxter wrote:
> Frits van Bommel wrote:
>> Bill Baxter wrote:
>>
>>>                 Also I you're free to make your own classes return bool from opCmp, it's just Object opCmp that returns int.
>>
>>
>> [You mean opEquals, of course]
>>
>> Maybe you forgot that a "bool opEquals" doesn't override Object.opEquals :( .
>> This means that any object ever compared as [1], well, an Object will still need to define "int opEquals" or run into a potentially hard-to-spot bug.
>>
>>
>> [1]: or /to/, if your "bool opEquals"'s parameter isn't an Object but something else (such as a more derived type, typically that of your class).
> 
> Yes, I thought that it was uncommon for derived classes to be concerned with comparing against base Objects by value.

Not for classes to be used as an AA key. From http://www.digitalmars.com/d/arrays.html#associative :
-----
*Using Classes as the KeyType*

Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object:

    * hash_t toHash()
    * int opEquals(Object)
    * int opCmp(Object)

Note that the parameter to opCmp and opEquals is of type Object, not the type of the class in which it is defined.
-----

Frits van Bommel wrote:

> Not for classes to be used as an AA key. From http://www.digitalmars.com/d/arrays.html#associative :
> -----
> *Using Classes as the KeyType*
> 
> Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object:
> 
>     * hash_t toHash()
>     * int opEquals(Object)
>     * int opCmp(Object)
> 
> Note that the parameter to opCmp and opEquals is of type Object, not the type of the class in which it is defined.
> -----

Huh, didn't know that.  Haven't done much with AA's yet.

--bb