[Python-Dev] Floor division

[Anders J. Munch]

[Tim Peters]
> [Anders J. Munch]
> > I did read the whole thread, and I saw your -1%1e100 example.  Mixing
> > floating-point numbers of very different magnitude can get you in
> > trouble - e.g. -1+1e100==1e100.  I don't think -1%1e100 is all that
> > worse.
> 
> Except that it's very easy to return an exactly correct result in that
> case:  -1.  

Except that the function that computes -1 is a different function.

Either it makes a difference which function is computed or it
doesn't:

If it makes a difference, because the first operand may be negative,
then the programmer absolutely has to choose the correct function, or
the program will have a bug.  If the correct function is one whose
result cannot be exactly represented, then there's nothing that can be
done about that.  Whether the function is called using a % infix
operator or using math.untrustworthy_intlike_fmod doesn't change the
fact that the result is going to be inexact.

If it doesn't make a difference, because the first operand is always
positive, then both functions provide exactly representable results.
So regardless, the current float.__mod__ doesn't create inexact
results where exact results are possible.

Suppose for example I'm normalising radians to the [0; 2*math.pi]
range using

   radians %= 2*math.pi

Changing that to

   radians = math.fmod(radians, 2*math.pi)

would simply be incorrect.  I could of course rewrite that to give the
correct result with a conditional and a bit more calculation, still
using math.fmod, but then the inexactness would reappear.

> It was natural to /want/ to extend it to floats.  That didn't work
> well, and to the contrary it's surprising precisely /because/ the
> behavior people enjoy with integers can fail when it's applied to
> floats.  

What makes you say it didn't work well?  What user experiences do you
base that on?

- Anders