Boolean Range

  • Thread starter Thread starter Matt MacDonald
  • Start date Start date
M

Matt MacDonald

Hi everyone,
Maybe I'm just discovering something late that everyone else knew already,
but it caught me off guard. In the past I could do an expression like "If 1
<= x <= 10 Then ..." to see if x was in the numeric range 1-10. So x = 5
would evaluate to True, whereas x = 0 would evaluate to False. Well now it
seems that no matter what x is, the statement evaluates to True. I can't
find anything concrete to support my theory, but my guess is that the order
of operations is the problem here. For example.

Rather than the compiler (or whatever) evaluating the above expression as
"(1 <= x) AND (x <= 10) it's evaluating it as "(1 <= x) <= 10". So if x is
5 then the first operation (in the parenthesis) will evaluate to True (or -1
converted to an integer) and if x is 0 then the first operation will
evaluate to False (or 0 converted to an integer). Either way, once the
second expression is evaluated, you will always get True, sinse "-1 <= 10"
and "0 <= 10" both equate to True.

Anyway, sorry for the long winded example, but is my theory correct? If so,
then I would assume that the best way to achieve what I need is "If 1 <= x
AndAlso x <=10". To be honest this situation doesn't come up that often
for me, so it could be that the last time it came up I was using a language
with different syntax rules like C# or C++.

Thanks,
Matt
 
Matt MacDonald said:
Hi everyone,
Maybe I'm just discovering something late that everyone else knew
already, but it caught me off guard. In the past I could do an
expression like "If 1 <= x <= 10 Then ..." to see if x was in the
numeric range 1-10. So x = 5 would evaluate to True, whereas x = 0
would evaluate to False.
Click to expand...

Can't repro this in VB6. Expression returns True in both cases.
Well now it seems that no matter what x
is, the statement evaluates to True.
Click to expand...

One more reason why Option Strict should be switched On. The syntax is
not valid in VB.Net because "1 <= x" is a Boolean which is not defined
in conjunction with "<= 10". A Boolean can not be compared to an Integer
value using the "<=" operator.

VB6 did implicit conversions - wanted or not, without giving a warning
or an error. Option Strict makes you think about what has to happen.


AZ
 
Armin Zingler said:
Can't repro this in VB6. Expression returns True in both cases.


One more reason why Option Strict should be switched On. The syntax is
not valid in VB.Net because "1 <= x" is a Boolean which is not defined
in conjunction with "<= 10". A Boolean can not be compared to an Integer
value using the "<=" operator.

VB6 did implicit conversions - wanted or not, without giving a warning
or an error. Option Strict makes you think about what has to happen.


AZ
Click to expand...

Amen! I hope that someday Option Strict will be the default and unavoidable.
IMHO, code quality would improve measurably.
 
Peter,
Amen! I hope that someday Option Strict will be the default and
unavoidable. IMHO, code quality would improve measurably.
Click to expand...

I changed my mind a while ago about this. Somebody stated the point bellow
and I agree.

As Armin, You and I have seldom a problem with casting, can option strict
off be a good start point for somebody just starts learning programming,
programming is in my idea learning to use logic, not learning to know from
head every name of a property or/and method that there can be.

I know that my knowledge about teaching is most probably very low against
yours.
But I found it a good point.

Cor
 
I'm pretty sure that

If 1 <= x <= 10 Then...

Has never been valid Microsoft BASIC syntax. If it ever worked it would not
have given the correct value because at best the (1 <= x) would return -1
(True) which would always be less than 10, so any value greater or equal to 1
would return True.

SELECT CASE x
CASE 1 TO 10
CASE ELSE
END SELECT

would give you what you want, or you could use
IF 1 <= X AND X <= 10 THEN...



--
David Streeter
Synchrotech Software
Sydney Australia
 
The more I think about this, it must have been back in my C++ (or maybe
earlier) days that I used this syntax. Like I said, it very seldom comes up
for me.

Thanks for all the input,
Matt
 
Back
Top