IF THEN issue using AND, I think I'm losing my mind!

[Dimster]

Hi Steve, is line 4 a typo?

[SMcNeill]

Hi Steve, is line 4 a typo?

Aye.  Should've been an __OR there, though it doesn't change the results any this time around.  ;)

[Dimster]

At first I was thinking it was not a typo but rather a demonstration of how an "OR" would behave in an "AND" function, effectively creating an "XOR".

[Stuart]

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!

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

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??

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.

[SMcNeill]

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.

And glitches like this -- that work hundreds or thousands of times with absolutely no problems whatsoever-- are the ones that are almost impossible to find.  Your brain KNOWS it should work.  Your eyes glaze over and instally rule out a simple A * B as the possible culprit.  You go MAD just looking over the same 500,000 line program over and over and over -- and it's ALWAYS the ridiculously long and complex programs that generate these rare glitches -- until you feel like giving up coding and going back to farming...

So the best solution I've found to prevent these future headaches, for myself, is to just not fall into them to begin with.  ;)

[OldMoses]

It explains a lot of what I've noticed in working with QB64 as compared to 4.5. It will handle astonishingly large computations on the fly, and you only have to make sure if you're storing any big numbers, that you use an appropriate variable type.

...and, yes, I've hit the limit a time or two. ;)  When you got it, you can't help but play with it...

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.

[luke]

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.

[johannhowitzer]

What I do is put

const true = -1
const false = 0

at the top of every program I write.  And I've always been in the habit of writing if n <> false, instead of just if n.  So I would write

if n <> false and p <> false then

This has saved me countless headaches.