Hey Martin... I agree on the confusion.
I still recommend not rounding the number itself, but rounding the printing of the number
Yes. If "rounding" had well specified behavior that was at least somewhat reasonable (e.g. return the closest floating point value and round to even if tied), I'd accept floating point results that don't print "pretty" in base 10. That's the way things are, there's no point in pretending IEEE-754 is not base 2. If "rounding" is being done in place of "printing", or obtaining a "string representation", I think that won't work as expected because 0.1 not representable etc. For "printing", the algorithms were Dragon4 and Grisu3 last time I checked. For "floating point that works nice in base 10", there's IEEE-854. For those unfamiliar with the spec, it's been implemented in non-exotic hardware already.
you did proof that, as you said "1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1.".
As a suggestion for these types of problems, try iterating over a floating point bit range converting each to a true fraction and see which one is closest?
testIfCompletelyBroken [doesn't round to even]
I'd agree rounding to even would be better. Guillermo,
And also: I'd argue that you NEVER EVER want to use simple Floats for financial applications
Define "financial" applications? In the risk management world, tying down that last $1 difference will likely cost more electricity (and way more time) than the $1 is worth. John,
While ANSI says that the numbers should be converted using the default conversion table, all of the Smalltalkâs that Iâve tried donât follow that. Iâve tried Dolphin, VW, Pharo, & VAST, and all return fractions. I prefer this behavior over the ANSI behavior.
I agree that ANSI doesn't always make the best sense. If it were up to me, I'd follow the relevant standard to the letter. That's more important than providing a custom interpretation of an interoperability mechanism just for Smalltalk (or a particular dialect) by default. Nicolas,
printShowingDecimalPlaces:
That's quite a long selector. Has anyone considered an approach along the lines of this? 1.2345 %f #'3.2' => ' 1.23' 1.2345 %f #'03.2' => '001.23' A reminder: calling printf() via FFI is undefined behavior. Andres. On 10/26/16 23:31 , Martin McClure 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).
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