Smalltalk › Pharo › Pharo Smalltalk Users

STON on ScaledDecimal?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

José Comesaña

STON on ScaledDecimal?

Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.

Regards

jtuchel

Re: STON on ScaledDecimal?

Hi,

Sounds good. But I think the Scale should be streamed as well: 12345.678s3

Joachim

José Comesaña <[hidden email]> schrieb:

Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.

Regards

José Comesaña

Re: STON on ScaledDecimal?

Oh, sorry, I forgot to write it. And Fraction as well. I have added it for my own use.

Regards

José

2014-05-31 6:13 GMT+02:00 Joachim Tuchel <[hidden email]>:

Hi,

Sounds good. But I think the Scale should be streamed as well: 12345.678s3

Joachim

José Comesaña <[hidden email]> schrieb:

Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.

Regards

Sven Van Caekenberghe-2

Re: STON on ScaledDecimal?

In reply to this post by José Comesaña

Hi José,

On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:

> Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
>
> Regards

That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.

One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?

I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?

Sven

José Comesaña

Re: STON on ScaledDecimal?

Hi Sven.

First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain.

There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo.

I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start.

You can see here the changes I have made to STONReader >>#parseNumber:

parseNumber

| negated number |

negated := readStream peekFor: $-.

number := self parseNumberInteger.

(readStream peekFor: $.)

ifTrue: [ number := number + self parseNumberFraction ].

" -------------- New from here -------------- "

(readStream peekFor: $s)

ifTrue: [ | scale |

scale := self parseNumberInteger.

number := ScaledDecimal newFromNumber: number scale: scale ].

(readStream peekFor: $/)

ifTrue: [ | denominator |

denominator := self parseNumberInteger.

number := Fraction numerator: number denominator: denominator ].

" -------------- to here -------------- "

((readStream peekFor: $e) or: [ readStream peekFor: $E ])

ifTrue: [ number := number * self parseNumberExponent ].

negated

ifTrue: [ number := number negated ].

self consumeWhitespace.

^ number

I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things.

I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition:

readStream atEnd not and: [ readStream peek isDigit ]

why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do:

number := Number readFromString: tmpString

That way, we would have a "native" parsing in each language

Hope this helps. If someone needs more information, pleas ask.

Best regards

2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

Hi José,

On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:

> Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
>
> Regards

That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.

One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?

I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?

Sven

José Comesaña

Re: STON on ScaledDecimal?

