Maybe Float::{is_positive, is_negative} should return false for 0's?

[huonw]

Over the real numbers, one doesn't usually consider zero to be explicitly positive or negative (one has to qualify as "non-negative" or "non-positive" respectively to get those classes including zero), so it is a little strange to me that we include 0.0 in the former and -0.0 in the latter.

However, floats are special (signed zero), so maybe the current behaviour is OK. I suppose the "real number" behaviour can be replicated with just > 0.0 and >= 0.0, while these functions are checking the IEEE-754 sign bit.

[huonw]

Nominating, as we may wish to change these functions slightly. (E.g. C/C++ calls this functionality signbit, effectively, although the handling of NaN is different.)

[Manishearth]

Sounds like a gotcha that might happen, people could write code like:

if if is_positive(foo) {

} else if is_negative(foo) {


} else {
 // case 0
}

I agree that renaming may be a solution here, something explicitly about the sign bit could avoid misuse.

If you needed this feature in a random language, what string would you search for in the docs?

[nagisa]

― boolean isSignMinus(source)
isSignMinus(x) is true if and only if x has negative sign. isSignMinus applies to zeros and NaNs
as well.

– IEEE 754

To me it sounds like at least the behaviour of is_negative wrt signed zero is correct.

[huonw]

The names of the functions in the standard are explicitly talking about "sign", i.e. the sign bit, whereas our method names are just referring to the less technical "negative" and "positive" concepts.

[pnkfelix]

P-backcompat-libs, I-needsdecision, 1.0 beta.