Greg Ewing wrote: > The time isn't the main issue. The main issue > is that almost all the use cases for round() > involve doing an int() on it afterwards. At > least nobody has put forward an argument to > the contrary yet.
Or, more accurately, they *should* involve an int afterwards, but often don't, because people expect round(something) to produce an integer. Looking only at the one-argument round() calls not surrounded by int(), I would bet that most are bugs rather than intentional. The proportion is certainly high enough that I can't just trust it. Ron Adam wrote: > I think you are only considering part of the usefulness of round(). In > statistics and science math equations, rounding isn't used to get an > integer, but instead used to give an answer that is meaningful within > the margin of error of the data being used. Yes, but (1) Only for display (or storage). This rounding should explicitly not be done on intermediate values, as it introduces another source of error. (2) You need to pass the precision, so this isn't the one-argument round(). (3) As a side note, even the two-argument round may not be what you want; it isn't uncommon to have accuracy to a number of significant figures, rather than to an absolute "three places past the decimal point". This gets complicated enough that it is reasonable to use math.fround() or some such instead of a builtin. -jJ _______________________________________________ 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
