Hello! 
I’ve found that the result of subtraction with nulls looks like this: null - number = number
It would be cool to know the reason behind it. The issue is that it can be hard to spot this behaviour when the calculations are complex.
Of course there are multiple ways to avoid it manually (removing nulls, GHPython/C# checking for nulls etc.) but maybe it will be cool to consider returning different result 
NullSubstraction.gh (4.0 KB)
I guess it came into Grasshopper because of vector subtraction. Subtracting a point from a Null point could somehow assume it’s the World Origin and then just returning the direction vector which equals what is in B (just instead of being a Point3d being a Vector3d instance).
This is definitely a bug. Numbers are value types in most languages and don’t allow NULL states, at least without wrapping around an object (e.g. Nullable). Numbers can be in ‘NaN’ state, but then a subtraction would also return ‘NaN’. But NaN and NULL are not the same. NULL means it is not initialized/ not assigned and this is a state you should prevent in first place. But how should a floating number become NULL unless you are doing some weird type casting or odd data manipulation? Isn’t that unlikely?
@TomTom Yeah, it appeared when I had array of Nullables
@Dani_Abalde Well, it looks like you discussed this issue already While null + number = number is not that bad, then null * number = number or null - number = number: this is really non-intuitive, anyway at least there should be a balloon message about it (in my opinion).
Ok, seems to be discussed in the other thread. I still find this very wrong. I would always throw or at least log a warning as soon as one parameter becomes NULL because this is obviously an invalid state the component (and even the system) is in. Silently catching NULL exceptions and handling them (even if it makes somehow sense) is bad, because NULL states are nasty to debug if they are unwanted.
