On 11/05/2016 06:17 AM, werner kassens wrote:
Hi,
fwiw when i redid that #testIfCompletelyBroken i noticed a sort of bug
in that new #round: - well, i think its a feature -, but i should
probably mention it nevertheless:
1.15 round:1. "1.1" "down"
1.25 round:1. "1.3" "up"
1.35 round:1. "1.4" "up"
1.45 round:1. "1.4" "down"
1.55 round:1. "1.6" "up"
1.65 round:1. "1.6" "down"
btw the same happens with #printShowingDecimalPlaces: (which is
unchanged, happens eg also in 4.0).
if one wants to change this to the normal behaviour, i'd guess one
could do it perhaps by using #asMinimalDecimalFraction instead of
#asFraction in #round:
This is, in part, an example of it being difficult to predict, at a
glance, what #round: should do, without an understanding of the
strengths and limitations of binary floating point numbers.
Remember that Floats are not usually exact representations of nice
decimal fractions. So most of these numbers are not *exactly* halfway
between their possible roundings.
1.15 < (115/100) "true"
1.25 = (125/100) "true"
1.35 > (135/100) "true"
1.45 < (145/100) "true"
1.55 > (155/100) "true"
1.65 < (165/100) "true"
In every case except 1.25, the answer is the correct rounding, that, is
the one that is closer. For 1.25, the number *is* exactly halfway
between two roundings. For round-to-even (which I recommend) the answer
should be 1.2, so it gets that one "wrong".
Regards,
-Martin
