[Pharo-project] SIXX problem for ScaledDecimal

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri May 20 19:32:14 CEST 2011


2011/5/20 Dario Trussardi <dario.trussardi at tiscali.it>:
> 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
>
>

No, no, no.
Don't use Float.
Float are INEXACT

(( 0.33333 asScaledDecimal: 5 )+  (0.33333 asScaledDecimal: 5 ) ) *6 = 3.99996s5
  -> FALSE !

Nicolas



More information about the Pharo-project mailing list