Yes, I was working at a large insurance company and some C code that did calculations on lots and lots of entries triggered an audit due to sizeable discrepancies in monetary terms.
I turned out that the code compiled on a x86 PC didn't gave the same results as the same code compiled on the mainframe. Given enough loops and runs, the skew became too large to ignore. This led to some serious finger pointing and head scratching from de devs. They found the root cause but, like, 2 months after they started looking. Also there is the banker's rounding. https://www.eecis.udel.edu/~breech/contest.inet.fall.07/problems/bankers-rounding.html Phil On Thu, Oct 27, 2016 at 11:15 AM, Guille Polito <[email protected]> wrote: > 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]>: > > >> >> >> >> 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 > > > > > > > > > >
