I’ve got some unexpected results from the equal compare command. I probably don’t see the logic so it would be great if somebody could clarify it for me.
I’ve got this piece of code:
Value1 var sword
Value2 var sword
test var bit
Value1 = 12
Value2 = 12
test = Value1=Value2
serout s_out, i38400, [sdec Value1, " ", sdec Value2, " ", sdec Value1=Value2, " ", sdec test, 13]
This results in:
12 12 -1 1
Why does Value1=Value2 result in -1?
I should expect:
Option A: 1 the 2 values are equal
Option B: 12 the commando copies Value2 in Value1 and returns the result
Actually it does make sense. A lot of compilers do set all bits to 1 (-1) with a True condition as any value but zero is considered true, that way whatever bit you test will be on.
Likewise in your case if then assign it to a bit, then that bit will be set. With your value Test which is only one bit, it probably has no clue how to sign extend that so it is either 0 or 1…
Now it makes perfect sense!
I was familiar with TRUE being <> 0. I don’t know if It’s possible to declare it the way you did but it sure it better then FALSE con 0. I’ll check that out tomorrow!Good idea. I didn’t expect a default compare would end up with -1.
Again, Thanks for clarifying this.
Kurte hit it on the nose. FALSE = 0 and TRUE = NOT FALSE with is -1 if looked at as a signed integer.
Alan, to do a TRUE that wasn’t -1(if looked at as a signed integer) in our basic would require a whole new variable type(like C/C++ has the bool type).
But since you should be looking at the value as TRUE or FALSE(singe you are doing a boolean comparison), not as a signed integer, it shouldn’t be a problem.
Xan, there is no #define in MBasic so you have to use FALSE con 0(which in fact works out exactly the same as a #define FALSE 0 would).
I believe you can do:
FALSE con 0
TRUE con NOT FALSE
But your TRUE will still end up being -1 if looked at it as a signed integer.
Edit: In your code it looks like you are outputting the variable “test”, correct?
You could try outputting “-test” which would negate the variable to be 1 instead of -1.
It took some time but I finally had some time to test above option. Sadly enough it didn’t give me the suspected result. Maybe I’m doing something wrong here.
Could you just invert the output like I said above by putting a negative(-) sign next to the constant you are outputting? Or to make it easier, just add another constant like:
FALSE con 0
_TRUE con !FALSE
TRUE con -_TRUE
In this code, TRUE is the inverted version of _TRUE.
That is assuming you have FALSE defined as 0 and TRUE defined as any value but 0. In my code I only use these defines as simple assignments.
Things like:[code]
validate var bit ; could be other data types like byte, sbyte, … as well
fValidData = TRUE
; or
fFalidData = FALSE[/code]
For Comparisons I simply use the zero/non-zero states. Things like:
if fValidData then ; Simple test will happen if Valid Data is not zero
if (fValidData <> 0) then ; same as the above
...
if !fValidData then ; will happen if Valid Data is zero
if not fValidData then ; same as above
if (fValidData = 0) then ; same as above
I typically never test for TRUE for any specific value except maybe in the case of a bit variable as it can only be 0 or 1…
I also tend to use more parenthesis than are required as I used to always be burned when I made assumptions on what order things will be compared…
Might not actually work that way. We want to flip all bits (or the only bit), not just the sign bit. And using a “signed” operation requires a “signed” variable. Not sure if it is enforced in AtomBasicPro or not.
And you are playing with the _ (underscore) which is usually reserved for ASM variables an what not. Again, not sure if it is enforced in AtomBasicPro or not.
And on a third note, TRUE/FALSE is a boolean, so use of a boolean operator (!) is preferable to a non-boolean (integer, float, etc) operator. Otherwise, side-effects can get ya!
But of course, Who knows what will or won’t work here. We’re not exactly using ANSI BASIC. This is a special “embedded” Basic. (Notice the different spelling of BASIC).
Yeah, the code was not intended to be used “as-is”. I was giving an example. I have not actually done any programming on a the BA Pro, but I am basically trying to make a logical explanation.
So, why not just say “TRUE = 1” - just like you did with “FALSE = 0”? Sorry if there is an obvious answer. Just curious.
Don’t feel bad, it’s a little more complicated then what’s on the surface. We “fix” FALSE to be 0, and then anything else is TRUE. Very transportable to other versions of BASIC, and in fact to other languages. While you might “get by” with other constructs, they might not always work.
TRUE = 1 and FALSE = 0 will usually work. Good for a bit. Maybe not so good for a byte. We really don’t want to “mix” integer/FP math and boolean math. It just keeps it all cleaner!
BASIC was originally written quite “loose” in regards to rules. To make it easier for beginners, I think. Better and more reliable code usually results from some stricter rules in the manipulation of numbers and of logic.
So why would TRUE need to be equal to 1?
I use Boolean logic all the time in video game programming. Occasionally I will do something like:
if (value != false)
{
//do something if "value" does not equal false.
}
My point is, if you wanted to check to see if a variable was true, you could just see if it is not false. the only other value besides false would be true. Correct?
Edit: sorry for hijacking this thread. I took a look at Xan’s original post and what he is trying to do makes more sense now. Thinking about it now, I realize there probably isn’t a cheap way around this. !0 is -1, and I’m not sure anything can change that.
Sure, you can use “if (value != false)”, that works, but why use a double negative? You can just use “if value = true”, or even “if value”. So much simpler, to my thinking.
You could make TRUE = 0, and False = !TRUE, maybe it’s just convention. Probably wouldn’t work with my “if value”, 'tho.
Thanks for all your replies. I think I’ll go with Kurt his option on this one. Just dropping the TRUE/FALSE names and using =0 and <>0. It’s just a bit harder to read but will do the job perfectly.
I still would like to know why the options I used in the previous post don’t work but doesn’t give a compiling error…
