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 !=.

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

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.

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

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

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.

"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.

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).

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

"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.