Floats problem with SIXX between Pharo and GemStone
Hi guys, When I export SmallDoubles with SIXX in GemStone it generates something like this: <sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble"
1.0000000000000000E-02</sixx.object>
This is because "0.01 asString" -> '1.0000000000000000E-02' Then I want to load this in Pharo. So first problem is that of course SmallDouble doesn't exist. So I did: aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. But then, SIXX use Float >> readFrom: aStream "Answer a new Float as described on the stream, aStream." ^(super readFrom: aStream) asFloat So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0 So my 0.01 in gemstone become 1.0 in Pharo.... Am I doing something wrong or this is expected? What is the best workaround? In GemStone I could print the SmallDouble in the XML with a method like Float >> xmlRepresentation ^ String streamContents: [:strm | self printOn: strm base: 10] Is this the correct approach? If true, I guess I should define: Float >> sixxContentOn: aStream indent: level context: dictionary aStream nextPutAll: self xmlRepresentation Thoughts? Thanks in advance, -- Mariano http://marianopeck.wordpress.com
That's exactly for this kind of reasons that I developped an ExtendedNumberParser connected to Number class>>readFrom:, to allow a variety of formats used in the rest of the world. It would have been easy to allow upper letter exponents in this parser, but the class was considered superfluous and removed from Pharo 3.0... 2014-02-26 22:38 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi guys,
When I export SmallDoubles with SIXX in GemStone it generates something like this:
<sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble"
1.0000000000000000E-02</sixx.object>
This is because "0.01 asString" -> '1.0000000000000000E-02'
Then I want to load this in Pharo. So first problem is that of course SmallDouble doesn't exist. So I did:
aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. But then, SIXX use Float >> readFrom: aStream "Answer a new Float as described on the stream, aStream." ^(super readFrom: aStream) asFloat
So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0
So my 0.01 in gemstone become 1.0 in Pharo....
Am I doing something wrong or this is expected? What is the best workaround?
In GemStone I could print the SmallDouble in the XML with a method like
Float >> xmlRepresentation ^ String streamContents: [:strm | self printOn: strm base: 10]
Is this the correct approach? If true, I guess I should define:
Float >> sixxContentOn: aStream indent: level context: dictionary aStream nextPutAll: self xmlRepresentation
Thoughts?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
2014-02-26 23:08 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
That's exactly for this kind of reasons that I developped an ExtendedNumberParser connected to Number class>>readFrom:, to allow a variety of formats used in the rest of the world.
It would have been easy to allow upper letter exponents in this parser, but the class was considered superfluous and removed from Pharo 3.0...
super easy is just redefine:
ExtendedNumberParser>>exponentLetters ^'edqEDQ' and then Float readFrom: '1.0000000000000000E-02' works as expected, that is in Squeak at least...
2014-02-26 22:38 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi guys,
When I export SmallDoubles with SIXX in GemStone it generates something like this:
<sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble"
1.0000000000000000E-02</sixx.object>
This is because "0.01 asString" -> '1.0000000000000000E-02'
Then I want to load this in Pharo. So first problem is that of course SmallDouble doesn't exist. So I did:
aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. But then, SIXX use Float >> readFrom: aStream "Answer a new Float as described on the stream, aStream." ^(super readFrom: aStream) asFloat
So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0
So my 0.01 in gemstone become 1.0 in Pharo....
Am I doing something wrong or this is expected? What is the best workaround?
In GemStone I could print the SmallDouble in the XML with a method like
Float >> xmlRepresentation ^ String streamContents: [:strm | self printOn: strm base: 10]
Is this the correct approach? If true, I guess I should define:
Float >> sixxContentOn: aStream indent: level context: dictionary aStream nextPutAll: self xmlRepresentation
Thoughts?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
On 26 Feb 2014, at 23:08, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
That's exactly for this kind of reasons that I developped an ExtendedNumberParser connected to Number class>>readFrom:, to allow a variety of formats used in the rest of the world.
It would have been easy to allow upper letter exponents in this parser, but the class was considered superfluous and removed from Pharo 3.0â¦
Nicolas to explain a bit the removal of that class. I do not think that Java has three different parser for number in its core or ruby?
From a maintenance perspective this is a lot of stress on us (not only at the code level the conceptually). If we do not have a guy like you taking care of such issues in Pharo daily how can we continue maintaining different parser? This is why we should simplifiy. Why this is the not the job of a GemstoneToPharoPharo to do that? Or ExternalNumberParser (to me it if conceptually different than ExtendedNumberParser) and it should be packaged somewhere else. We got at least two ASTs, three parsers and this cannot be.
Stef
2014-02-26 22:38 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>: Hi guys,
When I export SmallDoubles with SIXX in GemStone it generates something like this:
<sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble" >1.0000000000000000E-02</sixx.object>
This is because "0.01 asString" -> '1.0000000000000000E-02'
Then I want to load this in Pharo. So first problem is that of course SmallDouble doesn't exist. So I did:
aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float.
But then, SIXX use Float >> readFrom: aStream "Answer a new Float as described on the stream, aStream."
^(super readFrom: aStream) asFloat
So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0
So my 0.01 in gemstone become 1.0 in Pharo....
Am I doing something wrong or this is expected? What is the best workaround?
In GemStone I could print the SmallDouble in the XML with a method like
Float >> xmlRepresentation ^ String streamContents: [:strm | self printOn: strm base: 10]
Is this the correct approach? If true, I guess I should define:
Float >> sixxContentOn: aStream indent: level context: dictionary aStream nextPutAll: self xmlRepresentation
Thoughts?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
2014-02-27 8:39 GMT+01:00 Pharo4Stef <pharo4Stef@free.fr>:
On 26 Feb 2014, at 23:08, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
That's exactly for this kind of reasons that I developped an ExtendedNumberParser connected to Number class>>readFrom:, to allow a variety of formats used in the rest of the world.
It would have been easy to allow upper letter exponents in this parser, but the class was considered superfluous and removed from Pharo 3.0...
Nicolas
to explain a bit the removal of that class. I do not think that Java has three different parser for number in its core or ruby? From a maintenance perspective this is a lot of stress on us (not only at the code level the conceptually). If we do not have a guy like you taking care of such issues in Pharo daily how can we continue maintaining different parser? This is why we should simplifiy. Why this is the not the job of a GemstoneToPharoPharo to do that? Or ExternalNumberParser (to me it if conceptually different than ExtendedNumberParser) and it should be packaged somewhere else. We got at least two ASTs, three parsers and this cannot be.
Stef
Yes, I understand the motivation for simplification, but... For me, providing a way to parse very simple objects like numbers dates etc... from a string representation SHOULD be a core service. And, indeed, IT IS the #readFrom: API. For dates, there is a well known exhange format, so that's what we can use. For numbers, less so, but most other languages either share sufficient coverage of literal syntax, or provide common libraries for such parsing (like scanf etc...) If you provide a limited API (limited to Smalltalk literal syntax, Squeak/Pharo dialect), then it's sufficiently different from the rest of the world to require extension from app. developpers POV. So you put the burden on application developpers which will re-program the same micro-package again and again. Since it is a micro-feature, this will lead to a balkanization of micro packages, several packages doing more or less the same, more or less correctly. And concerning conversion of Float from decimal->binary representation, it'll be less ciorrectly, indeed it's very easy to do it wrong (not correctly rounded). 10 years ago, every SMalltalk dialect I know of did it wrong in any case... That's also why it should be a core service, and why it is in other languages (via scanf or other library) Back to the implementation, the decision for reifying the NumberParser was precisely: - to correct the parsing of Float which requires a little care to be correctly rounded (what every other language does right, Smalltalk did wrong) - to refactor a bunch of readFrom... selectors spreaded along the number hierarchy. - to correct discrepancies between the readFrom... variants (handling of separators, extra characters, error handling) So was it a good idea to factor Number parsing from several format? I cna agree on critiscism about the implementation: the NumberParser are ad-hoc hand crafted disconnected from grammatical formal description... Maybe what we need is a lower level service on which to build DSL parsers... But in any case, I think it's already better than what we had a few years ago. Cheers Nicolas
2014-02-26 22:38 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi guys,
When I export SmallDoubles with SIXX in GemStone it generates something like this:
<sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble"
1.0000000000000000E-02</sixx.object>
This is because "0.01 asString" -> '1.0000000000000000E-02'
Then I want to load this in Pharo. So first problem is that of course SmallDouble doesn't exist. So I did:
aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. But then, SIXX use Float >> readFrom: aStream "Answer a new Float as described on the stream, aStream." ^(super readFrom: aStream) asFloat
So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0
So my 0.01 in gemstone become 1.0 in Pharo....
Am I doing something wrong or this is expected? What is the best workaround?
In GemStone I could print the SmallDouble in the XML with a method like
Float >> xmlRepresentation ^ String streamContents: [:strm | self printOn: strm base: 10]
Is this the correct approach? If true, I guess I should define:
Float >> sixxContentOn: aStream indent: level context: dictionary aStream nextPutAll: self xmlRepresentation
Thoughts?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
Nicolas, Would you mind putting this in a configuration so that we can load it easily in 3.0? I agree with you that this parsing story should be as best as possible. And it is not so right now. Phil
Nicolas I do not criticise the implementation, Iâm too stupid for that. For us this is the conceptual overload our problem. There should be one number parser in the core. Now I would love to have nicely packaged extensions that are call ExternalParsers with nice tests and documentation (Iâm even willing to spend time writing it if there are some tests). And this package would be a really important one. You see related to that when I was young and bold I thought that we must enhance the time and date in the core. And we did it back then in Squeak. Now if I would have to redo it I would do it that way: keep a nice and minimal (not too minimal) core in the language AND have really nicely packaged frameworks supporting calendars, time zones and others. so that the programmers can choose. Stef
On 02/26/2014 01:38 PM, Mariano Martinez Peck wrote:
So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0
This is because Pharo only accepts lower-case letters for exponent ($e $d $q). So if you replace E with e Pharo will parse it as you wish. -Martin
Hi Mariano, How about just defining: SmallDouble >> sixxType ^'Float' SmallDouble >> sixxWriteValue ^self asFloat I'm not using GemStone right now, so maybe my assumption would be inaccurate. But just a quick answer. Regards, 2014-02-27 6:38 GMT+09:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi guys,
When I export SmallDoubles with SIXX in GemStone it generates something like this:
<sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble"
1.0000000000000000E-02</sixx.object>
This is because "0.01 asString" -> '1.0000000000000000E-02'
Then I want to load this in Pharo. So first problem is that of course SmallDouble doesn't exist. So I did:
aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. But then, SIXX use Float >> readFrom: aStream "Answer a new Float as described on the stream, aStream." ^(super readFrom: aStream) asFloat
So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0
So my 0.01 in gemstone become 1.0 in Pharo....
Am I doing something wrong or this is expected? What is the best workaround?
In GemStone I could print the SmallDouble in the XML with a method like
Float >> xmlRepresentation ^ String streamContents: [:strm | self printOn: strm base: 10]
Is this the correct approach? If true, I guess I should define:
Float >> sixxContentOn: aStream indent: level context: dictionary aStream nextPutAll: self xmlRepresentation
Thoughts?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
-- [:masashi | ^umezawa]
participants (6)
-
Mariano Martinez Peck -
Martin McClure -
Masashi UMEZAWA -
Nicolas Cellier -
Pharo4Stef -
phil＠highoctane.be