Re: [Python-Dev] Floor division
"Tim Peters"
OTOH, I am a fan of analyzing FP operations as if the inputs were in fact exactly what they claim to be, which 754 went a long way toward popularizing. That largely replaced mountains of idiosyncratic "probabilistic arguments" (and where it seemed no two debaters ever agreed on the "proper" approach) with a common approach that sometimes allows surprisingly sharp analysis. Since I spent a good part of my early career as a professional apologist for Seymour Cray's "creative" floating point, I'm probably much more grateful to leave sloppy arithmetic behind than most.
Well, I spent some of it working with code (and writing code) that was expected to work, unchanged, on an ICL 1900, CDC 6600/7600, IBM 370 and others. I have seen the harm caused by the 'exact arithmetic' mindset and so don't like it, but I agree about your objections to the "probabilistic arguments" (which were and are mostly twaddle). But that is seriously off-topic.
[remquo] It's really off-topic for Python-Dev, so I didn't/don't want to belabor it.
Agreed, except in one respect. I stand by my opinion that the C99 specification has no known PRACTICAL use (your example is correct, but I know of no such use in a real application), and so PLEASE don't copy it as a model for Python divmod/remainder.
No, /Python's/ definition of mod is inexact for that example. fmod (which is not Python's definition) is always exact: fmod(-1, 1e100) = -1, and -1 is trivially exactly congruent to -1 modulo anything (including modulo 1e100). The result of fmod(x, y) has the same sign as x; Python's x.__mod__(y) has the same sign as y; and that makes all the difference in the world as to whether the exact result is always exactly representable as a float.
Oops. You're right, of course. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679
participants (1)
-
Nick Maclaren