Tim Peters wrote: > OK, I looked, and it made no difference to me. Really. If I had an > infinitely tall monitor, maybe I could see a difference, but I don't > -- the sign of 0 on the nose makes no difference to the behavior of > 1/x for any x other than 0. On my finite monitor, I see it looks like > the line x=0 is an asymptote, and the graph approaches minus infinity > on that line from the left and positive infinity from the right; the > value of 1/0 doesn't matter to that.
Well, the value of 1/0 is undefined. Occasionally, it's useful to report +inf as the value of 1.0/+0.0 because practically we're more concerned with limiting behavior from an assumed limiting process than being correct. By the same token, we might also be concerned with the limiting behavior coming from the other direction (a different limiting process), so we might want 1.0/-0.0 to give -inf (although it's still actually undefined, no different from the first expression, and inf is really the same thing as -inf, too). Although I haven't read the paper you cited, it seems to me that the branch cut issue is the same thing. If you're on the cut itself, the value, practically, depends on which end of the branch you're deciding to approach the point from. It's arbitrary; there's no correct answer; but signed zeros give a way to express some of the desired, useful but wrong answers. And floating point is about nothing if not being usefully wrong. -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
