www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Using <> for opCmp

reply Lionello Lunesu <lio lunesu.remove.com> writes:
The operator < > <= >= all use opCmp, but if you want to differentiate 
between the three cases (< == >) you either have to call opCmp yourself 
or use multiple comparisons.

I'd like to suggest using the operator <> for an implicit call to opCmp, 
returning the actual comparison value (<0, 0, >0).

* <> is already valid and used (albeit for floats only ATM)
* if(x<>y) will work as supposed to without additional changes (in fact, 
it already does**)
* no explicit reference to the hidden function "opCmp"

L.

**It seems that <> already works, but it returns a boolean true/false, 
instead of an integer, so it currently is the same as !=.
Nov 24 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:


 The operator < > <= >= all use opCmp, but if you want to differentiate 
 between the three cases (< == >) you either have to call opCmp yourself 
 or use multiple comparisons.
 
 I'd like to suggest using the operator <> for an implicit call to opCmp, 
 returning the actual comparison value (<0, 0, >0).


I would prefer using <=> for this, as that is what Perl already does...
It is commonly used when writing sort functions, and called "starship".

Think it was suggested before, but the language wasn't taking in any
more operators at the time ? (The other one was ^^ for logical Xor.)

--anders
Nov 24 2006
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Anders F Björklund wrote:

 Lionello Lunesu wrote:
 

 The operator < > <= >= all use opCmp, but if you want to differentiate 
 between the three cases (< == >) you either have to call opCmp 
 yourself or use multiple comparisons.

 I'd like to suggest using the operator <> for an implicit call to 
 opCmp, returning the actual comparison value (<0, 0, >0).


 
 I would prefer using <=> for this, as that is what Perl already does...
 It is commonly used when writing sort functions, and called "starship".
 
 Think it was suggested before, but the language wasn't taking in any
 more operators at the time ? (The other one was ^^ for logical Xor.)
 
 --anders


The thing is, <> already exists! It's doing too much at the moment: it 
converts the int return value from opCmp to a boolean.

L.
Nov 24 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Lionello Lunesu wrote:
<snip>

 The thing is, <> already exists! It's doing too much at the moment: it 
 converts the int return value from opCmp to a boolean.


Exactly.  And that's indeed what I'd expect it to do.  Why do you feel 
that it's "too much"?

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.
Nov 26 2006
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:ekcecj$iig$1 digitaldaemon.com...

 Lionello Lunesu wrote:
 <snip>

 The thing is, <> already exists! It's doing too much at the moment: it 
 converts the int return value from opCmp to a boolean.


 Exactly.  And that's indeed what I'd expect it to do.  Why do you feel 
 that it's "too much"?


