Re: [Pharo-project] SIXX problem for ScaledDecimal
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
Il giorno 20/mag/2011, alle ore 16.57, Ralph Boland ha scritto:
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
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
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
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
But:
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
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
2011/5/20 Dario Trussardi <dario.trussardi@tiscali.it>:
But:
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
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
I don't know what ScaledDecimal expectations are or should be. By now, you are in charge or performing the rounding operation by yourself ( (1/3) asScaledDecimal: 2) roundTo: 0.01s2. We may add more convenient #roundToPrecision, and #roundToPrecision: But you could also truncate, fllor or ceil... Nicolas 2011/5/20 Ralph Boland <rpboland@gmail.com>:
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
On Fri, May 20, 2011 at 7:57 AM, Ralph Boland <rpboland@gmail.com> wrote:
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?
I am not a financial expert, but this is how ScaledDecimal works, in both Squeak/Pharo and I believe other implementations, too. I did run into this previously and it bugged me enough that I created FixedDecimal (at http://www.squeaksource.com/FixedDecimal.html ). It does not keep an internal more precise number - it keeps exactly what it shows you. (Although the implementation is somewhat odd - it does do what it is supposed to do.) -Chris
No, no, no. Don't use Float. Float are INEXACT
(( 0.33333 asScaledDecimal: 5 )+ (0.33333 asScaledDecimal: 5 ) ) *6 = 3.99996s5 -> FALSE !
Nicolas
I don't know what ScaledDecimal expectations are or should be. By now, you are in charge or performing the rounding operation by yourself
( (1/3) asScaledDecimal: 2) roundTo: 0.01s2.
We may add more convenient #roundToPrecision, and #roundToPrecision: But you could also truncate, fllor or ceil...
Nicolas
On Fri, May 20, 2011 at 7:57 AM, Ralph Boland <rpboland@gmail.com> wrote:
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?
I am not a financial expert, but this is how ScaledDecimal works, in both Squeak/Pharo and I believe other implementations, too.
I did run into this previously and it bugged me enough that I created FixedDecimal (at http://www.squeaksource.com/FixedDecimal.html ). It does not keep an internal more precise number - it keeps exactly what it shows you. (Although the implementation is somewhat odd - it does do what it is supposed to do.)
-Chris
After Your considerations i do this conclusion for manage ScaledDecimal instance with SIXX. 1) the instance reference into the SIXX declaration is based on the ScaledDecimal notation : 1234.333s3 '<sixx.object sixx.id="0" sixx.type="ScaledDecimal" >1234.333s3</sixx.object> ' 2) All the translation is based on it. Other think is the internal ScaledDecimal represent. It's important to rounding the data so that the numerator and denominator are integer. I do it wtih method : roundToPrecision: scalePrecision | rnd | rnd:= ScaledDecimal new setNumerator: 1 denominator: (10 raisedTo: scalePrecision) scale: scalePrecision. ^self roundTo: rnd The round is automatic when i create ScaledDecimal instance with: fromString: aString For example when converter a input string to ScaledDecimal instance based on number of digit typed. It's required when i do conversion from another Number type: ( 1/3 asScaledDecimal: 3 ) roundToPrecision It's all for now. Any pointers would be greatly appreciated ! Thanks, Dario
participants (4)
-
Chris Cunningham -
Dario Trussardi -
Nicolas Cellier -
Ralph Boland