I’m having an issue while manipulating zero, math formula and rule engine. I’ve created a basic worflow as demo. My issue is that multiplying a zero with a negative value creates a negative zero. Which is then no more identified as zero by the Rule Engine…
As a general rule in informatics, a double should never be compared using an “=” condition, because double numbers are coded in a way (using floating comma) that leads often to rounding problems with decimals and hence wrong comparisons.
The right way to overcome this kind of problems is to set a condition which integrates the rounding error, for instance in the rule engine:
value < 0.00000001 AND value > -0.00000001 => “It is a Zero coded as double”
TRUE => “It is not Zero”
Up to you to define which is your acceptable rounding value (here set to 0.00000001) to decide when a -double coded number- should be considered as equal to Zero.
Thanks for the head up. I’m fully aware of this limitation. In my specific contexte, I’m searching for true 0 coded as double. And now I have to search for 0.0 and -0.0. Not that a big issue, but that’s something that you need to know…
I fully agree with you. May be the problem you have spotted is related to the way KNIME converts strings into doubles in some nodes. A similar problem is described in the post below when rounding integers:
The problem may thus come from the fact that the numbers one enters in the Table Creator are originally strings that are converted into doubles. I guess the String to double conversion done by the -Table Creator- node is not handled in the same way for a 0.0 and a -0.0, most probably because of the rounding scheme used by KNIME to convert strings into doubles.
It appears that positive zero double and negative zero double in Java are two different things… but how does this work when someone uses == to compare a positive and a negative zero?
Let’s start with something that is positive absolute zero, no rounding, by having a Math Expression node return a 0:
Then, in a second Math Expression node, take the negative of this positive zero and put it in a new column:
Result:
Are these the same? Let’s ask a Java Snippet:
Result:
So, Java does not regard a table cell with a positive zero as the same as a table cell with a negative zero.
However…
yields
Even
yields
That’s odd! Is NegDouble really negative zero here? Yep:
I don’t understand… Does it have something to do with Double object-to-primitive unboxing?
Edit:
in the example below i force Java to compare primitives… and now the table cell values are suddenly equal: