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