Comparison Operators 4

[straybullet]

Perhaps one (or more) of you can mediate here...

There has been a debate raging around here regarding the use and meaning of comparison operators.

For instance, there are some who say that using 'NOT <=' is not the same as using '>' (and that the inverse is also not true). There are those who say it is.

Which is truly correct and how should this be explained to the naysayers?

Other examples:
“NOT <=” “>”
“NOT >=” “<”
“NOT >” “<=”
“NOT <” “>=”

Thanks in advance!!

Let them hate - so long as they fear... Lucius Accius

 

[SkipVought]

stray,

I'd agree that they ARE equivilant.

> VALUE == Not <= VALUE
[sub]
How are things in the Keystone State? (Born in Phillie, raised near Norristown, lived near Pittsburg, family in 'Billtown' & 'Chocolate Town')[/sub]

Skip,
[sub]
Just traded in my old subtlety...
for a NUANCE![/sub]

 

[r937]

if you're talking about mathematics, with actual numbers, then yes

if you're talking about SQL, which has NULLs, then maybe not (no pun intended)

NULL is not greater than any number, and it is also not less than any number

so if you toss NOT into the mix...

<voice="elmer fudd">be vewy, vewy cawefuw</voice>

;-)

r937.com | rudy.ca

 

[MasterRacker]

Good point. Nulls make all kinds of things "interesting".

Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[SQLSister]

I'm still trying to wrap my head around why I would want to use NOT <= even if it was equivalent to >? (Apparently Not <= doesn't work in SQl Server anyway.) The meaning concerning nulls is unclear and it's more characters to type. It would be easier to maintain "where test > 1" or "where test >1 or test = null" because the developer would know if you intended to include the null values.

"NOTHING is more important in a database than integrity." ESquared

 

[straybullet]

Thanks all! I tried explaining that Not <=100 would result in 101 and greater the same as >100 does. Falls on deaf ears.

Skip - as expected tis chilly in the great state of Pennsyltucky. The air is crisp and the rut is on! The fun part in all this is that these 'options' magically appeared on all the BW forms over the course of a weekend with no warning or explanation.

r937 and Master - good point on the nulls. I've been hesitant to even bring that up, at least until the first part's been accepted.

SQLSister - I have no idea why they would use Not <= either. But it's there (as well as >, Not >= & <) and the BW developers refuse to understand that all it's doing is confusing alot of the users - who I may add actually understand my explanation that they actually mean the same thing and to just use the one they are most comfortable with (> or <).

Let them hate - so long as they fear... Lucius Accius

 

[SkipVought]

"Not <=100 would result in 101 and greater "

Only with INTEGER arithmetic.

>100 includes 100.00000000001

for instance.

Pennsyltucky! I thot I was the only one that missused that! ;-)

Skip,
[sub]
Just traded in my old subtlety...
for a NUANCE![/sub]

 

[r937]

datetimes present the same conceptual problem

WHERE somedate BETWEEN '2008-11-01' and '2008-11-30'

this will miss out an entire day's worth of transactions (those for the 30th)

better is the open-ended upper range end --

WHERE somedate >= '2008-11-01'
AND somedate < '2008-12-01'

which has the added benefit that you don't have to generate the ending date with complex days-in-month logic, but rather just by adding INTERVAL 1 MONTH


r937.com | rudy.ca

 

[Thargy]

stray,

may I humbly recommend that strange quirky beast, known as a test. Don't argue or discuss with people, just set up definitive tests and demonstrate the results in whatever environment you're using. Even the most arrogant know-it-all has to shut his or her trap when confronted with irrefutable evidence that they're spouting nonsense.

Second, I would file such drivel under the heading of "clever" code. I used to be impressed by people who could write "clever" code, about 20 years ago that is. Now I know better. If you have clever code, you have to be clever to maintain and support it. Give me childishly simple, pellucidly clear code any day. I am simple, so I can only maintain simple code.

Folks who come out with such things are a dangerous carcinogen in your dev team, extirpate the disease ASAP, lest ye die!

Regards

T

 

[ousoonerjoe]

Give me childishly simple, pellucidly clear code any day. I am simple, so I can only maintain simple code.

Folks who come out with such things are a dangerous carcinogen in your dev team, extirpate the disease ASAP, lest ye die!

Amen.

--------------------------------------------------
"...and did we give up when the Germans bombed Pearl Harbor? NO!"

"Don't stop him. He's roll'n."
--------------------------------------------------

 

[straybullet]

True Skip - but we're not actually doing math with them... it's more a matter of setting criteria for a search. For instance, needing to find all the customer accounts within a certain numeric range.

You know tharg, I actually sent a set of screenshots of query results using the different choices.... they still argued! There's no getting through to some people is there!

Let them hate - so long as they fear... Lucius Accius

 

[Olaf Doschke]

certain languages compare certain things different than expected. VFP for example makes use of a partial string comparision to speed things up, eg a search for some field value beginning with "A" can be done as WHERE name="A" instad of WHERE NAME LIKE "A%".

Because the right side value only has one char the comparison also only takes one char of the name field in consideration. This also is true for > or < comparsion. So because "AB"="A" is true in this comparison mode, it's also false, that "AB"<"A" or "AB">"A".

You can set ANSI or EXACT settings in Foxpro to get the normal comparison behaviour. It may be the case that in the computer language used in your case it makes a difference if you compare < or inverse the result of >=, computer languages are not bound to the rules of math and so the common or mathematical or computer language meaning of the same thing can be different. You might expect from a programmer, that he hides this effect away from the users and does not surface this kind of ill logic. But it's very effective to use it under the hood, if you know what you're doing.

Besides that, it's true that people can be one track minded and you don't get into them boolean algebra for example. That's true.

You may be talking on two different levels here.

Bye, Olaf.

 

[ChrisHunt]

There are some who say that using 'NOT <=' is not the same as using '>' (and that the inverse is also not true).

Let them produce data to prove their assertion, it doesn't sound right to me. I don't think this would work in many SQL engines:

SELECT some_col
FROM   some_table
WHERE  some_val NOT < 99

But these should be equivalent:

SELECT some_col
FROM   some_table
WHERE  some_val >= 99


SELECT some_col
FROM   some_table
WHERE  NOT (some_val < 99)

As Tharg points out, though, clarity is an important factor when writing code. I think the straightforward >= approach is very much clearer, and therefore very much to be preferred.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[ousoonerjoe]

I do enough typing as it is. Why do in 6 chars that can be done in 1 or 2?

--------------------------------------------------
"...and did we give up when the Germans bombed Pearl Harbor? NO!"

"Don't stop him. He's roll'n."
--------------------------------------------------