Re: a print bug?

Summercoolness@xxxxxxxxx schreef:
Steve Holden wrote:
You obviously haven't yet passed your floating-point number proficiency
test yet. Please restrict yourself to integers until you understand the
difficulties that inaccuracies in floating-point can create ;-)

hm, actually, i understand the limitation of floating point.
but my real concern is, how come "print" favors one version over the
other...
the first version will favor the correct rounding, while the second
doesn't favor it. to me, this is biased computing.... i will feel
happier if the behavior is consistent. (such as the first line
printing out as 1.2344999999999) . if most people favor the behavior
of line 1, that is, silently rounding off to about the 11th decimal
places, then why doesn't printing with formatting also use that same
behavior, which is rounding off to the 11th places first, and then
round off to whatever the user wants.

print 1.2345

1.2345

print "%10.3f" % 1.2345

1.234

but then again, i just realize even if i do a

round(1.2344999999999999999, 6)

1.2344999999999999

so even if you round it off, it is still represented the same way....
still, how "print" handles 1.2345 and treating it and printing it as
1.2345, i wonder why we don't make the "print with formatting" the same
behavior, treating it as 1.2345 first and round it off to 1.235

You do realize that your formatting uses less decimal places than the print statement, do you?

>>> print 1.2345
1.2345
>>> print "%0.3f" % 1.2345
1.234
>>> print "%0.4f" % 1.2345
1.2345

If you use 4 decimals after the decimal sign, you get the same result as with a plain print statement (at least in this case). That means that print is not treating it as 1.2345 first and then rounding it off to 1.235; it is just using the actual internal representation and rounding it off to 1.2345. Which IMO is the only sensible thing one can do.


--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven
.

Relevant Pages

  • Re: Decimal
    ... It is even calculating the decimals ... You can see that by clicking on a cell you entered data in and looking at the formula bar... ... You can truncate off any decimal value as if they were never typed in by the user in the first place, or you can round off the typed in value, but then there are two ways to do rounding in a macro, so you have to make sure you specify the right one. ...
    (microsoft.public.excel.misc)
  • Re: Rounding a number to nearest even
    ... That's exactly how I was taught to do rounding in what-ever low-level ... If you round towards an even number instead when the ... and the average rounding error will be 0. ... the nearest whole or half SEK, which means that decimals 25 and 75 are ...
    (comp.lang.python)
  • Re: Rounding a number to nearest even
    ... from mid-way between integers as opposed to for instance always rounding up in those cases: ... If you round towards an even number instead when the decimal is 5, then you will round up half of those times, and round down the other half, and the average rounding error will be 0. ... The standard in Swedish stores, after adding the prices of your goods, is to round the number to the nearest whole or half SEK, which means that decimals 25 and 75 are mid-way between. ...
    (comp.lang.python)
  • Re: Problems with Math.Round
    ... you need to role your own Round method like in this class: ... /// Rounds the double value to round to a specified number of decimals. ... Does not use Bankers Rounding. ... int digits) { ...
    (microsoft.public.dotnet.general)
  • Re: XQ and ->Qpi bug on large X
    ... you shouldn't be rounding to only two digits ... I am trying to make a similar point here about rounding; ... and round it, ... prior to using the input values in calculations. ...
    (comp.sys.hp48)