Mark Dickinson <dicki...@gmail.com> added the comment: > I continue to wonder what is the rationale for these specifications
So I can't speak with any authority: I'm only an interested bystander when it comes to IEEE 754, but I believe this particular behaviour stems from two desires: 1. The desire that for a general floating-point operation f, f(-0.0) should behave in much the same way as f(+0.0): if one is valid, the other should be too, and in the majority of cases they should give the same result (possibly modulo sign of zero again, and noting that in cases like atan2 there are good reasons to have 0.0 and -0.0 give different results). So this justifies things like `sqrt(-0.0)` giving a zero result (rather than being considered invalid) and `log(-0.0)` giving `-inf`. In the case of interest, this justifies the rule `pow(-0.0, y) = 0.0` for `y` positive and not an odd integer. Note the sign of the result there: what's really going on is that we can't assign a sensible sign to the result (except when `y` is an integer), and so it makes sense to return the more "standard" of the two zeros. 2. The desire to respect symmetries in pow (and other functions). In particular, we should have pow(1/x, y) = 1/pow(x, y). Now plug in x = -0.0 and y = 0.5, and we get: pow(-inf, 0.5) = 1/pow(-0.0, 0.5) = 1/0.0 = inf I guess also: historically, C99 Annex F got there first on specifying corner cases for the more interesting mathematical operations (IEEE 754-1985 only covered basic arithmetic operations; coverage of the transcendental functions and friends didn't happen until IEEE 754-2008), and without a good reason to do otherwise, it makes sense for IEEE 754-2008 to follow what C99 did. So perhaps we should really be asking the C standardisation folks for their rationale. Don't ask me about sqrt(-0.0) returning -0.0 rather than 0.0, though. I have no idea on that one. (Well, I have some ideas about _why_ that ended up being the IEEE 754 specification. I'm still not convinced that it was the right thing to do.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32171> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
