2016-10-27 9:51 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>: > > 2016-10-27 8:31 GMT+02:00 Martin McClure <mar...@hand2mouse.com>: > >> 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.
