From: Chris Cunningham <cunningham.cb@gmail.com>

Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal

To: Pharo-project@lists.gforge.inria.fr

Message-ID: <BANLkTinP7E_oh2Fi2=axmra6JsoXVJYWkg@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