Page 1 of 1
Native True constant definition creates inconsistencies (?)
Posted: Mon Aug 31, 2009 8:01 am
by Blue
IF this is a logical bug, it's not specific to any PB version
PureBasic defines
#True as 1 and that
creates inconsistencies
If the value attributed to
True was adequate, we should be able to retrieve the values of True and False when using the built-in boolean functions. But it is not the case.
If you run the following, you can see for yourself :
Code: Select all
; Blue - août 2009
EnableExplicit
;{ ======= macros =====================
Macro QUOTES
"
EndMacro
Macro BugLINE ;; numéro de ligne
RSet(Str(#PB_Compiler_Line),8)+": ( "+ #PB_Compiler_Procedure+" ) " +
EndMacro
Macro BUG (varN)
Debug BugLINE QUOTES varN = QUOTES + Str(varN)
EndMacro
Macro Debugg ;; ligne vide
Debug ""
EndMacro
;}
Procedure Testing(vrai, faux)
Debug " Verifying constant values"
BUG (vrai)
BUG (faux)
Debugg
Debug " Verifying false = not true "
faux = ~vrai
BUG (vrai)
BUG (faux)
Debugg
Debug " Verifying true = not false"
faux = #False ; making sure we use the original PB value
vrai = ~faux
BUG (vrai)
BUG (faux)
EndProcedure
Debugg
Debug "====================================="
Debug "Using native PB True and False values,"
Testing(#True,#False)
Debug "... we get inconsistencies and irregular results"
Debugg
Debugg
Debug "To get consistent and regular results,"
Debug "====================================="
Debug "1. we explicitly define True as -1"
Testing(-1,#False)
Debugg
Debug "====================================="
Debug "2. we define True as Not False"
Testing(~#False,#False)
Debugg
Posted: Mon Aug 31, 2009 8:33 am
by eddy
Code: Select all
; ~ bitwise not operator
debug Bin(~#True)
Posted: Mon Aug 31, 2009 8:43 am
by blueznl
This is dangerous:
~ is not a logical NOT, it's a binary INVERT.
~%00000001 = %11111110
And this, obviously, would invalidate things such as:
Code: Select all
a = 1
If ( ~ a )
Debug "A"
EndIf
If Not a
Debug "B"
EndIf
Debug "C"
Debug ~a
Debug Not a
Frankly, I don't see a problem. I think the definition of true and false in purebasic is not 1 and 0, but <> 0 and 0
Ie. something is false when it is 0, otherwise it's true.
Code: Select all
If 1
Debug "1 is true as it is <> 0"
EndIf
If 5
Debug "5 is true as it is <> 0"
EndIf
If 0
Else
Debug "0 = false is it is = 0"
EndIf
That DOES make a difference. Also remember in PureBasic there is no true boolean type.
Posted: Mon Aug 31, 2009 8:47 am
by eddy
Can we use the NOT keyword to replace the ~ operator ?
Is it supported ?
Posted: Mon Aug 31, 2009 8:55 am
by blueznl
eddy wrote:Can we use the NOT keyword to replace the ~ operator ?
Is it supported ?
Nope, unfortunately Not can only be used in expressions.
Perhaps we should request a Not() function?
Code: Select all
Procedure x_Not(a)
If a = #False
ProcedureReturn #True
Else
ProcedureReturn #False
EndIf
EndProcedure
;
a = 0
a = x_Not(a)
Debug a
Posted: Mon Aug 31, 2009 9:14 am
by Blue
blueznl wrote:[...]I think the definition of true and false in purebasic is not 1 and 0, but <> 0 and 0
Ie. something is false when it is 0, otherwise it's true.
You're right. That is HOW we USE it. But i'm not talking about that.
I'm referring to the PB built-in constant called #True, and its built-in assigned value of 1. I think it should be -1 to make everything consistent.
For everything else, i can only agree with you.
When I code, i DON'T write
Code: Select all
If valid = #True
PleaseDoThis()
endif
but
which makes the value of #True irrelevant.
Anyway, i can see that it's a rather minor point.
Posted: Mon Aug 31, 2009 9:21 am
by Blue
eddy wrote:Code: Select all
; ~ bitwise not operator
debug Bin(~#True)
The shortest answers are the sweetest... You win the prize, today!
But not to quote you, Eddy,
differs from
by a single bit. Shouldn't True be the exact opposite of False, i.e. every bit inversed?
You do get that result if #True is defined as -1.
Posted: Mon Aug 31, 2009 10:21 am
by Trond
#True and #False are not PureBasic constants, they are imported from windows.h. That is why things don't work.
In PureBasic, everything that is 0 or an empty string is false. Everything else is true (includes 1, -1, 123492439, "Hello").
Also, the boolean operators do not return a value. They only set a state which can become the input of another boolean operator or a conditional statement (like while, if, repeat). This state cannot be converted back to a number without a conditional statement. You may think of it as a special boolean type which is incompatible with any other type.
It is most unfortunate that PB doesn't give an error in the case of misuse (assigning a boolean state to a variable), but that's just how it is.
Posted: Mon Aug 31, 2009 10:37 am
by Blue
Thanks, Trond, for these 2 right-on-the-button precisions.
Trond wrote:#True and #False are not PureBasic constants, they are imported from windows.h. That is why things don't work.
That totally removes any point to my argument.
Trond wrote:[...]the boolean operators do not return a value. They only set a state...
AH !!! Now things that seemed strange don't seem so strange anymore...
PS: Is there some way to move a whole discussion to a different section ? >>>> Thanks to whoever did it!
Posted: Sun Sep 06, 2009 11:27 pm
by Rescator
Kinda amusing to see discussions of True and False.
1 and 0 is in my view correct as that translate directly to binary 1 and 0,
-1 is not a binary.
And unless I'm mistaken a -1 applied to a 1bit variable would store it as 0 right? Oops! No wait, it would store it as binary 1 I think. So it kinda makes sense that PB treats 1 and -1 equally in being true.
Anyway, I kinda like how PB does it, sure it's kinda annoying in certain situations, but the majority of the time I (and most here I assume) prefer the simplicity of typing "If x" rather than "If x<>0" or "If (Not x=1) or (Not x=-1)" right?
