-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
doc: signbit
underspecified in the case of negative zero, docs don't seem to align with implementation
#53964
Comments
On the other hand, if |
The floating point implementation is consistent with the IEEE 754
The implementation of |
I get why |
Or at least it isn't clear. The mathematical definition of "negative" is "less than zero". Specifically, negative zero isn't negative. |
The referent is an entity in a computer, not the mathematical abstraction. However, I think I can see the issue you are pointing to: "the value of" summons a slightly different notion. This could be made more clear by re-writing the docstring to unambiguously reference an entity in a computer:
|
Should the doc string then also define what "sign" means? |
Re-reading this today, I think the best clarity can be achieved by stating the following in the docstring:
It seems excessive to include the above. For people that do not understand computer representations of numbers, this would most likely be confusing rather than helpful -- for those that do understand computer representations of numbers, it is mere pedantry (in fact, quite poorly executed pedantry, as there are many other number representations). |
I get what you’re saying, but this just seems like an unhelpful sort of technically-correct. Yes negative zero is equal to zero, but it behaves as though it’s negative. That’s its point. Yes, it’s strange to have two equal values that have differing sign bits. It’s also strange to have two equal values whose |
Disagree, given the very reasonable So this isn't about some "mathematical" notion of negativity that would perhaps be overly abstract or technical to consider in the docs. This is simply a case of a doc string getting an edge case wrong in its description. |
There's also: julia> signbit.((-NaN,NaN))
(true, false)
julia> sign.((-NaN,NaN))
(NaN, NaN)
julia> signbit.(sign.((-NaN,NaN)))
(true, false) If we use the word sign, we shouldn't use or define it differently from The generic definition of
|
It exists for integers because most integer representations also have single exclusive sign bits (or no way of representing negatives at all), although it is used far less often for them since no native
I'm not quite sure how this should be reflected in the docstring, but I'll agree that the current docstring could use some minor improvements. It might be worth recommending that questions about values should use |
My point is that this is not currently apparent from the doc string, apart from in the name of the function. |
If there's a bit that isn't "true if x is negative and false if x is positive," then it's not a sign bit. |
I'll propose language like
Note that under the definition I wrote, That is to say that this is at least a minor change. I expect it would not be breaking in practice because one wouldn't (maybe merely shouldn't) abuse Any fix to this docstring is technically breaking in that the existing (and important) behavior for It would be very slightly less breaking if we stated a preference for I find the current examples in the docstring to be inadequate. They should emphasize the interesting cases as that's the whole reason to use this over julia> (signbit(5), signbit(-4))
(false, true)
julia> (signbit(+0.0), signbit(-0.0)) # signed zeros exist for this type
(false, true)
julia> signbit(NaN) == signbit(-NaN) # NaN includes a variable sign bit
false I'll also propose that we delete the |
The
signbit
doc string says:This seems to imply that a correct implementation would be
x < 0
, i.e. returntrue
iffx
is negative? However, for whenx
is a floating-point negative zero,signbit(-0.0)
istrue
even though-0.0
isn't negative.I guess it might be expected, from the perspective of the representation of floating-point numbers, that
signbit(-0.0)
istrue
, given that a negative zero has a set sign bit in its representation. However thensignbit
doesn't behave as documented? I guess the doc string need adjusting.The text was updated successfully, but these errors were encountered: