NumberField now bugs with default = NaN

[adannenberg]

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?

[adannenberg]

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.

[adannenberg]

The previous statement is now false?! NumberField(1:.1:10, default = NaN) now bugs with the error message:

InexactError: trunc(Int64, NaN) [email protected]:805[inlined] [email protected]:369[inlined] closest(::StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, ::Float64)@Builtins.jl:122 #NumberField#[email protected]:250[inlined] 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.

[lukeodowd]

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.

[fonsp]

@lukeodowd Can you create a fork, a branch, and a pull request? I am not sure how to work with floating commits.

[lukeodowd]

Hopefully I've done it properly this time... 213e97cebc202c2c191ca8cf22440c24bdf90edc Thanks for your work on this