Hi Martin,
yes, what i said was wrong (!). i got irritated when i used
#printShowingDecimalPlaces: on a directly entered decimal number <g> and
got a seemingly upwards rounded number. of course that result was also
correct. iow there is no problem in the new #round: or
#printShowingDecimalPlaces:. sorry for my confusion.
werner
On 11/06/2016 01:57 AM, Martin McClure wrote:
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