And this is an improved version. More changes to avoid parsing weird things as 123.456s3e2 (it could be improved, for sure, but I don't have any more time...)

parseNumber

| negated number |

negated := readStream peekFor: $-.

number := self parseNumberInteger.

(readStream peekFor: $.)

ifTrue: [ number := number + self parseNumberFraction ].

(readStream peekFor: $s)

ifTrue: [ | scale |

scale := self parseNumberInteger.

number := ScaledDecimal newFromNumber: number scale: scale ]

ifFalse: [

(readStream peekFor: $/)

ifTrue: [ | denominator |

denominator := self parseNumberInteger.

number := Fraction numerator: number denominator: denominator ]

ifFalse: [

((readStream peekFor: $e) or: [ readStream peekFor: $E ])

ifTrue: [ number := number * self parseNumberExponent ].

]

negated

ifTrue: [ number := number negated ].

self consumeWhitespace.

^ number

2014-06-02 1:51 GMT+02:00 José Comesaña <[hidden email]>:

Hi Sven.

First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain.

There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo.

I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start.

You can see here the changes I have made to STONReader >>#parseNumber:

parseNumber
| negated number |
negated := readStream peekFor: $-.
number := self parseNumberInteger.
(readStream peekFor: $.)

ifTrue: [ number := number + self parseNumberFraction ].
" -------------- New from here -------------- "

(readStream peekFor: $s)
ifTrue: [ | scale |
scale := self parseNumberInteger.

number := ScaledDecimal newFromNumber: number scale: scale ].
(readStream peekFor: $/)
ifTrue: [ | denominator |

denominator := self parseNumberInteger.
number := Fraction numerator: number denominator: denominator ].

" -------------- to here -------------- "
((readStream peekFor: $e) or: [ readStream peekFor: $E ])

ifTrue: [ number := number * self parseNumberExponent ].
negated
ifTrue: [ number := number negated ].

self consumeWhitespace.
^ number

I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things.

I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition:

readStream atEnd not and: [ readStream peek isDigit ]

why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do:

number := Number readFromString: tmpString

That way, we would have a "native" parsing in each language

Hope this helps. If someone needs more information, pleas ask.

Best regards

2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

Hi José,

On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:

> Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
>
> Regards

That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.

One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?

I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?

Sven

José Comesaña

Re: STON on ScaledDecimal?

One last thing. If you do:

sd := STON fromString: '1345.76s2'.

sd2 := ScaledDecimal readFromString: '1345.76s2'.

you can note that sd = sd2 returns false, and that sd - sd2 returns 0.00s2. Both numbers are different in the order of precision, because the first has numerator 5918715072783319 and denominator 4398046511104 and the second has numerator 33644 and denominator 25. I still have to fix this.

Hope not to bore you too much.

Regards

2014-06-02 1:56 GMT+02:00 José Comesaña <[hidden email]>:

And this is an improved version. More changes to avoid parsing weird things as 123.456s3e2 (it could be improved, for sure, but I don't have any more time...)

parseNumber
| negated number |
negated := readStream peekFor: $-.
number := self parseNumberInteger.

(readStream peekFor: $.)
ifTrue: [ number := number + self parseNumberFraction ].
(readStream peekFor: $s)

ifTrue: [ | scale |
scale := self parseNumberInteger.
number := ScaledDecimal newFromNumber: number scale: scale ]

ifFalse: [
(readStream peekFor: $/)
ifTrue: [ | denominator |

denominator := self parseNumberInteger.
number := Fraction numerator: number denominator: denominator ]

ifFalse: [
((readStream peekFor: $e) or: [ readStream peekFor: $E ])
ifTrue: [ number := number * self parseNumberExponent ].

]
].
negated
ifTrue: [ number := number negated ].

self consumeWhitespace.
^ number

2014-06-02 1:51 GMT+02:00 José Comesaña <[hidden email]>:

Hi Sven.

First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain.

There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo.

I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start.

You can see here the changes I have made to STONReader >>#parseNumber:

parseNumber
| negated number |
negated := readStream peekFor: $-.
number := self parseNumberInteger.
(readStream peekFor: $.)

ifTrue: [ number := number + self parseNumberFraction ].
" -------------- New from here -------------- "

(readStream peekFor: $s)
ifTrue: [ | scale |
scale := self parseNumberInteger.

number := ScaledDecimal newFromNumber: number scale: scale ].
(readStream peekFor: $/)
ifTrue: [ | denominator |

denominator := self parseNumberInteger.
number := Fraction numerator: number denominator: denominator ].

" -------------- to here -------------- "
((readStream peekFor: $e) or: [ readStream peekFor: $E ])

ifTrue: [ number := number * self parseNumberExponent ].
negated
ifTrue: [ number := number negated ].

self consumeWhitespace.
^ number

I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things.

I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition:

readStream atEnd not and: [ readStream peek isDigit ]

why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do:

number := Number readFromString: tmpString

That way, we would have a "native" parsing in each language

Hope this helps. If someone needs more information, pleas ask.

Best regards

2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

Hi José,

On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:

> Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
>
> Regards

That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.

One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?

I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?

Sven

jtuchel

Re: STON on ScaledDecimal?

In reply to this post by José Comesaña

Hi,

VA Smalltalk comes with ScaledDecimal, and as far as I know, it always print out the scale of a number, because it could be something like 0.5s3. And I'd guess ScaledDecimal or FixedPoint are pretty common, because the use of this class has been encouraged for the modelling of monetary amounts for decades now.

Joachim

Am 02.06.14 01:51, schrieb José Comesaña:

Hi Sven.

First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain.

There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo.

I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start.

You can see here the changes I have made to STONReader >>#parseNumber:

parseNumber

| negated number |

negated := readStream peekFor: $-.

number := self parseNumberInteger.

(readStream peekFor: $.)

ifTrue: [ number := number + self parseNumberFraction ].

" -------------- New from here -------------- "

(readStream peekFor: $s)

ifTrue: [ | scale |

scale := self parseNumberInteger.

number := ScaledDecimal newFromNumber: number scale: scale ].

(readStream peekFor: $/)

ifTrue: [ | denominator |

denominator := self parseNumberInteger.

number := Fraction numerator: number denominator: denominator ].

" -------------- to here -------------- "

((readStream peekFor: $e) or: [ readStream peekFor: $E ])

ifTrue: [ number := number * self parseNumberExponent ].

negated

ifTrue: [ number := number negated ].

self consumeWhitespace.

^ number

I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things.

I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition:

readStream atEnd not and: [ readStream peek isDigit ]

why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do:

number := Number readFromString: tmpString

That way, we would have a "native" parsing in each language

Hope this helps. If someone needs more information, pleas ask.

Best regards

2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

Hi José,

On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:

> Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
>
> Regards

That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.

One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?

I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?

Sven

-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

Sven Van Caekenberghe-2

Re: STON on ScaledDecimal?

In reply to this post by José Comesaña

Hi José,

Thanks for your feedback, suggestions and code. I incorporated a slightly changed version (fixing the precision issue; you also did not provided the necessary changes to support writing Fractions and ScaledDecimals). I also added some unit tests.

In #bleedingEdge:

===
Name: STON-Core-SvenVanCaekenberghe.50
Author: SvenVanCaekenberghe
Time: 2 June 2014, 12:52:39.808591 pm
UUID: ce24c992-4f32-4f3a-8853-a4a9cf55c453
Ancestors: STON-Core-SvenVanCaekenberghe.49

Add support for Fractions and ScaledDecimals as primitive numbers (thx José Comesaña):

- add Fraction>>#stonOn: delegating to STONWriter>>#writeFraction:
- add ScaledDecimal>>#stonOn: delegating to STONWriter>>#writeScaledDecimal:
- extended STONReader>>#parseNumber to allow / and s notations
- changed STONReader>>#parseNumberFraction to return pure Fractions as required by ScaledDecimal
===
Name: STON-Tests-SvenVanCaekenberghe.45
Author: SvenVanCaekenberghe
Time: 2 June 2014, 12:53:39.436939 pm
UUID: bf7a8e27-4b7b-4a0e-b517-6321c1da1694
Ancestors: STON-Tests-SvenVanCaekenberghe.44

Add support for Fractions and ScaledDecimals as primitive numbers (thx José Comesaña).

Added specific tests for Fractions and ScaledDecimals
===

Please let me know if this works for you.

Regards,

Sven

On 02 Jun 2014, at 01:56, José Comesaña <[hidden email]> wrote:

> And this is an improved version. More changes to avoid parsing weird things as 123.456s3e2 (it could be improved, for sure, but I don't have any more time...)
>
> parseNumber
> | negated number |
> negated := readStream peekFor: $-.
> number := self parseNumberInteger.
> (readStream peekFor: $.)
> ifTrue: [ number := number + self parseNumberFraction ].
> (readStream peekFor: $s)
> ifTrue: [ | scale |
> scale := self parseNumberInteger.
> number := ScaledDecimal newFromNumber: number scale: scale ]
> ifFalse: [
> (readStream peekFor: $/)
> ifTrue: [ | denominator |
> denominator := self parseNumberInteger.
> number := Fraction numerator: number denominator: denominator ]
> ifFalse: [
> ((readStream peekFor: $e) or: [ readStream peekFor: $E ])
> ifTrue: [ number := number * self parseNumberExponent ].
> ]
> ].
> negated
> ifTrue: [ number := number negated ].
> self consumeWhitespace.
> ^ number
>
>
> 2014-06-02 1:51 GMT+02:00 José Comesaña <[hidden email]>:
> Hi Sven.
>
> First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain.
>
> There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo.
>
> I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start.
>
> You can see here the changes I have made to STONReader >>#parseNumber:
>
> parseNumber
> | negated number |
> negated := readStream peekFor: $-.
> number := self parseNumberInteger.
> (readStream peekFor: $.)
> ifTrue: [ number := number + self parseNumberFraction ].
> " -------------- New from here -------------- "
> (readStream peekFor: $s)
> ifTrue: [ | scale |
> scale := self parseNumberInteger.
> number := ScaledDecimal newFromNumber: number scale: scale ].
> (readStream peekFor: $/)
> ifTrue: [ | denominator |
> denominator := self parseNumberInteger.
> number := Fraction numerator: number denominator: denominator ].
> " -------------- to here -------------- "
> ((readStream peekFor: $e) or: [ readStream peekFor: $E ])
> ifTrue: [ number := number * self parseNumberExponent ].
> negated
> ifTrue: [ number := number negated ].
> self consumeWhitespace.
> ^ number
>
> I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things.
>
> I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition:
>
> readStream atEnd not and: [ readStream peek isDigit ]
>
> why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do:
>
> number := Number readFromString: tmpString
>
> That way, we would have a "native" parsing in each language
>
> Hope this helps. If someone needs more information, pleas ask.
>
> Best regards
>
>
>
> 2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
>
> Hi José,
>
> On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:
>
> > Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
> >
> > Regards
>
> That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.
>
> One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?
>
> I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?
>
> Sven
>
>

Sven Van Caekenberghe-2

Re: STON on ScaledDecimal?

In reply to this post by José Comesaña

On 02 Jun 2014, at 02:06, José Comesaña <[hidden email]> wrote:

> One last thing. If you do:
>
> sd := STON fromString: '1345.76s2'.
> sd2 := ScaledDecimal readFromString: '1345.76s2'.
>
> you can note that sd = sd2 returns false, and that sd - sd2 returns 0.00s2. Both numbers are different in the order of precision, because the first has numerator 5918715072783319 and denominator 4398046511104 and the second has numerator 33644 and denominator 25. I still have to fix this.

The problem was that #parseNumberFraction returned a Float which let to reduced precision when creating the ScaledDecimal. Now it returns a pure/precise Fraction, with Float conversion happening later, if necessary.

> Hope not to bore you too much.

No, you do not ;-)

> Regards
>
>
>
> 2014-06-02 1:56 GMT+02:00 José Comesaña <[hidden email]>:
> And this is an improved version. More changes to avoid parsing weird things as 123.456s3e2 (it could be improved, for sure, but I don't have any more time...)
>
> parseNumber
> | negated number |
> negated := readStream peekFor: $-.
> number := self parseNumberInteger.
> (readStream peekFor: $.)
> ifTrue: [ number := number + self parseNumberFraction ].
> (readStream peekFor: $s)
> ifTrue: [ | scale |
> scale := self parseNumberInteger.
> number := ScaledDecimal newFromNumber: number scale: scale ]
> ifFalse: [
> (readStream peekFor: $/)
> ifTrue: [ | denominator |
> denominator := self parseNumberInteger.
> number := Fraction numerator: number denominator: denominator ]
> ifFalse: [
> ((readStream peekFor: $e) or: [ readStream peekFor: $E ])
> ifTrue: [ number := number * self parseNumberExponent ].
> ]
> ].
> negated
> ifTrue: [ number := number negated ].
> self consumeWhitespace.
> ^ number
>
>
> 2014-06-02 1:51 GMT+02:00 José Comesaña <[hidden email]>:
>
> Hi Sven.
>
> First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain.
>
> There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo.
>
> I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start.
>
> You can see here the changes I have made to STONReader >>#parseNumber:
>
> parseNumber
> | negated number |
> negated := readStream peekFor: $-.
> number := self parseNumberInteger.
> (readStream peekFor: $.)
> ifTrue: [ number := number + self parseNumberFraction ].
> " -------------- New from here -------------- "
> (readStream peekFor: $s)
> ifTrue: [ | scale |
> scale := self parseNumberInteger.
> number := ScaledDecimal newFromNumber: number scale: scale ].
> (readStream peekFor: $/)
> ifTrue: [ | denominator |
> denominator := self parseNumberInteger.
> number := Fraction numerator: number denominator: denominator ].
> " -------------- to here -------------- "
> ((readStream peekFor: $e) or: [ readStream peekFor: $E ])
> ifTrue: [ number := number * self parseNumberExponent ].
> negated
> ifTrue: [ number := number negated ].
> self consumeWhitespace.
> ^ number
>
> I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things.
>
> I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition:
>
> readStream atEnd not and: [ readStream peek isDigit ]
>
> why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do:
>
> number := Number readFromString: tmpString
>
> That way, we would have a "native" parsing in each language
>
> Hope this helps. If someone needs more information, pleas ask.
>
> Best regards
>
>
>
> 2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
>
> Hi José,
>
> On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:
>
> > Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
> >
> > Regards
>
> That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.
>
> One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?
>
> I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?
>
> Sven
>
>
>

Sven Van Caekenberghe-2

Re: STON on ScaledDecimal?

In reply to this post by jtuchel

On 02 Jun 2014, at 09:34, [hidden email] wrote:

> Hi,
>
> VA Smalltalk comes with ScaledDecimal, and as far as I know, it always print out the scale of a number, because it could be something like 0.5s3. And I'd guess ScaledDecimal or FixedPoint are pretty common, because the use of this class has been encouraged for the modelling of monetary amounts for decades now.

Yes, I realise it is important in some contexts, that is why I added it now.

Apart from the class name, another issue is that 0.5s3 prints as 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere.

> Joachim
>
> Am 02.06.14 01:51, schrieb José Comesaña:
>> Hi Sven.
>>
>> First of all, I know that in VisualWorks there exists a class called FixedPoint, that is (more or less) similar to ScaledDecimal (is what the class comment says). But, instead of 123.45s2, VWs writes 123.45s. NEVERTHELESS, it can read 123.45s2 with no pain.
>>
>> There exists a Fraction type also in VW, which, I believe, uses the same notation as in Pharo.
>>
>> I know that portability is an important issue, but, at least for me, portability from Pharo to Pharo is the most important. I depend on ScaledDecimal for an application (for storing money values -changing the storage mode is not an option now-) and need the possibility of converting it to string and reading it back. The string version is my database, that gets loaded into memory upon program start.
>>
>> You can see here the changes I have made to STONReader >>#parseNumber:
>>
>> parseNumber
>> | negated number |
>> negated := readStream peekFor: $-.
>> number := self parseNumberInteger.
>> (readStream peekFor: $.)
>> ifTrue: [ number := number + self parseNumberFraction ].
>> " --------------
>> New from here
>> --------------
>> "
>>
>> (readStream peekFor: $s)
>> ifTrue: [ | scale |
>> scale := self parseNumberInteger.
>> number := ScaledDecimal newFromNumber: number scale: scale ].
>> (readStream peekFor: $/)
>> ifTrue: [ | denominator |
>> denominator := self parseNumberInteger.
>> number := Fraction numerator: number denominator: denominator ].
>> " --------------
>> to here
>> --------------
>> "
>>
>> ((readStream peekFor: $e) or: [ readStream peekFor: $E ])
>> ifTrue: [ number := number * self parseNumberExponent ].
>> negated
>> ifTrue: [ number := number negated ].
>> self consumeWhitespace.
>> ^ number
>>
>> I am a newbie about STON. I don't know if it is correct, but it works for me, at least for some tests I have made. I know it needs improvements, thinking about strange strings we could receive. But I trust the writer not to create such weird things.
>>
>> I could suggest another way of making the function of parseNumber (OK, OK, I know I am thinking from a Pharo-only perspective...). Seeing that number parsing always ends with this condition:
>>
>> readStream atEnd not and: [ readStream peek isDigit ]
>>
>> why not create a temporary string (including possibility of $e, $s, $/, even $@ ...) to that point (tmpString) and do:
>>
>> number := Number readFromString: tmpString
>>
>> That way, we would have a "native" parsing in each language
>>
>> Hope this helps. If someone needs more information, pleas ask.
>>
>> Best regards
>>
>>
>>
>> 2014-05-31 21:29 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
>> Hi José,
>>
>> On 31 May 2014, at 01:32, José Comesaña <[hidden email]> wrote:
>>
>> > Wouldn't it be good if STON could save ScaledDecimals as 12345.678s?. That way, we could read them back again as ScaledDecimal, instead of Float. I have tried and it seems quite useful.
>> >
>> > Regards
>>
>> That is an interesting idea and it is probably nice to have for those relying on ScaledDecimals.
>>
>> One of the ideas of STON is to be portable across dialects, so I am wondering if ScaledDecimals exists everywhere ?
>>
>> I am curious as to how you did it though, since STONReader basically contains its own number parser. Could you share your code ?
>>
>> Sven
>>
>
>
> --
> -----------------------------------------------------------------------
> Objektfabrik Joachim Tuchel
> mailto:[hidden email]
>
> Fliederweg 1
> http://www.objektfabrik.de
>
> D-71640 Ludwigsburg
> http://joachimtuchel.wordpress.com
>
> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>
>

jtuchel

Re: STON on ScaledDecimal?

Am 02.06.14 13:03, schrieb Sven Van Caekenberghe:
> Apart from the class name, another issue is that 0.5s3 prints as
> 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere.

Hmm, that looks strange to me. If you DisplayIt a 0.5s3 in VAST, you get
0.5. If you inspect it, it is debugPrint'ed as 0.5s3.
I would tend to say that Pharo's display string is strange, not
necessarily incorrect. I don't have access to the ANSI standard, but I
guess the fact that there is the s3 already, which says there are 3
digits in the fraction part, alrady says enough.

Pharo does parse 0.5s3 correctly, so it can probably juist be accepted
as a harmless weirdness. VAST, otoh, also parses 0.500s3 correctly, so
it seems there is no harm done in exchange between VAST and Pharo. Not
sure about VW, however.

Another question: doesn't creating a fraction when you parse a
ScaledDecimal make life a bit harder than it should be in terms of CPU
cycles burnt? Not that this matters for a few hundred or thousand
numbers, but it might for large files.... Precision-wise there is no
gain in it, right?

Joachim

--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:[hidden email]
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

jtuchel

Re: STON on ScaledDecimal?

Okay, here we go ;-)

VisualWorks also prints the trailing zeros. So maybe the weirdness lies
on the VAST side ;-)
VisualWorks also prints the ScaledDecimal without its scale.
It does parse all three correctly: 0.500s3 0.5s3 0.500

Joachim

Am 02.06.14 13:35, schrieb [hidden email]:

>
>
> Am 02.06.14 13:03, schrieb Sven Van Caekenberghe:
>> Apart from the class name, another issue is that 0.5s3 prints as
>> 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere.
>
> Hmm, that looks strange to me. If you DisplayIt a 0.5s3 in VAST, you
> get 0.5. If you inspect it, it is debugPrint'ed as 0.5s3.
> I would tend to say that Pharo's display string is strange, not
> necessarily incorrect. I don't have access to the ANSI standard, but I
> guess the fact that there is the s3 already, which says there are 3
> digits in the fraction part, alrady says enough.
>
> Pharo does parse 0.5s3 correctly, so it can probably juist be accepted
> as a harmless weirdness. VAST, otoh, also parses 0.500s3 correctly, so
> it seems there is no harm done in exchange between VAST and Pharo. Not
> sure about VW, however.
>
> Another question: doesn't creating a fraction when you parse a
> ScaledDecimal make life a bit harder than it should be in terms of CPU
> cycles burnt? Not that this matters for a few hundred or thousand
> numbers, but it might for large files.... Precision-wise there is no
> gain in it, right?
>
> Joachim
>
>
>

--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:[hidden email]
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

jtuchel

Re: STON on ScaledDecimal?

Sorry, I'm trying to do too many things at the same time...

Am 02.06.14 13:40, schrieb [hidden email]:
> Okay, here we go ;-)
>
> VisualWorks also prints the trailing zeros. So maybe the weirdness
> lies on the VAST side ;-)
> VisualWorks also prints the ScaledDecimal without its scale.
it prints FixedPoint, not ScaledDecimal...
> It does parse all three correctly: 0.500s3 0.5s3 0.500
the last one should be 0.500s

