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:
i have to admit that i have no problems at all with this idiosyncrasy
and would _not use #asMinimalDecimalFraction in #round: for these reasons:
1. i see it as a poor mans round-to-even (this bankers rounding is done
so that the sum of rounded numbers does not have an upward bias in
relation to the sum of the original unrounded numbers).
2. although i havent tested it, i assume #asMinimalDecimalFraction is
noticeably slower than #asFraction, because the former one has to use a
#whileFalse: iteration.
3. round-to-even imprints a definite structure on eg random-numbers, the
structure of the new #round: is at least less simple & does not produce
too many even decimals, insofar it's even a rich mans round-to-even (in
a way a non-random, hence repeatable, stochastic rounding). normal
rounding of course introduces an even less wanted upward bias.
But <stupid grin> perhaps somebody else wants to have a more predictable
behaviour of #round:?
werner
On 11/04/2016 10:26 PM, werner kassens wrote:
Hi Stephane,
i uploaded a
SLICE-Issue-15471-Cant-round-Float-fmax-to-2-decimal-places-WernerKassens.2
to the inbox with these changes:
i corrected RandomTest>>testIfCompletelyBroken, completed tests with
some border cases and the usual specifications, and added your comment
to Float>>round:.
