But:
> >>> From: Chris Cunningham <[email protected]> >>> Subject: Re: [Pharo-project] SIXX problem for ScaledDecimal >>> To: [email protected] >>> Message-ID: <[email protected]> >>> 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
