[Pharo-project] SIXX problem for ScaledDecimal
Dario Trussardi
dario.trussardi at tiscali.it
Fri May 20 12:32:00 EDT 2011
Il giorno 20/mag/2011, alle ore 16.57, Ralph Boland ha scritto:
>> From: Chris Cunningham <cunningham.cb at gmail.com>
>> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal
>> To: Pharo-project at lists.gforge.inria.fr
>> Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>
>> For ScaledDecimal, SIXX should definite store it as the underlying
>> fraction. Storing it in the printed fashion does change the value of
>> the ScaledDecimal.
>
>> (1/3) asScaledDecimal: 2 gives 0.33s2
>> and
>> (33/100) asScaledDecimal: 2 gives 0.33s2
>> yet
>> 0.33s2 ~= ( (1/3) asScaledDecimal: 2 )
>> and
>> ( (1/3) asScaledDecimal: 2 ) ~= ( (33/100) asScaledDecimal: 2 )
>
>> In other words, the ScaledDecimal is about the precise internal number
>> and the scale to display it - which is NOT the scale that it is stored
>> as.
>
>> -Chris
>
> I don't agree. ScaledDecimal would be used where consistency is often
> more important than accuracy, e.g. in Financial calculations where being off by
> a few pennies doesn't matter but always getting the same answer matters a LOT.
> Once a number is converted to a ScaledDecimal computations must always
> produce the same result assuming enough digits. To ensure this asScaledDecimal
> must produce a scaled decimal for use in computations and, as such, storing
> a fraction internally is unacceptable.
> From a financial point of view 1/3 * 3 is not 1!
> From a programmers point of view asScaledDecimal changes the value
> in much the same way asInteger does for a float.
>
> Having said all of this allow me to contradict myself. It seems to me that
> a scaled decimal should in general store more digits than are displayed.
> For example money might be stored with a large (possibly arbitrary) number
> of digits after the decimal point but only display two digits beyond the decimal
> point.
> I don't know how ScaledDecimal is implemented but I would be inclined to
> use arbitrary or large size integers and store the location of the decimal point
> internally recomputing the position of the decimal point after each calculation.
> This is an expensive way of doing computations but I expect users of
> ScaledDecimal can live with that. When converting non decimal results to
> ScaledDecimal then how many digits of precision to maintain must be specified
> somehow.
> Dealing with ScaledDecimal is a complicated matter and I have probably failed
> to appreciate many of the complications but whoever is implementing
> ScaledDecimal
> (and Smalltalk needs ScaledDecimal) needs to appreciate those complications.
> Anybody here a financial expert?
>
> Ralph Boland
>
I think ScaledDecimal for financial data.
Where rounded is do only for the last of the operations. ( the total of the document for example or when i command it )
I do :
( ((1/3 asScaledDecimal:5 ) + (1/3 asScaledDecimal:5 )) * (6 asScaledDecimal:5) )
The result 4 is not right .
2/3 * 6 when management 5 decimal are :
0,66666 * 6,00000 = 3,99996
and not fraction 2/3 * 6/1 -> 12 / 3 - > 4
I'm surprised about it.
Any idea ?
Dario
More information about the Pharo-dev
mailing list