This should also work:Code: QB64: [Select]
This should also work:Code: QB64: [Select]
I should say (and I think that I'm in agreement with Steve, though I'm not sure of that!):
If variables are numbers (16 & 15) in this case, then always use equations:
as Steve's IF P.MOR <> 0 AND P.MOB <> 0 THEN...
The Boolean algebra is done after the equations are worked out.
Only use Boolean algebra (ie True or False only) when the variables are strictly Booleans (0 or -1 in QB64), eg:
IF P%% AND NOT Q%% THEN...
Then you can't go wrong.
If the main purpose is to make sure that neither value is zero, instead of this :
IF P.MOR <> 0 AND P.MOB <> 0 THEN...
wouldn't this work just as well and be more simple, shorter, and faster if it was in a loop?
IF P.MOR * P.MOB THEN...
Just wondering...
Hi Steve, is line 4 a typo?
IF A <> 0 AND B <> 0 THEN.... <--- Never any issues with this, and it's actually quite readable and easy to understand.
IF A * B THEN.... <--- This might run faster and be shorter code, but there's always the chance that SOMETIME, it's going to overflow. And, I know myself -- when it does, something like this would drive me absolutely insane trying to find it and debug it. Because, after all, it works perfectly well all the rest of the time!
Now, with that caveat said, I'd also like to say, "I don't have a clue what variable TYPE an IF statement actually uses for internal calculations." When we do A * B, is the intermittent result that we compare against 0 an _UNSIGNED _BYTE like the two initial variable types? Is it a LONG? A _FLOAT??
I totally agree, since unsigned variables are possible in QB64.
QB4.5 didn't allow unsigned variables, so it was never an issue back in those days... (I'm just an old style SCREEN 0 type of programmer.)
That is a very good question...
It seems like it could cause occasional "unexpected results" depending on what the answer really is.
Back in QB4.5, I'm pretty sure that all internal functions like VAL(num$) would ALWAYS be interpreted as a SIGNED FLOAT.
QB45 didn't allow overflow, so it was never a possibility. If A * B was greater than the variable limit, you'd get Overflow Error on Line X and the program would terminate.
As for QB64, if My poor memory holds correct, I think our C undercode does a lot of function overloading in math operations. Integers return INT64 values. Floating point numbers return via FLOAT values.
If so, then the main value one would have to watch out for would be the SQR(&HFFFFFFFFFFFFFFFF), or two values that multiplied together equaled that value. (The highest value an INT64 can hold +1.)
Like I mentioned, the vast majority of the time, I think it'd be basically impossible to hit that value and glitch out. The only issue is, as a programmer, my personal experience over the years has taught me that IF there's a chance for something to glitch out, it WILL glitch out eventually.
QB45 didn't allow overflow, so it was never a possibility. If A * B was greater than the variable limit, you'd get Overflow Error on Line X and the program would terminate.Pedant's note: the QuickBasic interpreter will catch overflow. Compiled programs will not catch the error, and will silently wrap values.