>
> Joachim
>
>
>
>
> Am 02.06.14 13:35, schrieb [hidden email]:
>>
>>
>> Am 02.06.14 13:03, schrieb Sven Van Caekenberghe:
>>> Apart from the class name, another issue is that 0.5s3 prints as
>>> 0.500s3 in Pharo, the trailing zeros are possibly not added everywhere.
>>
>> Hmm, that looks strange to me. If you DisplayIt a 0.5s3 in VAST, you
>> get 0.5. If you inspect it, it is debugPrint'ed as 0.5s3.
>> I would tend to say that Pharo's display string is strange, not
>> necessarily incorrect. I don't have access to the ANSI standard, but
>> I guess the fact that there is the s3 already, which says there are 3
>> digits in the fraction part, alrady says enough.
>>
>> Pharo does parse 0.5s3 correctly, so it can probably juist be
>> accepted as a harmless weirdness. VAST, otoh, also parses 0.500s3
>> correctly, so it seems there is no harm done in exchange between VAST
>> and Pharo. Not sure about VW, however.
>>
>> Another question: doesn't creating a fraction when you parse a
>> ScaledDecimal make life a bit harder than it should be in terms of
>> CPU cycles burnt? Not that this matters for a few hundred or thousand
>> numbers, but it might for large files.... Precision-wise there is no
>> gain in it, right?
>>
>> Joachim
>>
>>
>>
>
>

