[Python-Dev] Floor division (original) (raw)

Anders J. Munch ajm at flonidan.dk
Tue Jan 23 17:07:49 CET 2007

[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?

More information about the Python-Dev mailing list