2016-10-27 11:04 GMT+02:00 test <[email protected]>: > On 10/27/2016 10:34 AM, Nicolas Cellier wrote: > > > > 2016-10-27 9:51 GMT+02:00 Denis Kudriashov <[email protected]>: > >> >> 2016-10-27 8:31 GMT+02:00 Martin McClure <[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 >
+1 feel free to improve the slice.