José Comesaña

Re: STON on ScaledDecimal?

In reply to this post by Sven Van Caekenberghe-2

Hi Sven

2014-06-02 12:59 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

Hi José,

Thanks for your feedback, suggestions and code. I incorporated a slightly changed version (fixing the precision issue; you also did not provided the necessary changes to support writing Fractions and ScaledDecimals). I also added some unit tests.

Oh, yes, sorry, too late at night, I forgot to paste them, :)

In #bleedingEdge:

===
Name: STON-Core-SvenVanCaekenberghe.50
Author: SvenVanCaekenberghe
Time: 2 June 2014, 12:52:39.808591 pm
UUID: ce24c992-4f32-4f3a-8853-a4a9cf55c453
Ancestors: STON-Core-SvenVanCaekenberghe.49

Add support for Fractions and ScaledDecimals as primitive numbers (thx José Comesaña):

- add Fraction>>#stonOn: delegating to STONWriter>>#writeFraction:
- add ScaledDecimal>>#stonOn: delegating to STONWriter>>#writeScaledDecimal:
- extended STONReader>>#parseNumber to allow / and s notations
- changed STONReader>>#parseNumberFraction to return pure Fractions as required by ScaledDecimal
===
Name: STON-Tests-SvenVanCaekenberghe.45
Author: SvenVanCaekenberghe
Time: 2 June 2014, 12:53:39.436939 pm
UUID: bf7a8e27-4b7b-4a0e-b517-6321c1da1694
Ancestors: STON-Tests-SvenVanCaekenberghe.44

Add support for Fractions and ScaledDecimals as primitive numbers (thx José Comesaña).

Added specific tests for Fractions and ScaledDecimals
===

Please let me know if this works for you.

Regards,

Sven

Thank you very much for yor good work. It find it very useful. I have my on #toXml and #fromXml versions, but I think I will change to STON.

Regards

José Comesaña