Open adannenberg opened 2 years ago
Apologies: It appears to have nothing to do with version number. NumberField(1:10,default=NaN) bugs but NumberField(1:.1:10,default=NaN) initializes with a blank field.
The previous statement is now false?! NumberField(1:.1:10, default = NaN) now bugs with the error message:
InexactError: trunc(Int64, NaN) trunc@float.jl:805[inlined] round@float.jl:369[inlined] closest(::StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, ::Float64)@Builtins.jl:122
top-level scope@Local: 1[inlined]
Can someone clarify what's going on? Apologies for the changing narrative, but this is something that worked for weeks prior to today and now has unstable behavior.
I've hit the same speed bump and looked into it a bit.
It looks like the closest
function in Builtins.jl has some logic to determine whether the element is outside the range (<= rmin, >= rmax) and assumes it is inside the range if not. NaN returns false on both of these accounts, but still isn't inside the range.
A simple test at the start of the function could fix this
if isnan(x); return x; end;
I've added the pull request under commit 0495293f93b65669384d75860fc2a2641a38f510
Hope this helps.
@lukeodowd Can you create a fork, a branch, and a pull request? I am not sure how to work with floating commits.
Hopefully I've done it properly this time... 213e97cebc202c2c191ca8cf22440c24bdf90edc Thanks for your work on this
this worked in v0.7.29. I used the default=NaN configuration for inputs that are optional. You can then use isnan on the associated variable to avoid extra calculations associated with the optional input.
Can NumberField be changed back so as to allow a default value of NaN and have the displayed cell remain empty?