-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix some floating-point logic #77
base: master
Are you sure you want to change the base?
Conversation
I think the goal is to make the dual numbers take the same code path as the a real with the same real value would. |
Ya but sometimes |
In my view, it would be surprising if you got a different number of iterations until the algorithm exits when using reals or dual numbers. |
Dual numbers carry derivative information, so it's not inconceivable in a Maclaurin series that a derivative might overflow/underflow/NaN before the function does. This PR pulls dual numbers in line with complex numbers. |
This also fixes |
Why is this better than the status quo? Well, what Base function currently allows me to check whether all components of a dual number are finite? To be sure, the However, not having a finite check from Base on field extensions prevents generic code from working across all such extensions. Of course it's possible to adapt an algorithm for field extensions which need a bespoke finite check, but that defeats the purpose of generic code. I want to write an algorithm, test it with complex numbers (as part of Base) as a field extension, and have it Just WorkTM for any other field extension that a user loads. |
Seems like a big change, but feels "right": for all julia> 1.0 == nextfloat(1.0)
false So why would the current behaviour Though julia> isinf(NaN)
false so I would say the correct definition is: isinf(x::Dual) = isinf(value(x)) & isfinite(epsilon(x)) |
That's an interesting take on these checks -- ascribing the meaning of the unit dual from the limit definition. This proposal is akin to component-wise checking the matrix definition, Your argument would suggest that: isnan(x::Dual) = isnan(value(x)) | !isfinite(epsilon(x)) since an It also brings up the following issue with equality: julia> 1.0+ Inf*ε == 1.0+Inf*ε If |
According to the Julia Base docs,
==
for floating-point types should fail forNaN
s but not for zeros with opposite signs andisequal
should have the opposite behaviour for these cases.Currently, that behaviour is also replicated by complex numbers but not for dual numbers. To me, that seems inconsistent hence the pull request.
The corresponding change is made to
isnan
,isinf
, andisfinite
so thatisnan(x) == true
andisfinite(x) == false
iffx != x
, closing #15.