A generic comment. Many of my postings seem to be being misunderstood. I hold no brief for ANY particular floating-point religion, sect or heresy, except insofar as it affects robustness and portability (i.e. "software engineering"). I can work with and teach almost any model, and have done so with some pretty weird ones.
My objections to some proposals is that they are sacrificing those in favour of some ill-defined objectives. "Tim Peters" <[EMAIL PROTECTED]> wrote: > [TIm Peters] > >> That's wrong, if true: it should return something with the opposite > >> sign on the imaginary part, whether or not that equals 0 (+0. and -0. > >> both "equal 0"). > > |[Nick Maclaren] > > Grrk. Why? Seriously. > > Seriously: because there's some reason to do so and no good reason > not to. Hmm. That doesn't fully support the practice, except for IEEE 754(R) numbers. To require a floating-point format to have signed zeroes is a religious matter. But I agree that specifying something different if the numbers are an IEEE 754(R) format makes no sense. > > And, returning to 'floor' - if one is truncating towards -infinity, > > should floor(-0.0) deliver -1.0, 0.0 or -0.0? > > I'd leave a zero argument alone (for ceiling too), and am quite sure > that's "the right" 754-ish behavior. It's not clear, and there was a debate about it! But it is what IEEE 754R ended up specifying. > Couldn't quite parse that, but nearly all of Python's math-module > functions inherit most behavior from the platform libm. This is often > considered to be a feature: the functions called from Python > generally act much like they do when called from C or Fortran on the > same platform, easing cross-language development on a single platform. And making it impossible to write robust, portable code :-( Note that most platforms have several libms and the behaviour even for a single libm can be wildly variable. It can also ENHANCE cross-language problems, where a user needs to use a library that expects a different libm or libm option. > Do note the flip side: to the extent that different platform > religions refuse to standardize libm endcase behavior, Python plays > along with whatever libm gods the platform it's running on worships. > That's of value to some too. Actually, no, it doesn't. Because Python doesn't support any libm behaviour other than the one that it was compiled with, and that is often NOT what is wanted. > So which one would you prefer? As explained, there are 3 plausible > candidates. > > You seem to be having some trouble taking "yes" for an answer here ;-) Actually, there are a lot more candidates, but let that pass. All I am saying is that there should be SOME defined AND SANE behaviour. While I would prefer an exception, I am not dogmatic about it. What I can't stand is completely undefined behaviour, as was introduced into Python by C99. > > What I was trying to point out is that the current behaviour is > > UNDEFINED (and may give total nonsense). That is not > > good. > > Eh -- I can't get excited about it. AFAIK, in 15 years nobody has > complained about passing a 0 modulus to math.fmod (possibly because > most newbies use the Windows distro, and it does raise ValueError > there). Some people write Python that is intended to be robust and portable; it is those people who suffer. > What Guido would rather do, which I agreed with, was to have > x.conjugate() simply return x when x is float/int/long. No change in > value, no change in type, and the obvious implementation would even > make ... Fine. I am happy with that. What I was pointing out that forcible changes of type aren't harmful if you remove the "gotchas" of loss of information with coercions that aren't intended to do so. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761 Fax: +44 1223 334679 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com