in v7.170 the boolean functions are broken for values above 2^31.
When testing with bXOR and trying with different numbers to pinpoint the problem, I found that
2^31 (2147483648) works fine in the below examples, but
2^31+1 onwards (2147483649) gives the different results as shown below. I've tried explicitly declaring all variables as floats (eg. A#, B# etc) but that didn't help.
Any boolean function where parameter 1 is a variable and its value is greater than
2^31 will return the same values each time (ie. bAND (A,B) where A=
2^31+1 gives the same (wrong) result as A=
2^31+2 etc)
If you run the following code, C,D,E and F should all equal 255. D and F show the bug.
A=4294967295
B=255
C=bAND(4294967295,255)
D=bAND(A,B)
E=bAND(A,255)
F=bAND(4294967295,B)
Results
A=4294967295
B=255
C=255
D=0E=255
F=0Similarly, if you change bAND to bOR, bOR is gives incorrect results
C & E =-1
D & F = -2147483393
And bXOR is broken as well
C & E = -256
D & F = -2147483393
If my (extremely bad) C skills are telling me the right thing, I would say that it appears to be (according to glb.h) that the boolean functions are mapping to DGInt which from memory is a 32-bit number, but that doesn't explain why it gives different values for variables as opposed to when you put the same value as a number there.
QuoteFrom glb.h
inline DGNat bAND(DGNat a, DGNat b)
{
unsigned long la = (a== (DGInt)0xffffffff ? 0xffffffff:(unsigned long)a),
lb = (b== (DGInt)0xffffffff ? 0xffffffff:(unsigned long)b);
return (DGNat)(long)(la & lb);
}
bAND is only for 32 bit integers, not floats. Also I think this is signed integer so the range is
−2 147 483 648 to +2 147 483 647
But the problem is also that you get a different result if you put the number in as a number to if you put the same number in as a variable.
I don't have that problem, can you show with an example? (where you don't go over the limit please :-)
It should work on floats - if it didn't the compiler would complain at the typecasting. If the boolean ops are only supposed to be for integers, then there's a different problem (i.e. the compiler is letting you do booleans on floats when it should flag an error). I don't see any reason they shouldn't work on floats though.
The problem only occurs when you use floats and go over the 2^31 number. The issue though is still that you get different results for C and D below which should be exactly the same.
A=4294967295
C=bAND(4294967295,255)
D=bAND(A,255)
The floats are converted to intergers internally (32 bit)
They would explain why values over 2^31 aren't giving the correct results
Quote from: FutureCow on 2009-Nov-11
It should work on floats - if it didn't the compiler would complain at the typecasting. If the boolean ops are only supposed to be for integers, then there's a different problem (i.e. the compiler is letting you do booleans on floats when it should flag an error). I don't see any reason they shouldn't work on floats though.
The problem only occurs when you use floats and go over the 2^31 number. The issue though is still that you get different results for C and D below which should be exactly the same.
A=4294967295
C=bAND(4294967295,255)
D=bAND(A,255)
Is this what you mean? It works just fine for me. The number gets converted into a signed integer 32 bit.
LOCAL a%, c%, d%
a=4294967295
c=bAND(4294967295,255)
d=bAND(a,255)
DEBUG "a:"+a+"\n"
DEBUG "c:"+c+"\n"
DEBUG "d:"+d+"\n"
LOCAL a2, c2, d2
a2=4294967295
c2=bAND(4294967295,255)
d2=bAND(a,255)
DEBUG "a2:"+a2+"\n"
DEBUG "c2:"+c2+"\n"
DEBUG "d2:"+d2+"\n"
Output:a:-1
c:255
d:255
a2:4294967295
c2:255
d2:255
If I run Moru's code, I get correct results, so I've done some more tests.
Can someone please confirm my findings? The problem occurrs in one of two scenarios
1) if you do not declare your variables and let the compiler create them
2) You create the large number as an int
Looking at both of these scenario's
1) Letting the compiler create your variables
a=4294967295
b=255
c=bAND(4294967295,255)
d=bAND(a,255)
DEBUG "a:"+a+"\n"
DEBUG "b:"+b+"\n"
DEBUG "c:"+c+"\n"
DEBUG "d:"+d+"\n"
Results
a:4294967295
b:255
c:255
d:0
Scenario 2, declaring the variables, but declaring the large number as an int
LOCAL a#, b%, c%, d% // Or LOCAL a#, b#, c#, d# - it gives the same results
a=4294967295
b=255
c=bAND(4294967295,255)
d=bAND(a,255)
DEBUG "a:"+a+"\n"
DEBUG "b:"+b+"\n"
DEBUG "c:"+c+"\n"
DEBUG "d:"+d+"\n"
Results
a:4294967295
b:255
c:255
d:0
Now I'm probably missing something obvious, but even if the compiler is converting to signed 32 bit ints I can't see why it should break. If you pass the large 32 bit number as a value, i.e.
c=bAND(4294967295,255)
The 4294967295 should be converted to a signed int the same was as the "a" value if you pass the same value in a variable.
d=bAND(a,255)
Either way the value (429...) should end up as the same signed int value and hence the same calculation should performed.
Shouldn't it?
4294967295 is too big to be converted to int32. It trims to 1/2 of it (0x8000000). If you want such large numbers, type them in hex.
How do you type numbers in hex? I can't find anything about it in the docs.
What does GLBasic do with hex numbers? Does it use 64bit ints or similar to get larger numbers? If GLBasic doesn't leave them stored internally as hex I think I'll run into problems again with numbers greater than 0x80000000 and boolean operations (needed for a CRC32 creation routine).
internally, yes. But if you type it in the editor, everything > 0x8000000 must be entered in hex (or signed , thus negative). 0xffffffff = -1 e.g.
Thanks, I'll give it a try and see if it works tommorrow.
Hex numbers are preceded with 0x. It is mentioned in the manual... :P
Damn! Any idea where? :-[
In the help section 'Advanced' at the bottom, use search in the CHM file it says:
Hexadecimal Numbers
Hexadecimal numbers can also be used in addition to decimal numbers by prefixing it with '0x'.
Cheers,
Freshworks
Awesome - cheers!
I didn't even think of using search (I'm going to blame that on my two kids waking me up pretty much ever hour last night).
Its in Tutorials -> Advanced
Tutorials or Advanced. Maybe :D
Not sure if its a bug or a feature but you can seem to, at least declare large numbers.
"global bigfloat as double" for example, seems to compile OK... untested past that though.