Talk:Boolean constants - Revision history

Sunjammer at 18:18, 28 October 2009

2009-10-28T18:18:32Z

Axe Murderer: small dispute with revisions made

2009-10-28T10:11:46Z

small dispute with revisions made

BryanDerksen: At the moment this is the only place that covers the usage of these constants, however, so IMO deletion is inappropriate. Content can be cross-linked and merged later once there are better places.

2009-10-26T19:20:10Z

At the moment this is the only place that covers the usage of these constants, however, so IMO deletion is inappropriate. Content can be cross-linked and merged later once there are better places.

Sunjammer at 18:40, 26 October 2009

2009-10-26T18:40:52Z

BryanDerksen: seems pertinant to me, though it did need some condensing IMO.

2009-10-26T15:47:36Z

seems pertinant to me, though it did need some condensing IMO.

Sunjammer: information moved from article as not relevant to the page it was on

2009-10-25T00:17:39Z

information moved from article as not relevant to the page it was on

New page

If you test for a variable's truth value by testing if it is equal to TRUE you may not get the correct result since TRUE == x is a true expression only when x is 1, yet all non-zero values are also not FALSE; FALSE != x is true when x is not zero. There is an ambiguity whenever x is not 1 even though all non-zero values are treated logically as true. When x is 2, for instance, both TRUE == x and FALSE == x are false statements, leading one to conclude that x is neither TRUE nor FALSE when its value is 2 (or any other value besides 0 and 1). But this code snippet
<pre>
int b_X_is_True = FALSE;
if( x ) b_X_is_True = TRUE;
</pre>
will set the variable b_X_is_True to TRUE whenever the value of x is not zero. Clearly when x is 2 the language treats x as a true value logically.

The problem is that the identifier TRUE must be given a value, and that value must represent all non-zero values to be accurate. But a single value cannot represent many different values so there is ambiguity everywhere except at the value the constant is actually assigned. FALSE on the other hand, also needs to be given a value, but it only has to represent one integer value...zero, because that is the only integer value treated logically as false. Any integer value tested against FALSE will be unambiguously resolved. Because of this ambiguity with the TRUE identifier, and the correspondingly unambiguous nature of the FALSE identifier, you may wish to instead test if your variable is not equal to FALSE rather than testing its equivalence to TRUE.

Note also that it is never necessary, and furthermore wasteful, to explicitly "test for TRUE" or "test for NOT FALSE" in a boolean expression anyway. One would never write, for example:
<pre>
if( (x == y) == TRUE ) ... <-- redundant comparison with TRUE
if( (x == y) != FALSE ) ... <-- redundant comparison with FALSE
</pre>
because the sub-expression (x == y) will evaluate to TRUE or FALSE already. Additionally comparing the result to TRUE (or NOT FALSE) gives the exact same result for the entire expression as leaving the extraneous comparison out completely does. Thus the comparison with TRUE (or NOT FALSE) is redundant, unnecessary and a wasteful computation.

The same logic applies to expressions involving function calls. If a function returns a TRUE/FALSE value, it would be a redundant waste of CPU cycles to test if the returned value was TRUE.
<pre>
if( IsObjectValid( oObject) != FALSE) ... <-- this is redundant as well
if( IsObjectValid( oObject) == TRUE) ... <-- as is this, also it's ambiguous
if( IsObjectValid( oObject) ) ... <-- same thing, one less comparison
</pre>
In this case the return value of the function (TRUE/FALSE) has the same logic characteristics as the sub-expression (x == y) in the example above. So you can treat the function call as a boolean sub-expression just like (x == y) and therefore the same logic leads to the same conclusion concerning the overall expression.

In contrast, testing for FALSE or for NOT TRUE is perfectly acceptable:
<pre>
if( IsObjectValid( oObject) == FALSE) ... <-- this is not redundant
if( IsObjectValid( oObject) != TRUE) ... <-- not redundant either but is ambiguous
if( !IsObjectValid( oObject) ) ... <-- but this might be the best method
</pre>

