# [Pharo-project] SIXX problem for ScaledDecimal

Dario Trussardi dario.trussardi at tiscali.it
Fri May 20 18:49:05 CEST 2011

```But:

>
>>> 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
>
>

BUT :

(( 0.33333 asScaledDecimal: 5 )+  (0.33333 asScaledDecimal: 5 ) ) *6  3.99996s5

is right.

Dario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110520/ff7cbc5c/attachment.htm>
```