# "True" and "False" in a floating point world

In Pictorus, *all signals* are currently represented as double-precision floating point numbers. Simply put, it means we store all values with sufficient precision to avoid common issues (like round-off and overflow) encountered when using lesser precision. It means our Apps are a little larger than they need to be, but we don't have to deal with overflow and rounding errors. In time we'll add more user control of variable sizing.

Since boolean logic is crucial to computer programming, we need to specify conventions for * True* and

*in this floating-point world. To keep things simple:*

**False**### When blocks *emit* a True/False value (i.e. Logical/Comparison blocks)

will always be emitted as**True***exactly*1.0will always be emitted as**False***exactly*0.0

### When comparing block outputs to evaluate "Truthiness"

is defined as**False***exactly*0.0.*ANY*value other than*exactly*0.0 is defined as(aka 1.0, 1.1, 12345.6789, -30000000, etc etc)**True**

Consider the example below, comparing a sinewave to a constant value zero. When the sinewave is larger, the comparison block emits "1.0", otherwise it emits "0.0":

Now consider this example, where we try to do a Logical AND between a sinewave and one:

You might be wondering why the logical block *always* emits * True*, even though there should be an instant where the sinewave equals 0.0 and so both signals are not "

*".*

**True**The reason becomes clear if we zoom in to the moment of zero-crossing, and consider the timestep of our application:

The sinewave crosses 0.0 at the irrational value t=3.14159..., but our app updated at times 3.1 and 3.2. So in both instances, the sinewave was "non-zero" and therefore * True*.

For situations like these, it can be helpful to use Deadband Blocks to force small values to zero. Also, its generally better to rework your diagrams where possible to lean on *"Less/Greater than or equal"* type expressions over *exactly "Equals"* expressions.