# Not as simple as you might assume: Testing for “true” or 0.0

Calling all Programmers and Builders of Strategies –

Do you know what’s “true”? Are you sure?

When testing to see if something is “true” vs. “false” (in Opto 22 products, and elsewhere when programming in general), keep in mind that an integer representation of “false” is pretty consistently 0, but “true” might be 1, -1 or more generally “non-zero.”

What’s the best way to make your code as robust as possible?
(Hint: you don’t need to test for both 1 and -1.)

In a Condition block, use the “Variable True?” command, rather than “Equal?” to -1 or 1.

In a Script block, there’s a few options. You might have code like this:

``````if (bFlag == -1) then
// do something here
endif
``````

That can be simplified to just the following. There’s no reason to do a comparison. The integer automatically gets resolved down to either a zero or non-zero value.

``````if (bFlag) then
// do something here
endif
``````

If that’s not clear enough, another option is the following.

``````if (IsVariableTrue(bFlag)) then
// do something here
endif
``````

FYI, PAC Display now lets you pick what true means to you: -1 (the default) or +1.

Also, when comparing float values to 0.0, remember that you could get very very close to zero but not exactly. So testing to see if a float is equal to zero is not good.

Instead, evaluate the absolute value of the difference between the floats you’re comparing. For more info on comparing floats and other issues related to storing floating-point values in a binary-based computer, see form 1755: Using Floats Technical Note.

Happy coding!
-OptoMary

This came up when I was working wit Ben (my old boss, and not(a bad boss)) and the new snap PAC gear came online. The old factory floor stuff (M4’s) used to universally have -1 as a on/true value. Being a slightly ‘green’ in optoscript programming I used to check for -1 for variables/dig points in my scripts (because i was !(awesome)). When the PAC stuff came to us, some of the scripts wouldn’t work. Pretty quickly it became evident that the old -1 check was the problem. So when doing checks for ‘true’ I changed my programming to <>0. His solved my problems. I know I could use isvariabletrue(somevar) but lets face it, when yr punching out script it’s easier to type the varname as opposed to isvariabletrue (call me lazy)!
I still use this check in script work because I’m lazy(!). So my checks are generally
If (somevar<>0) then
Do something
Endif

I use them in switch statements as well to check for true
Switch(not(0))
Case (somevar==someval):
Do something
Break;
Endswitch

When comparing floats to 0 I find that Opto does a pretty good job of doing a float to int conversion in script. If using an action or compare command I reckon comparing a float to an integer 0 works the best. It hasn’t failed me yet (but I wasn’t touching wood when i punched this out…)

Nick

Hi Nick,

I prefer the word “efficient” over lazy.

When using that 2nd flag option above, I like to name my flag something descriptive so it almost reads like English, for example:

``````if (bBigTankIsTooHot) then

// cool off Big Tank

endif
``````

Also, sometimes if I’m writing a loop in OptoScript that I want to loop forever (with a delay in it, of course), I might have something that looks like this:

``````while (0 == 0) // loop forever

// or at least until the power goes out!

wend
``````

Forgot to mention that form of “true” before.

-OptoMary

Ok, so to be clear. I may (or may not) have taught Nick a thing or three about ‘Opto’, but he taught me a great deal about programming in OptoScript. I’m sure Nick remembers the many times I told him how I was flat out scared of the stuff.
Its also probably my fault for Nicks first goes at checking for the exact value of -1. I simply did not know any better!
Im still not super fond of it, but Mary has picked up where Nick left off and has been dragging me kicking and screaming into the world of OptoScript.
I mention that because it is different if you are not used it, but here we are years down the track, and I find myself dumping an OptoScipt block right after ‘Block 0’ in pretty much every chart I write these days…

So, that said, this whats-true-whats-false-and-how-to-test-for-it still trips me up a bit…

I like and use this method a fair bit to do stuff if a variable is true;

``````
if (digitalIN) then
do stuff if the point is on
endif

``````

Its clean and efficient. Of course it does not have to just be a digital in:

``````
if ((digitalIN) and (someVAR)) then
do stuff if both the digital in and the var are true
endif

``````

Is there an advantage or disadvantage from doing this way vs the way Nick said?
(No offense Nick, but the whole <>0 trips me up when I am reading it because I see the zero, and I think the var has to be zero to do the do… I still have trouble thinking in reverse after all these years!).

Ok, so that’s true, but what about not true?

We can do this pretty quick and clean:

``````
if (not(digitalIN)) then
do stuff if the point is off
endif

``````

But is simply putting ‘not’ in front the best way to ‘read’ your code?

Im not the best typist, so I need it quick to bang out, and the whole ‘isVariableTrue’ or isVariableFalse’ is just too much work for my fingers (and brain).

I just want to know the best way to check for true and false that is easy to type and easy to read.

Ben.

P.S Really enjoying this ‘how to program 101’ thread!

We do like to give you choices, and which you choose here is more a matter of style or preference.

However, I would say the “best” thing to do no matter what your personal style (or any coding guidelines you might be given) is to add a little comment with your intent. So that:
[INDENT]1) you don’t have to stare at the code to figure out what it’s supposed to mean

1. just in case it’s not working as you expect (maybe the evil code elves got your keyboard when you weren’t looking), you at least know what you MEANT for the code to do, and will have an easier time fixing/troubleshooting!

They conclude the page by saying a couple of things which I think are relevant here: “The point of having style [B]guidelines[/B] is to have a common vocabulary of coding so people can concentrate on [B]what you are saying, rather than on how you are saying it[/B].” [emphasis mine] So to increase the odds of that happening, use lots of comments.

But don’t take my word for it, there’s a whole big section in this same page on comments. Here are my favorite parts: “…comments are absolutely vital to [B]keeping our code readable[/B]. … Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments. … When writing your comments, write for your audience: the next contributor who will need to understand your code. Be generous — the next one may be you!”

Write on, OptoFans!

-Mary

In OptoControl (at least) when you use “not” it actually returned a value of 0 or -1. In PAC Control, I assume that it returns 0 or 1 (I haven’t tested it).

This actually means that you can use any number as a 0 or 1 by:

``````result = not not anynumber;
``````

this is also a simple extension to the truth test. It automatically changes any true number to the current value of “true” in the OS.

I’ve used this a couple times.

I do have a question in the code from ben

in the example

``````if ((digitalIN) and (someVAR)) then
do stuff if both the digital in and the var are true
endif
``````

wouldn’t it be easier to read without extraneous parenthesis?

eg

``````if (digitalIN and someVAR) then
do stuff if both the digital in and the var are true
endif
``````

alanlevezu,

Your double negative to make a positive is interesting.

Re the code, which is more readable…