Hi David.
Also copying this into the discourse forums, the bug identified by Michael Pryor about a year ago still seems to be present in GH v1.0.0004; null items have weird effects on the basic arithmetic components: they are either treated as 0, 1, or even ‘0-’ (in the case of subtraction, where null - x = x). Division seems to treat an operation on a null item as an ‘illegal’ operation that returns another null…
I tested this with empty branches and the same occurred. I would anticipate any arithmetic operation on a null or empty branch produces again a null or empty branch, or triggers an error/warning?
Is there a better solution to this other than writing our own code blocks to deal with null items or empty branches?
(Also note this behavior is different (and more consistent with .NET null operations) in GH 0.9.0076)
Not sure why this isn’t getting traction – the issue could be significant when dealing with empty branches, and also that script evaluation is inconsistent between 0.9.0076 & 1.0.0004:
0.9.0076 only inserts items into empty branches on addition (which I’m guessing can be thought of as relatively logical)…
While 1.0.0004 only maintains empty branches on division:
I’m not sure how it makes sense to insert items into empty branches on multiplication or subtraction…
With respect to null evaluation in arithmetic operations (previous posts), while C#/.NET is supposed to avoid this issue with the use of non-nullable value types, an arithmetic operation on a null evaluates to null, and also triggers a warning about why this occurs…
(code supplied:
A = 10 + null;
B = 10 - null;
C = 10 * null;
D = 10 / null;
)
@DavidRutten any thoughts about this?
Yeah it’s probably due to all inputs being optional. When you add a new input to an arithmetic operator I don’t want the component to stop working. But it’s probably messing with the null handling code.
Logged under RH-44502