The identifier TRUE is only really useful for defining default values of boolean type parameters in a function definition, passing a true value to a function with a boolean parameter when you call it, or setting the value of a boolean type variable. There is no other place where you need it.
<pre>
void Dance( int bChaCha = TRUE)... <-- default value in function def
SetItemDroppable( oItem, TRUE); <-- boolean parameter in function call
int bStillLooking = TRUE; <-- set a variable value
</pre>

Some will probably take the position that having the extra comparison in there makes the code more readable and obvious. It would be difficult to argue that point especially in some more complex expression situations. But it is functionally unnecessary and adding it does waste CPU cycles in exchange for that marginal increase in readability. Learning to read expressions without it having to be there would benefit anybody.

← Older revision		Revision as of 18:18, 28 October 2009
Line 9:		Line 9:
	::When it's covered elsewhere then by all means there should be cross-links between the various places that discuss it and consolidation of similar content. But at the moment this is the only place where boolean usage in scripting is covered in detail so IMO it's inappropriate to simply delete the contents without having a new home for them. Problems with the example section should also be dealt with by rewriting - if there are situations where testing against TRUE is appropriate they should be described as well. Generally speaking a wiki entry shouldn't be deleted if it's just imperfect. [[User:BryanDerksen\|BryanDerksen]] 19:20, 26 October 2009 (UTC)		::When it's covered elsewhere then by all means there should be cross-links between the various places that discuss it and consolidation of similar content. But at the moment this is the only place where boolean usage in scripting is covered in detail so IMO it's inappropriate to simply delete the contents without having a new home for them. Problems with the example section should also be dealt with by rewriting - if there are situations where testing against TRUE is appropriate they should be described as well. Generally speaking a wiki entry shouldn't be deleted if it's just imperfect. [[User:BryanDerksen\|BryanDerksen]] 19:20, 26 October 2009 (UTC)
	:::The last paragraph now states "TRUE and FALSE are only useful..." which is not correct. There are multitudes of other situations where FALSE is appropriate since it is not ambiguous. It is only the TRUE identifier which, due to its ambiguity, is useful in only those few situations identified. I don't think those should be lumped together like that. [[User:Axe Murderer\|Axe Murderer]] 10:11, 28 October 2009 (UTC)		:::The last paragraph now states "TRUE and FALSE are only useful..." which is not correct. There are multitudes of other situations where FALSE is appropriate since it is not ambiguous. It is only the TRUE identifier which, due to its ambiguity, is useful in only those few situations identified. I don't think those should be lumped together like that. [[User:Axe Murderer\|Axe Murderer]] 10:11, 28 October 2009 (UTC)
		+	:::: Can I suggest that we leave this page alone for a while? The '''Example''' section is both inaccurate and irrelevant to this page. There is no point wasting any more time on it until it can be removed to a more appropriate part of the scripting framework. Incidentally '''TRUE '''isn't ambiguous: '''true''' is.
		+	::::--[[User:Sunjammer\|Sunjammer]] 18:18, 28 October 2009 (UTC)

← Older revision		Revision as of 10:11, 28 October 2009
Line 8:		Line 8:

	::When it's covered elsewhere then by all means there should be cross-links between the various places that discuss it and consolidation of similar content. But at the moment this is the only place where boolean usage in scripting is covered in detail so IMO it's inappropriate to simply delete the contents without having a new home for them. Problems with the example section should also be dealt with by rewriting - if there are situations where testing against TRUE is appropriate they should be described as well. Generally speaking a wiki entry shouldn't be deleted if it's just imperfect. [[User:BryanDerksen\|BryanDerksen]] 19:20, 26 October 2009 (UTC)		::When it's covered elsewhere then by all means there should be cross-links between the various places that discuss it and consolidation of similar content. But at the moment this is the only place where boolean usage in scripting is covered in detail so IMO it's inappropriate to simply delete the contents without having a new home for them. Problems with the example section should also be dealt with by rewriting - if there are situations where testing against TRUE is appropriate they should be described as well. Generally speaking a wiki entry shouldn't be deleted if it's just imperfect. [[User:BryanDerksen\|BryanDerksen]] 19:20, 26 October 2009 (UTC)
		+	:::The last paragraph now states "TRUE and FALSE are only useful..." which is not correct. There are multitudes of other situations where FALSE is appropriate since it is not ambiguous. It is only the TRUE identifier which, due to its ambiguity, is useful in only those few situations identified. I don't think those should be lumped together like that. [[User:Axe Murderer\|Axe Murderer]] 10:11, 28 October 2009 (UTC)

← Older revision		Revision as of 19:20, 26 October 2009
Line 6:		Line 6:
	: The '''Example''' section should be removed or completely rewritten to provide more appropriate advice (though as stated above this would be better in the section on boolean expressions).		: The '''Example''' section should be removed or completely rewritten to provide more appropriate advice (though as stated above this would be better in the section on boolean expressions).
	: --[[User:Sunjammer\|Sunjammer]] 18:40, 26 October 2009 (UTC)		: --[[User:Sunjammer\|Sunjammer]] 18:40, 26 October 2009 (UTC)
		+
		+	::When it's covered elsewhere then by all means there should be cross-links between the various places that discuss it and consolidation of similar content. But at the moment this is the only place where boolean usage in scripting is covered in detail so IMO it's inappropriate to simply delete the contents without having a new home for them. Problems with the example section should also be dealt with by rewriting - if there are situations where testing against TRUE is appropriate they should be described as well. Generally speaking a wiki entry shouldn't be deleted if it's just imperfect. [[User:BryanDerksen\|BryanDerksen]] 19:20, 26 October 2009 (UTC)

← Older revision		Revision as of 18:40, 26 October 2009
Line 2:		Line 2:

	Actually, though it is indeed perhaps a bit wordy and redundant at times, this information does seem quite pertinent to this page. It's the sort of thing that a scripter should be aware of when working with boolean constants in scripts, and since dascript doesn't have an explicit boolean type this seems like the best place for it to me. I'm going to reinstitute it and do some rewriting to make it less of a big block. [[User:BryanDerksen\|BryanDerksen]] 15:47, 26 October 2009 (UTC)		Actually, though it is indeed perhaps a bit wordy and redundant at times, this information does seem quite pertinent to this page. It's the sort of thing that a scripter should be aware of when working with boolean constants in scripts, and since dascript doesn't have an explicit boolean type this seems like the best place for it to me. I'm going to reinstitute it and do some rewriting to make it less of a big block. [[User:BryanDerksen\|BryanDerksen]] 15:47, 26 October 2009 (UTC)
		+	: However '''dascript''' does have boolean logic and that will be covered in the language definition (under the expressions section in my outline).
		+	: Moreover the '''Example''' section is highly subjective and in my opinion incorrect. There are quite obviously occasions when testing against <code>TRUE</code> is appropriate: <code>MyFunctionThatReturns2()</code> will equate to '''true''' but <code>MyFunctionThatReturns2() == TRUE</code> will equate to '''false''' so depending on your requirements one of these is an error. In addition an explicit comparison against TRUE or FALSE may clarify your logic and intent which is invariably worth an extra byte code instruction or two. Consquently the phrases "never necessary" and "only really useful" are at the very least misleading.
		+	: The '''Example''' section should be removed or completely rewritten to provide more appropriate advice (though as stated above this would be better in the section on boolean expressions).
		+	: --[[User:Sunjammer\|Sunjammer]] 18:40, 26 October 2009 (UTC)

@@ Line 1: / Line 1: @@
-If you test for a variable's truth value by testing if it is equal to TRUE you may not get the correct result since TRUE == x is a true expression only when x is 1, yet all non-zero values are also not FALSE; FALSE != x is true when x is not zero. There is an ambiguity whenever x is not 1 even though all non-zero values are treated logically as true. When x is 2, for instance, both TRUE == x and FALSE == x are false statements, leading one to conclude that x is neither TRUE nor FALSE when its value is 2 (or any other value besides 0 and 1). But this code snippet
+<snip pasted AxeMurderer content- see [http://social.bioware.com/wiki/datoolset/index.php?title=Talk:Boolean_constants&oldid=7093 this revision] for it>
-<pre>
-int b_X_is_True = FALSE;
-if( x ) b_X_is_True = TRUE;
-</pre>
-will set the variable b_X_is_True to TRUE whenever the value of x is not zero. Clearly when x is 2 the language treats x as a true value logically.
-The problem is that the identifier TRUE must be given a value, and that value must represent all non-zero values to be accurate. But a single value cannot represent many different values so there is ambiguity everywhere except at the value the constant is actually assigned. FALSE on the other hand, also needs to be given a value, but it only has to represent one integer value...zero, because that is the only integer value treated logically as false. Any integer value tested against FALSE will be unambiguously resolved. Because of this ambiguity with the TRUE identifier, and the correspondingly unambiguous nature of the FALSE identifier, you may wish to instead test if your variable is not equal to FALSE rather than testing its equivalence to TRUE.
+Actually, though it is indeed perhaps a bit wordy and redundant at times, this information does seem quite pertinent to this page. It's the sort of thing that a scripter should be aware of when working with boolean constants in scripts, and since dascript doesn't have an explicit boolean type this seems like the best place for it to me. I'm going to reinstitute it and do some rewriting to make it less of a big block. [[User:BryanDerksen|BryanDerksen]] 15:47, 26 October 2009 (UTC)
-−
-Note also that it is never necessary, and furthermore wasteful, to explicitly "test for TRUE" or "test for NOT FALSE" in a boolean expression anyway. One would never write, for example:
-<pre>
-if( (x == y) == TRUE ) ...  <-- redundant comparison with TRUE
-if( (x == y) != FALSE ) ...  <-- redundant comparison with FALSE
-</pre>
-because the sub-expression (x == y) will evaluate to TRUE or FALSE already. Additionally comparing the result to TRUE (or NOT FALSE) gives the exact same result for the entire expression as leaving the extraneous comparison out completely does. Thus the comparison with TRUE (or NOT FALSE) is redundant, unnecessary and a wasteful computation.
-−
-The same logic applies to expressions involving function calls. If a function returns a TRUE/FALSE value, it would be a redundant waste of CPU cycles to test if the returned value was TRUE.
-<pre>
-if( IsObjectValid( oObject) != FALSE) ... <-- this is redundant as well
-if( IsObjectValid( oObject) == TRUE) ... <-- as is this, also it's ambiguous
-if( IsObjectValid( oObject) ) ... <-- same thing, one less comparison
-</pre>
-In this case the return value of the function (TRUE/FALSE) has the same logic characteristics as the sub-expression (x == y) in the example above. So you can treat the function call as a boolean sub-expression just like (x == y) and therefore the same logic leads to the same conclusion concerning the overall expression.
-−
-In contrast, testing for FALSE or for NOT TRUE is perfectly acceptable:
-<pre>
-if( IsObjectValid( oObject) == FALSE) ... <-- this is not redundant
-if( IsObjectValid( oObject) != TRUE) ... <-- not redundant either but is ambiguous
-if( !IsObjectValid( oObject) ) ... <-- but this might be the best method
-</pre>
-−
-The identifier TRUE is only really useful for defining default values of boolean type parameters in a function definition, passing a true value to a function with a boolean parameter when you call it, or setting the value of a boolean type variable. There is no other place where you need it.
-<pre>
-void Dance( int bChaCha = TRUE)... <-- default value in function def
-SetItemDroppable( oItem, TRUE); <-- boolean parameter in function call
-int bStillLooking = TRUE; <-- set a variable value
-</pre>
-−
-Some will probably take the position that having the extra comparison in there makes the code more readable and obvious. It would be difficult to argue that point especially in some more complex expression situations. But it is functionally unnecessary and adding it does waste CPU cycles in exchange for that marginal increase in readability. Learning to read expressions without it having to be there would benefit anybody.