Native True constant definition creates inconsistencies (?)

Everything else that doesn't fall into one of the other PB categories.
User avatar
Blue
Addict
Addict
Posts: 973
Joined: Fri Oct 06, 2006 4:41 am
Location: Canada

Native True constant definition creates inconsistencies (?)

Post 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
Last edited by Blue on Mon Aug 31, 2009 10:03 am, edited 2 times in total.
PB Forums : Proof positive that 2 heads (or more...) are better than one :idea:
User avatar
eddy
Addict
Addict
Posts: 1479
Joined: Mon May 26, 2003 3:07 pm
Location: Nantes

Post by eddy »

Code: Select all

; ~ bitwise not operator
debug  Bin(~#True)
Imagewin10 x64 5.72 | IDE | PB plugin | Tools | Sprite | JSON | visual tool
User avatar
blueznl
PureBasic Expert
PureBasic Expert
Posts: 6175
Joined: Sat May 17, 2003 11:31 am
Contact:

Post by blueznl »

This is dangerous:

Code: Select all

vrai = ~faux 
~ 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.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB - upgrade incoming...)
( The path to enlightenment and the PureBasic Survival Guide right here... )
User avatar
eddy
Addict
Addict
Posts: 1479
Joined: Mon May 26, 2003 3:07 pm
Location: Nantes

Post by eddy »

Can we use the NOT keyword to replace the ~ operator ?
Is it supported ?

Code: Select all

a = Not #True
Imagewin10 x64 5.72 | IDE | PB plugin | Tools | Sprite | JSON | visual tool
User avatar
blueznl
PureBasic Expert
PureBasic Expert
Posts: 6175
Joined: Sat May 17, 2003 11:31 am
Contact:

Post by blueznl »

eddy wrote:Can we use the NOT keyword to replace the ~ operator ?
Is it supported ?

Code: Select all

a = Not #True
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
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB - upgrade incoming...)
( The path to enlightenment and the PureBasic Survival Guide right here... )
User avatar
Blue
Addict
Addict
Posts: 973
Joined: Fri Oct 06, 2006 4:41 am
Location: Canada

Post 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

Code: Select all

If valid 
  PleaseDoThis()
endif
which makes the value of #True irrelevant.

Anyway, i can see that it's a rather minor point.
PB Forums : Proof positive that 2 heads (or more...) are better than one :idea:
User avatar
Blue
Addict
Addict
Posts: 973
Joined: Fri Oct 06, 2006 4:41 am
Location: Canada

Post 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,

Code: Select all

Bin(~#False)
differs from

Code: Select all

Bin(~#True)
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.
PB Forums : Proof positive that 2 heads (or more...) are better than one :idea:
Trond
Always Here
Always Here
Posts: 7446
Joined: Mon Sep 22, 2003 6:45 pm
Location: Norway

Post 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.
User avatar
Blue
Addict
Addict
Posts: 973
Joined: Fri Oct 06, 2006 4:41 am
Location: Canada

Post 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.
:shock: 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!
PB Forums : Proof positive that 2 heads (or more...) are better than one :idea:
User avatar
Rescator
Addict
Addict
Posts: 1769
Joined: Sat Feb 19, 2005 5:05 pm
Location: Norway

Post 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? :lol:
Post Reply