View mode: basic / threaded / horizontal-split · Log in · Help
November 24, 2006
Using <> for opCmp
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 !=.
November 24, 2006
Re: Using <> for opCmp
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
November 24, 2006
Re: Using <> for opCmp
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.
November 25, 2006
Re: Using <> for opCmp
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
November 25, 2006
Re: Using <> for opCmp
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
November 26, 2006
Re: Using <> for opCmp
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.
November 27, 2006
Re: Using <> for opCmp
"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.
November 27, 2006
Re: Using <> for opCmp
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).
November 27, 2006
Re: Using <> for opCmp
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
November 27, 2006
Re: Using <> for opCmp
"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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home