You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been thinking about best do this, but I think it's a bit tricky. My initial idea was to allow Measurement type to have parameter of type Union{AbstractFloat,Missing}, instead of just AbstractFloat. Note that this is the type of both the measurement value and its uncertainty, so
y =1.0±missing
wouldn't be allowed, or at least it'll be automatically converted to
y =missing±missing
I don't see great value in separating the types of the value and the uncertainties, this helps us keeping type-stability in many situations.
The idea proposed above is doable, it just requires some work to be done -- help is always much appreciate! What worries me most about my suggestion is that you can have a missing measurement Measurement{Missing}, but this will be subtype of AbstractFloat instead of Missing: we can certainly define
Base.ismissing(::Measurement{Missing}) =true
but any code relying on a missing value being subtype of Missing would fail to detect it.
I'm not sure it makes sense, but wouldn't it be nice to be able to deal with
missing
measurements?E.g., have
not throw errors and just propagate the
missings
for things likex+y
orx+z
?The text was updated successfully, but these errors were encountered: