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
Hi José, On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com> 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
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 <sven@stfx.eu>:
Hi José,
On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com> 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
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 <jose.comesana@gmail.com>:
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 <sven@stfx.eu>:
Hi José,
On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com> 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
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 <jose.comesana@gmail.com>:
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 <jose.comesana@gmail.com>:
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 <sven@stfx.eu>:
Hi José,
On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com> 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
On 02 Jun 2014, at 02:06, José Comesaña <jose.comesana@gmail.com> 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 <jose.comesana@gmail.com>: 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 <jose.comesana@gmail.com>:
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 <sven@stfx.eu>:
Hi José,
On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com> 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
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 <jose.comesana@gmail.com> 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 <jose.comesana@gmail.com>: 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 <sven@stfx.eu>:
Hi José,
On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com> 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
Hi Sven 2014-06-02 12:59 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
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
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 <sven@stfx.eu <mailto:sven@stfx.eu>>:
Hi José,
On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com <mailto:jose.comesana@gmail.com>> 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:jtuchel@objektfabrik.de 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
On 02 Jun 2014, at 09:34, jtuchel@objektfabrik.de 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 <sven@stfx.eu>: Hi José,
On 31 May 2014, at 01:32, José Comesaña <jose.comesana@gmail.com> 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:jtuchel@objektfabrik.de
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
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:jtuchel@objektfabrik.de 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
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 jtuchel@objektfabrik.de:
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:jtuchel@objektfabrik.de 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
Sorry, I'm trying to do too many things at the same time... Am 02.06.14 13:40, schrieb jtuchel@objektfabrik.de:
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 jtuchel@objektfabrik.de:
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:jtuchel@objektfabrik.de 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
participants (3)
-
José Comesaña -
jtuchel＠objektfabrik.de -
Sven Van Caekenberghe