On 10/27/2016 10:34 AM, Nicolas Cellier wrote:
2016-10-27 9:51 GMT+02:00 Denis Kudriashov <[email protected]
<mailto:[email protected]>>:
2016-10-27 8:31 GMT+02:00 Martin McClure <[email protected]
<mailto:[email protected]>>:
I think roundTo: is OK. #round: is not, and should be
deprecated (at least for Floats). For Floats, the idea of
rounding to a specific number of decimal digits is a fantasy.
Here's why: Floats cannot exactly represent most common
decimal fractions. For example:
0.1 -- not representable
0.2 -- not representable
0.3 -- not representable
0.4 -- not representable
0.5 -- hey, representable!
0.6 -- not representable
0.7 -- not representable
0.8 -- not representable
0.9 -- not representable
1.0 -- representable.
*Printing* a Float to a specific rounded decimal format is a
sensible idea, and should be encouraged. But trying for a
"rounded Float" *number* just can't be done exactly (except by
converting to a Fraction).
Fractions can be rounded to exact decimal fractions, so
something like "myFraction roundTo: 1/100" makes sense. But
the current implementation of round: on Fraction that converts
to a Float just gets you the misery detailed above.
On 10/26/2016 01:00 PM, Nicolas Cellier wrote:
I've put a single slice in the inbox for the 3 issues because
they all are related.
See slice comment:
For Float, implement guard to prevent overflow (15471), and
use exact representation for intermediate results
(asFraction) so as to avoid double rounding problems (15473)
The double rounding problem is not the fundamental problem,
the fundamental problem is that what is desired does not
exist, because Floats cannot exactly represent most decimal
fractions. So this can't really fix it.
Exactly. Thank's for good explanation
Nonetheless, if user asked to round a Float, we must give him back a
Float.
We ain't gonna answer a ScaledDecimal because we think that it's
better for him: we don't know what is better for him.
And we MUST do our best to round correctly to the NEAREST Float that
is 0.1e0, 0.2e0, ... 1.0e0
If user asked to round a Fraction or ScaledDecimal, then it's different.
We'd better keep the exactness and use ScaledDecimal rather than
convert to a Float.
That's exactly these two things that the SLICE posted in inbox is doing.
i completely agree (well, i would have preferred a pure Fraction result
in the pure Fraction case instead of a ScaledDecimal, but so what)
werner
p.s. a pure Fraction result in the pure Fraction case would also insure
that the rest of Number is more or less independent of the not very
useful ScaledDecimal
