Just like IMP, this is one of those keywords that does binary comparisons on values, that you never see anyone using.
WHY?
Because everyone seems to be under a misconception about what EQV actually does!
From our wiki page -- EQV - QB64 Phoenix Edition Wiki -- we learn that this does bitwise comparisons. When both bits are the same (both are 0, or both are 1), then EQV reports that it's TRUE, they're equivalent to each other. If the two bits are different, EQV reports to us that it's FALSE, and they're not equivalent to each other.
Most people see that, or read that, and think, "Hey! That's simple enough. If they're the same, it's true. If they're different, it's false. This is just like equals!"
BZZZZZTTTTZZZ!! That's completely WRONG!
And let me tell you why:
0 EQV 0 = 1
1 EQV 1 = 1
0 EQV 1 = 0
1 EQV 0 = 0
^ Those are the basic rules of evaluating our bits. Now, let's apply it to two real world numbers!
4 = &B00000100
2 = &B00000010
EQV ----------
&B11111001
All those 0's that compare to 0's become 1. All the 1's that compare to 1's become 1. When a 0 compares to a 1, the result is 0. <<-- All just like the rules for EQV tell us.
Now, is 2 EQUAL TO 4?? (2 = 4)??
Of course not!!
But is 2 EQV 4??
Absolutely! It's 249! (Just count and add the bits in the result above... 11111001 = 249.)
Remember, in BASIC, *ONLY* zero is FALSE. Anything else is TRUE.
2 is not equal to 4, but it *is* EQV to 4.
Now, I know what some of you guys are going to say, after you think on this for a bit: "Then in BASIC, EQV is just about useless as all mixed numbers are going to give TRUE results."
1 EQV 0 = TRUE
1 EQV 1 = TRUE
1 EQV 2 = TRUE
1 EQV 3 = TRUE
Try it for yourself:
11 non-zero numbers on the screen.. 11 TRUE values! They're *ALL* True!!
"Now hold on one moment there, Stevey-boy!" (I'm channeling my inner Pete here, as I can hear him already.) "Just how the hell did 1 and 0 end up being TRUE? By our definition from the wiki, they have to be FALSE!! Somethings fishy here, and it isn't the tuna I had for supper last night!"
BZZZZZZZZTTTZZZZ!! Sorry, Imaginary @Pete. The result is exactly what you'd expect to see, if you think about it for just a moment.
What is 1? What is 0??
1 = &B00000001
0 = &B00000000
Now, that 0 and 1 might EQV out to become 0, but what happens to all those 0's and 0's when they're compared against each other??
11111110.
1 AND 0 = 254 (as unsigned bytes). It's definitely true!
"Then how the hell do you ever generate a FALSE with EQV? That's impossible, for tarnation's sake!"
BZZZZZZZZTTTZZZZ!! Sorry again, Imaginary @Pete.
You get FALSE back, if -- and only if -- EVERY bit is the opposite of the other!
&B10101010
&B01010101
EQV========
&B00000000
&B11111111
&B00000000
EQV========
&B00000000
&B00000001
&B11111110
EQV========
&B00000000
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.
So 1 EQV 254 is FALSE. 0 EQV 255 is FALSE. 127 EQV 128 is FALSE.
.
.
.
"Ha! Ha! You're a goober! That's wrong! I just tried it! Nanner! Nanner!"
Shut up, Imaginary @Pete!
It's only wrong because you didn't pay attention to what I just stressed in bold, italic, underline above!
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.
What variable type did you use, when you tested those values for 1 EQV 254? 0 EQV 255?
"Umm... Whatever QB64-PE defaults to. I just typed them in as numbers!"
Then let me ask.. What is 254 as an INTEGER value? What is 1 as an INTEGER value??
254 = &B0000000011111110
1 = &B0000000000000001
See the problem already? There's a whole bunch of leading 0's which match for both values!
It's only when one is dealing with BYTE values, that 1 EQV 254 is FALSE. If they're a different variable type, they're both padded with zeros which are going to match up, and 0 EQV 0 = 1...
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.
I can't stress the above enough. EQV is not a form of equal. It's a bitwise comparison, and...
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.
WHY?
Because everyone seems to be under a misconception about what EQV actually does!
From our wiki page -- EQV - QB64 Phoenix Edition Wiki -- we learn that this does bitwise comparisons. When both bits are the same (both are 0, or both are 1), then EQV reports that it's TRUE, they're equivalent to each other. If the two bits are different, EQV reports to us that it's FALSE, and they're not equivalent to each other.
Most people see that, or read that, and think, "Hey! That's simple enough. If they're the same, it's true. If they're different, it's false. This is just like equals!"
BZZZZZTTTTZZZ!! That's completely WRONG!
And let me tell you why:
0 EQV 0 = 1
1 EQV 1 = 1
0 EQV 1 = 0
1 EQV 0 = 0
^ Those are the basic rules of evaluating our bits. Now, let's apply it to two real world numbers!
4 = &B00000100
2 = &B00000010
EQV ----------
&B11111001
All those 0's that compare to 0's become 1. All the 1's that compare to 1's become 1. When a 0 compares to a 1, the result is 0. <<-- All just like the rules for EQV tell us.
Now, is 2 EQUAL TO 4?? (2 = 4)??
Of course not!!
But is 2 EQV 4??
Absolutely! It's 249! (Just count and add the bits in the result above... 11111001 = 249.)
Remember, in BASIC, *ONLY* zero is FALSE. Anything else is TRUE.
2 is not equal to 4, but it *is* EQV to 4.
Now, I know what some of you guys are going to say, after you think on this for a bit: "Then in BASIC, EQV is just about useless as all mixed numbers are going to give TRUE results."
1 EQV 0 = TRUE
1 EQV 1 = TRUE
1 EQV 2 = TRUE
1 EQV 3 = TRUE
Try it for yourself:
Code: (Select All)
Dim As _Unsigned _Byte a, b, c
a = 1
For i = 0 To 10
b = i
c = a Eqv b
Print c
Next11 non-zero numbers on the screen.. 11 TRUE values! They're *ALL* True!!
"Now hold on one moment there, Stevey-boy!" (I'm channeling my inner Pete here, as I can hear him already.) "Just how the hell did 1 and 0 end up being TRUE? By our definition from the wiki, they have to be FALSE!! Somethings fishy here, and it isn't the tuna I had for supper last night!"
BZZZZZZZZTTTZZZZ!! Sorry, Imaginary @Pete. The result is exactly what you'd expect to see, if you think about it for just a moment.
What is 1? What is 0??
1 = &B00000001
0 = &B00000000
Now, that 0 and 1 might EQV out to become 0, but what happens to all those 0's and 0's when they're compared against each other??
11111110.
1 AND 0 = 254 (as unsigned bytes). It's definitely true!
"Then how the hell do you ever generate a FALSE with EQV? That's impossible, for tarnation's sake!"
BZZZZZZZZTTTZZZZ!! Sorry again, Imaginary @Pete.
You get FALSE back, if -- and only if -- EVERY bit is the opposite of the other!
&B10101010
&B01010101
EQV========
&B00000000
&B11111111
&B00000000
EQV========
&B00000000
&B00000001
&B11111110
EQV========
&B00000000
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.
So 1 EQV 254 is FALSE. 0 EQV 255 is FALSE. 127 EQV 128 is FALSE.
.
.
.
"Ha! Ha! You're a goober! That's wrong! I just tried it! Nanner! Nanner!"
Shut up, Imaginary @Pete!
It's only wrong because you didn't pay attention to what I just stressed in bold, italic, underline above!
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.
What variable type did you use, when you tested those values for 1 EQV 254? 0 EQV 255?
"Umm... Whatever QB64-PE defaults to. I just typed them in as numbers!"
Then let me ask.. What is 254 as an INTEGER value? What is 1 as an INTEGER value??
254 = &B0000000011111110
1 = &B0000000000000001
See the problem already? There's a whole bunch of leading 0's which match for both values!
It's only when one is dealing with BYTE values, that 1 EQV 254 is FALSE. If they're a different variable type, they're both padded with zeros which are going to match up, and 0 EQV 0 = 1...
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.
I can't stress the above enough. EQV is not a form of equal. It's a bitwise comparison, and...
When EVERY bit is the opposite of the other, the result is FALSE. Otherwise it's TRUE.