SIXX problem for ScaledDecimal

> Hi,
>
>        i found some problem into Gemstone relative to   SIXX support for manage ScaledDecimal instances.
>
>
>        I do some test into Pharo and i found error when i read the sixx declaration relative to ScaledDecimal :
>
>                <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object>
>
>
>        For solve this error i define the ScaledDecimal :
>
>                readSixxContentStringFrom: aStream
>
>
>                        | numerator scale |
>
>                        numerator := aStream upTo: $s .
>
>                        scale := aStream upToEnd.
>
>
>                        ^ self newFromNumber:  numerator asNumber scale: scale asNumber
>
>
> Now my doubt is relative to string size and performance.
>
> A)      If i write
>
>                <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object>
>
>
>        i have small string in sixx declartion but when create a ScaledDecimal from sixx the system execute the:
>
>                newFromNumber: aNumber scale: anInteger
>                        | aFraction |
>                        aFraction := aNumber asFraction.
>                        ^aFraction isFraction
>                        ifTrue: [self new setNumerator: aFraction numerator denominator: aFraction denominator scale: anInteger]
>                        ifFalse: [self new setNumerator: aFraction denominator: 1 scale: anInteger]
>
>
>        What is the performance relative to :                   aFraction := aFloat asFraction.    ????
>
>
>
>
> B)      The alternative is to write a sixx declaration with:
>
>                <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >(8687443681197687/70368744177664s3)</sixx.object>
>
>
>        in this case the sixx string is big but the ScaledDecimal instance creation is direct:
>
>
>                readSixxContentStringFromA: aStream
>
>                        " with numerator and denominator "
>                | numerator denominator scale |
>                aStream next. "skip $("
>                numerator := aStream upTo: $/ .
>                denominator := aStream upTo: $s.
>                scale := aStream upTo: $).
>
>                ^ self new setNumerator:  numerator asNumber denominator: denominator asNumber scale:  scale asNumber
>
>
>
> Any pointers would be greatly appreciated !
>
>        Thanks,
>
>                Dario
>
>
>
>

> Hi,
>
>        i found some problem into Gemstone relative to   SIXX support for manage ScaledDecimal instances.
>
>
>        I do some test into Pharo and i found error when i read the sixx declaration relative to ScaledDecimal :
>
>                <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object>
>
>
>        For solve this error i define the ScaledDecimal :
>
>                readSixxContentStringFrom: aStream
>
>
>                        | numerator scale |
>
>                        numerator := aStream upTo: $s .
>
>                        scale := aStream upToEnd.
>
>
>                        ^ self newFromNumber:  numerator asNumber scale: scale asNumber
>
>
> Now my doubt is relative to string size and performance.
>
> A)      If i write
>
>                <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >123.456s3</sixx.object>
>
>
>        i have small string in sixx declartion but when create a ScaledDecimal from sixx the system execute the:
>
>                newFromNumber: aNumber scale: anInteger
>                        | aFraction |
>                        aFraction := aNumber asFraction.
>                        ^aFraction isFraction
>                        ifTrue: [self new setNumerator: aFraction numerator denominator: aFraction denominator scale: anInteger]
>                        ifFalse: [self new setNumerator: aFraction denominator: 1 scale: anInteger]
>
>
>        What is the performance relative to :                   aFraction := aFloat asFraction.    ????
>
>

>
>
> B)      The alternative is to write a sixx declaration with:
>
>                <sixx.object sixx.id="0" sixx.type="ScaledDecimal" >(8687443681197687/70368744177664s3)</sixx.object>
>
>
>        in this case the sixx string is big but the ScaledDecimal instance creation is direct:
>
>
>                readSixxContentStringFromA: aStream
>
>                        " with numerator and denominator "
>                | numerator denominator scale |
>                aStream next. "skip $("
>                numerator := aStream upTo: $/ .
>                denominator := aStream upTo: $s.
>                scale := aStream upTo: $).
>
>                ^ self new setNumerator:  numerator asNumber denominator: denominator asNumber scale:  scale asNumber
>
>
>
> Any pointers would be greatly appreciated !
>
>        Thanks,
>
>                Dario
>
>
>
>

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

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

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