> On 27 Oct 2016, at 08:31, Martin McClure <[email protected]> wrote:
> 
> On 10/26/2016 08:27 AM, stepharo wrote:
>> So what is the definition of printShowingMaxDecimalDigit:?
>> I have the impression that there is a confusion between the rounding a 
>> number and the printing of his value in a given format. 
> 
> Yes, I see quite a bit of confusion in this thread about that. 
> 
>> we can deprecate roundTo: if necessary. 
> 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).

YES !

Nice explanation.

> 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.
> 
>> 
>> For Fraction (15472), choose an exact representation for result rather than 
>> Float. This is because such method is particularly usefull for 
>> financial/monetary applications.
>> 
> Yes. Fraction or ScaledDecimal. Not Floats, unless the developer understands 
> the needs of the financial world and the limitations of Floats very well.
> 
> 
> Regards,
> 
> -Martin


Reply via email to