[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
participants (1)
-
Anders J. Munch