I am also for what Martin says :).
And also: I'd argue that you NEVER EVER want to use simple Floats for
financial applications. In financial applications you really need
precision, and Floats have hardware limitations that do not provide
precision.
I thought ScaledDecimal (which I never used in Pharo) was meant to
provide high-precision decimal numbers to the expense of using an
internal representation that is not tied to the hardware limitations.
-------- Original Message --------
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