The original opCmp return value is lost, so currently <> is exactly the same 
as != (except using opCmp instead of opEquals, I'd hope). Converting the 
integer return value to a boolean is an extra operation, with added 
instructions. If this 'conversion to bool' was to be dropped, if (a<>b) 
would still behave the same way, with less instructions, and the added 
benifit of access to opCmp's value.

At the moment, if you want to distinguish between the three cases, a<b, 
a==b, a>b, you will have to do two comparisons (resulting in either one call 
to opCmp and one to opEquals, or two calls to opCmp). To prevent these extra 
comparisons, you have to call opCmp explicitely, but then you'll have to 
know the type of the variables (for built-ins you need different code than 
for classes), not mentioning the fact that you reference the function opCmp 
(which I think should be hidden as much as possible).

Now, if <> were to return the opCmp return value as an integer, you can do 
int cmp = a<>b; and have the three cases (<, ==, >) right there, without 
having to call opCmp, or worrying about the types. And it'll be faster code, 
too.

I'm really rather surprised by the resistance. I'm not suggesting a new 
operator, merely changing an existing one slightly, improving its 
performance, whilst keeping it backward compatible. It should be a dead 
giveaway. Not getting people convinced shows how bad I am at making my point 
:S

L.
Nov 27 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Lionello Lunesu wrote:

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:ekcecj$iig$1 digitaldaemon.com...

 Lionello Lunesu wrote:
 <snip>

 The thing is, <> already exists! It's doing too much at the moment: it 
 converts the int return value from opCmp to a boolean.


 Exactly.  And that's indeed what I'd expect it to do.  Why do you feel 
 that it's "too much"?


 
 The original opCmp return value is lost, so currently <> is exactly the same 
 as != (except using opCmp instead of opEquals, I'd hope). 


Not quite.
x != y
is not the same as
x <> y
if x and y are reals (eg, x=2, y = real.nan:  x!=y is TRUE, but x <> y 
is FALSE).

I would expect that in the future there'd be an opUnorderedCmp(),
which the NCEG operators would use (As well as floating point, the NCEG 
operators could be used for tribools and SQL comparisions with NULL, for 
example).
Nov 27 2006
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:eke9uq$2et5$1 digitaldaemon.com...

 Lionello Lunesu wrote:

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:ekcecj$iig$1 digitaldaemon.com...

 Lionello Lunesu wrote:
 <snip>

 The thing is, <> already exists! It's doing too much at the moment: it 
 converts the int return value from opCmp to a boolean.


 Exactly.  And that's indeed what I'd expect it to do.  Why do you feel 
 that it's "too much"?


 The original opCmp return value is lost, so currently <> is exactly the 
 same as != (except using opCmp instead of opEquals, I'd hope).


 Not quite.
 x != y
 is not the same as
 x <> y
 if x and y are reals (eg, x=2, y = real.nan:  x!=y is TRUE, but x <> y is 
 FALSE).

 I would expect that in the future there'd be an opUnorderedCmp(),
 which the NCEG operators would use (As well as floating point, the NCEG 
 operators could be used for tribools and SQL comparisions with NULL, for 
 example).


Right, for reals there's no simple "int opCmp", since there are more 
relations than the usual three, but even for reals <> could be made to 
return an int, where a value of 0 would not only mean a==b, but also 'either 
a or b is NaN' (correct?)

L.
Nov 27 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:


 The original opCmp return value is lost, so currently <> is exactly the same 
 as != (except using opCmp instead of opEquals, I'd hope).


But it seems to be using opEquals... At least it does when using GDC.


 I'm really rather surprised by the resistance. I'm not suggesting a new 
 operator, merely changing an existing one slightly, improving its 
 performance, whilst keeping it backward compatible. It should be a dead 
 giveaway. Not getting people convinced shows how bad I am at making my point 
 :S


Or maybe you are wrong about it, and <> is in fact a boolean operator ?
(i.e. as far as I know, != and <> are the same for non-floating types)

I think opCmp should be give a new operator, but not holding my breath.

--anders
Nov 27 2006
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Anders F Björklund wrote:

 Lionello Lunesu wrote:
 

 The operator < > <= >= all use opCmp, but if you want to differentiate 
 between the three cases (< == >) you either have to call opCmp 
 yourself or use multiple comparisons.

 I'd like to suggest using the operator <> for an implicit call to 
 opCmp, returning the actual comparison value (<0, 0, >0).


 
 I would prefer using <=> for this, as that is what Perl already does...
 It is commonly used when writing sort functions, and called "starship".
 
 Think it was suggested before, but the language wasn't taking in any
 more operators at the time ? (The other one was ^^ for logical Xor.)
 
 --anders


Sure is kinda funny when we start using emoticons for operators... ^^

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 25 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 Think it was suggested before, but the language wasn't taking in any
 more operators at the time ? (The other one was ^^ for logical Xor.)


 
 Sure is kinda funny when we start using emoticons for operators... ^^


Must be getting old (or not around the globe enough), hadn't seen those.

(You too ? Look at http://en.wikipedia.org/wiki/Verticon for the {^_^} )

--anders
Nov 25 2006
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

 Think it was suggested before, but the language wasn't taking in any
 more operators at the time ? (The other one was ^^ for logical Xor.)


 Sure is kinda funny when we start using emoticons for operators... ^^


 
 Must be getting old (or not around the globe enough), hadn't seen those.
 
 (You too ? Look at http://en.wikipedia.org/wiki/Verticon for the {^_^} )
 
 --anders


I don't understand the logic sequence between those two sentences: you 
say you don't know that emoticon, but then you should you do, and ask if 
I don't know the emoticon? ... Huh? Of course I know. Confusion ensues :P )


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 28 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 I don't understand the logic sequence between those two sentences: you 
 say you don't know that emoticon, but then you should you do, and ask if 
 I don't know the emoticon? ... Huh? Of course I know. Confusion ensues :P )


Nah, I meant "if someone else needs to look it up, here's a link".
As in someone reading it other than the original poster, i.e. you.

Sorry for the confusion, it got pasted together...  :-) ^_^ (-:

--anders
Nov 28 2006
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Bruno Medeiros wrote:

 
 Sure is kinda funny when we start using emoticons for operators... ^^
 


I can't wait to see what kind of functionality can be provided using the 
Homer Simpson operator:

~(_8^(|)

Maybe it can be some sort of exception-handling operator. D'oh!!!

--benji
Nov 27 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Benji Smith wrote:

 Bruno Medeiros wrote:

 Sure is kinda funny when we start using emoticons for operators... ^^


 
 I can't wait to see what kind of functionality can be provided using the 
 Homer Simpson operator:
 
 ~(_8^(|)
 
 Maybe it can be some sort of exception-handling operator. D'oh!!!
 
 --benji


Oooo, make it a D easter egg?! <g>
Nov 27 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Kyle Furlong wrote:
<snip>

 Oooo, make it a D easter egg?! <g>


What's the point of hiding Easter eggs if we've already found them?

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.
Nov 28 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Stewart Gordon wrote:

 Kyle Furlong wrote:
 <snip>

 Oooo, make it a D easter egg?! <g>


 
 What's the point of hiding Easter eggs if we've already found them?
 
 Stewart.
 


We (early adopters) hide easter eggs for the new converts of 1.0 and beyond.
Nov 28 2006