Null & Empty Branches and basic arithmetic functions


(Daniel Fink) #1

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?

Null && Null == True?
(Daniel Fink) #2

(Also note this behavior is different (and more consistent with .NET null operations) in GH 0.9.0076)

(Daniel Fink) #3

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?

(David Rutten) #4

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

(Daniel Fink) #5

Thanks @DavidRutten!