This was raised in the office today. With the various types of computing, various languages and various boolean types. Is the following always true
true == !false;
While there should be no language where your expression can directly be false, there are quite a number of languages where the related expression
someTrueValue == !false
does not hold true. C and its variants, for instance. And Lisp variants, to name just a few. In these languages, there is one false value (zero or nil), everything else is considered true. So, !false will yield one of these true values, which can be different from someTrueValue.
Assuming true and false are reserved keywords representing boolean values, it should always be true.
If the language happens to not reserve those keywords (ie: older versions of Python), you could always declare a variable with those names such that true == !false is false.
In addition to true and false being variables, ! has different meanings in many languages. Though I don't know any language which uses == for something other than (some sort of) equality, it could be user-defined.
Yes. It is because !false equals true, and true always equals true.
If there was ever a language where (true == !false)==false then the language would be inconsistent with Boolean logic ('inconsistent' is being used here both informally and in a formal sense within Boolean logic) and the result of this would be that it would be possible to derive inconsistent logical assertions (such as true == false, or false == true).
The final result of this would be that there would be no trustworthy logical framework underpinning any of the use of conditionals within the language rendering it useless.
Related
I would like to evaluate my ruta script using the annotation test environment provided by the uima ruta plugin for eclipse. I've built a manually-annotated corpus. Some annotations are evaluated as true postives as well as false positives, which should not be possible per definition.
I have already checked, if there are minor differences between the true positives and false positives, but they are in fact identical (same offsets).
As an option I chose "partial match".
When I check the results.xmi, where I can see the true positives, false positives, and false negatives as annotations, the annotations in question have an error-feature; but there is no further information.
True Postives and False Positives as Annotations in the result.xmi
The annotations in question should actually be true positives.
Edit: I also noticed that when I specify only one type (i.e. one type of annotation) to be evaluated, everything is like it should be. The problem occurs only when more than one type is supposed to be evaluated.
This question already has answers here:
Testing for nil in Objective-C -- if(x != nil) vs if(x)
(4 answers)
Closed 9 years ago.
If you have an object like NSString *someString, what is the difference, if any, between
if (!someString)
vs
if (someString == nil)
Thanks!
The first syntax you use:
if (!someString)
exploits a sort of "ambiguity" of C deriving from the fact that the original standard of C lacked a proper boolean type. Therefore, any integer value equalling 0 was interpreted as "false", and any integer value different from "0" was taken as "true". The meaning of ! is therefore defined based on this convention and current versions of the C standard have kept the original definition for compatibility.
In your specific case, someString is a pointer, so it is first converted to an integer, then ! someString is interpreted as a bool value of true when someString points at the location 0x000000, otherwise it evals to "true".
This is fine in most conditions (I would say always), but in theory, NULL/nil could be different from 0x000000 under certain compilers, so (in very theory) it would be better to use the second syntax, which is more explicit:
if (someString == nil)
It is anyway more readable and since someString is not an integer (rather a pointer), IMO, better practice in general.
EDIT: about the definition of NULL...
Whether the C standard defines NULL to be 0 is an interesting topic for me...
According to C99 standard, section 7.17, "Common definitions ":
NULL [which] expands to an implementation-defined null pointer constant;
So, NULL is defined in stddef.h to an implementation-defined null pointer constant...
The same document on page 47 states:
An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
So, the null pointer constant (which is (void*)0) can be converted to a null pointer and this is guaranteed to compare unequal to a pointer to any object or function.
So, I think that basically it depends on whether the implementation decides that the result of converting a null pointer constant to a null pointer produces a pointer which converted back to an integer gives 0. It is not clear that a null pointer interpreted as an integer equals 0.
I would say that the standard really try and enforce the null pointer being 0, but leaves the door open to systems where the null pointer was not 0.
For most pointers, they're equivalent, though most coders I know prefer the former as it's more concise.
For weakly linked symbols, the former resolves the symbol (and will cause a crash if it's missing) while an explicit comparison against nil or NULL will not.
The bang, exclamation, ! prefix operator in C is a logical not. At least, its a version of it. If you looked at a typical logical not truth table you would see something like this:
Input Result
1 0
0 1
However in C the logical not operator does something more like this:
Input Result
non-zero 0
0 1
So when you consider that both NULL and nil in Objective-C evaluate to 0, you know that the logical not operator applied to them will result in a 1.
Now, consider the equality == operator. It compares the value of two items and returns 1 if they are equal, 0 if they are not. If you mapped its results to a truth table then it would look exactly like the results for logical not.
In C and Objective-C programs, conditionality is actually determined by int's, as opposed to real booleans. This is because there is no such thing as a boolean data type in C. So writing something like this works perfectly fine in C:
if(5) printf("hello\n"); // prints hello
and in addition
if(2029) printf("hello\n"); // also prints hello
Basically, any non-zero int will evaluate as 'true' in C. You combine that with the truth tables for logical negation and equality, and you quickly realize that:
(! someString) and (someString == nil)
are for all intents identical!
So the next logical question is, why prefer one form over another? From a pure C view-point it would be mostly a point of style, but most (good) developers would choose the equality test for a number of reasons:
It's closer to what you are trying to express in code. You are
trying to check if the someString variable is nil.
It's more portable. Languages like Java have a real boolean type.
You cannot use bang notation on their variables or their NULL
definition. Using equality where its needed makes it easier to port
C to such languages later on.
Apple may change the definition of nil. Ok, no they won't! But it
never hurts to be safe!
In your case it means the same thing. Any pointer that does not point to nil will return YES (true).
Normally the exclamation mark operator negates a BOOL value.
If you mean to test the condition "foo is nil" you should say that: foo == nil.
If you mean to test a boolean value for falsehood, !foo is okay, but personally I think that a skinny little exclamation point is easy to miss, so I prefer foo == NO.
Writing good code is about clearly conveying your intention not just to the compiler, but to the next programmer that comes along (possibly a future you). In both cases, the more explicit you can be about what you're trying to do, the better.
All that aside, ! and ==nil have the same effect in all the cases I can think of.
! is a negation operator. If your object isn't allocated, you will reach the same result from a truth table as you would with an == nil operation.
But, ! is usually more used for boolean operations.
if(!isFalse) {
//if isFalse == NO, then this operation evaluates to YES (true)
[self doStuff];
}
When you use ! on an object like !something it just checks to see if the pointer is pointing to nil, if it doesn't, it returns true, and the if statement fires.
In most programming languages, 1 and 0 can be used instead of True and False. However, from my experience, integers seem to always be easier to use.
Here are some examples of what I mean:
if x is True: x = False
else: x = True
vs
x = abs(x-1)
__
if x is False: a = 0
else: a = 5
vs
a = 5*x
In what cases are booleans simpler/more efficient to use than 1 or 0?
You should always use any boolean built-in type for boolean values in high-level languages. Your second example would be a horror to debug in the case that x is true, but equal to a value different from 1, and a tricky one to figure out for any developer new to the code - especially one not familiar with your coding style.
What's wrong with
x = !x;
or
a = x ? 5 : 0;
One example where an integer could be more efficient than a boolean would be in a relational database. A bit column generally can't be indexed (I can't necessarily speak for all databases on that statement, hence "generally"), so something like a tinyint would make more sense if indexing is required.
Keep in mind that, depending on the use and on the system using it, while a boolean "takes less space" because it's just a single bit (depending on the implementation), an integer is the native word size of the hardware. (Certain systems likely use a full word for a boolean, essentially saving no space when it actually runs on the metal, just to use a simple word size.)
In high-level programming languages, the choice between a boolean and an int is really more of code readability/supportability than one of efficiency. If the values are indeed limited to "true" or "false" then a boolean makes sense. (Is this model in a given state, such as "valid," or is it not? It will never be a third option.) If, on the other hand, there are currently two options but there could be more someday, it might be tempting to use a boolean (even just "for now") but it would logically make more sense to use an int (or an enum).
Keep that in mind also when doing "clever" things in code. Sure, it may look sleeker and cooler to do some quick int math instead of using a boolean, but what does that do to the readability of the code? Being too clever can be dangerous.
For readibility and good intentions, it's always better to choose booleans for true/false.
You know that you have only two possible choices. With integers, things can get a bit tricky, especially if you're using 0 as false and anything else as true.
You can get too clever when using integers for true/false, so be careful.
Using booleans will make your intentions clearer to you 6 months later and other people who will maintain your code. The less brain cycles you have to use, the better.
I'd say in your examples that the boolean versions are more readable (at least as far as your intentions). It all depends on the context too. If you're sacrificing readability in an attempt to make micro optimizations, that's just evil.
I'm not sure about efficiency but I prefer booleans in many cases.
Your first example could be easily written as x = !x and x = abs(x-1) looks really obscure to me.
Also when using integers, you can't really be sure if x is 1 and not 2 or -5 or anything. When using booleans, it's always just true or false.
It's always more efficient to use Boolean because it's easier to process and uses less processing/memory. Whenever possible, use Boolean
Booleans obviously can only accept true/false or 0/1, not only that they use less processing power and memory as Webnet has already stated.
Performance points aside, I consider booleans and integers to be two fundamentally different concepts in programming. Boolean represents a condition, an integer represents a number. Bugs are easy to introduce if you don't strictly keep the value of your integer-boolean 0 or not 0, and why bother even with that when you can just use booleans, that allow for compile-time security / typechecking? I mean, take a method:
doSomething(int param)
The method alone does /not/ imply the param is interpreted as a boolean. Nobody will stop me from passing 1337 to it, and nobody will tell me what'll happen if I do - and even if it's clearly documented not to pass the 1337 value to the method (but only 0 or 1), I can still do it. If you can prevent errors at compile time, you should.
doSomething(bool param)
only allows two values: true and false, and neither are wrong.
Also, your examples about why integers would be better than booleans are kinda flawed.
if x is True: x = False
else: x = True
could be written as
x != x
whereas your integer alternative:
x = abs(x-1)
would require me to know:
What possible values x can have
what the abs() function does
why 1 is subtracted from x
what this actually /does/. What does it do?
Your second example is also a big wtf to me.
if x is False: a = 0
else: a = 5
could be written as:
a = (x) ? 5 : 0;
whereas your integer alternative
a = 5*x
again requires me to know:
What is X?
What can X be?
What happens if x = 10? -1? 2147483647?
Too much conditionals. Use booleans, for both readability, common sense, and bug-free, predictable code.
I love booleans, so much more readable and you've basically forced a contract with the user.
E.g. "These values are ONLY TRUE or FALSE".
In Programming in Scala the authors write that Scala's == function compares value equality instead of reference equality.
This works as expected on lists:
scala> List(1,2) == List(1,2)
res0: Boolean = true
It doesn't however work on arrays:
scala> Array(1,2) == Array(1,2)
res1: Boolean = false
The authors recommend to use the sameElements function instead:
scala> Array(1,2).sameElements(Array(1,2))
res2: Boolean = true
As an explanation they write:
While this may seem like an inconsistency, encouraging an explicit test of the equality of two mutable data structures is a conservative approach on the part of the language designers. In the long run, it should save you from unexpected results in your conditionals.
What does this mean? What kind of unexpected results are they talking about? What else could I expect from an array comparison than to return true if the arrays contain the same elements in the same position? Why does the equals function work on List but not on Array?
How can I make the equals function work on arrays?
It is true that the explanation offered in the book is questionable, but to be fair it was more believable when they wrote it. It's still true in 2.8, but we have to retrofit different reasoning because as you've noticed, all the other collections do element comparisons even if they're mutable.
A lot of blood had been shed trying to make Arrays seem like the rest of the collections, but this was a tremendously leaky abstraction and in the end it was impossible. It was determined, correctly I think, that we should go to the other extreme and supply native arrays the way they are, using implicit machinery to enhance their capabilities. Where this most noticeably falls down is toString and equals, because neither of them behaves in a reasonable fashion on Arrays, but we cannot intercept those calls with implicit conversions because they are defined on java.lang.Object. (Conversions only happen when an expression doesn't type check, and those always type check.)
So you can pick your explanation, but in the end arrays are treated fundamentally differently by the underlying architecture and there's no way to paper over that without paying a price somewhere. It's not a terrible situation, but it is something you have to be aware of.
This exact question has been voiced many times (by myself too, see Strange behaviour of the Array type ).
Note that it is ONLY the Array collection that does not support ==, all other collections do. The root cause is that Array IS the Java array.
It's all about referential transparency. The idea is, if two values are ==, it shouldn't matter which one you use for something. If you have two arrays with the same contents, it clearly matters which one you modify, so == returns false unless they are the same one.
I'm designing a language, and trying to decide whether true should be 0x01 or 0xFF. Obviously, all non-zero values will be converted to true, but I'm trying to decide on the exact internal representation.
What are the pros and cons for each choice?
It doesn't matter, as long as it satisfies the rules for the external representation.
I would take a hint from C here, where false is defined absolutely as 0, and true is defined as not false. This is an important distinction, when compared to an absolute value for true. Unless you have a type that only has two states, you have to account for all values within that value type, what is true, and what is false.
0 is false because the processor has a flag that is set when a register is set to zero.
No other flags are set on any other value (0x01, 0xff, etc) - but the zero flag is set to false when there's a non-zero value in the register.
So the answers here advocating defining 0 as false and anything else as true are correct.
If you want to "define" a default value for true, then 0x01 is better than most:
It represents the same number in every bit length and signedness
It only requires testing one bit if you want to know whether it's true, should the zero flag be unavailable, or costly to use
No need to worry about sign extension during conversion to other types
Logical and arithmetic expressions act the same on it
-Adam
Using -1 has one advantage in a weakly typed language -- if you mess up and use the bitwise and operator instead of the logical and operator, your condition will still evaluate correctly as long as one of the operands has been converted to the canonical boolean representation. This isn't true if the canonical representation is 1.
0xffffffff & 0x00000010 == 0x00000010 (true)
0xffffffff && 0x00000010 == 0xffffffff (true)
but
0x00000001 & 0x00000010 == 0x00000000 (false)
0x00000001 && 0x00000010 == 0xffffffff (true)
Why are you choosing that non-zero values are true? In Ada true is TRUE and false is FALSE. There is no implicit type conversion to and from BOOLEAN.
IMO, if you want to stick with false=0x00, you should use 0x01. 0xFF is usually:
a sign that some operation overflowed
or
an error marker
And in both cases, it probably means false. Hence the *nix return value convention from executables, that true=0x00, and any non-zero value is false.
-1 is longer to type than 1...
In the end it doesn't matter since 0 is false and anything else is true, and you will never compare to the exact representation of true.
Edit, for those down voting, please explain why. This answer is essentially the same as the one currently rated at +19. So that is 21 votes difference for what is the same basic answer.
If it is because of the -1 comment, it is true, the person who actually defines "true" (eg: the compiler writer) is going to have to use -1 instead of 1, assuming they chose to use an exact representation. -1 is going to take longer to type than 1, and the end result will be the same. The statement is silly, it was meant to be silly, because there is no real difference between the two (1 or -1).
If you are going to mark something down at least provide a rationale for it.
0xff is an odd choice since it has an implicit assumption that 8 bits is your minimum storage unit. But it's not that uncommon to want to store boolean values more compactly than that.
Perhaps you want to rephrase by thinking about whether boolean operators produce something that is just one 0 or 1 bit (which works regardless of sign extension), or is all-zeroes or all-ones (and depends on sign extension of signed two's-complement quantities to maintain all-ones at any length).
I think your life is simpler with 0 and 1.
The pros are none, and the cons are none, too. As long as you provide an automatic conversion from integer to boolean, it will be arbitrary, so it really doesn't matter which numbers you choose.
On the other hand, if you didn't allow this automatic conversion you'd have a pro: you wouldn't have some entirely arbitrary rule in your language. You wouldn't have (7 - 4 - 3) == false, or 3 * 4 + 17 == "Hello", or "Hi mom!" == Complex(7, -2).
I think the C method is the way to go. 0 means false, anything else means true. If you go with another mapping for true, then you are left with the problem of having indeterminate values - that are neither true nor false.
If this is language that you'll be compiling for a specific instruction set that has special support for a particular representation, then I'd let that guide you. But absent any additional information, for an 'standard' internal representation, I'd go with -1 (all 1's in binary). This value extends well to whatever size boolean you want (single bit, 8-bit, 16, etc), and if you break up a "TRUE" or a "FALSE" into a smaller "TRUE" or "FALSE", its still the same. (where if you broke a 16 bit TRUE=0x0001 you'd get a FALSE=0x00 and a TRUE=0x01).
Design the language so that 0 is false and non-zero is true. There is no need to "convert" anything, and thinking "non-zero" instead of some specific value will help you write the code properly.
If you have built-in symbols like "True" then go ahead and pick a value, but always think "non-zero is true" instead of "0x01 is true".
Whatever you do, once you select your values don't change them. In FORTH-77, true and false were defined as 1 and 0. Then, FORTH-83 redefined them as -1 and 0. There were a not few (well ok, only a few, this is FORTH we are talking about) problems caused by this.