[Python-Dev] Floor division

Nick Maclaren nmm1 at cus.cam.ac.uk
Tue Jan 23 13:26:57 CET 2007


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" <tim.peters at gmail.com> 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:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


More information about the Python-Dev mailing list