Parsing float difference between 2.0 and 3.0, was it on purpose?
Hi guys, In Pharo 2.0, the expression "Number readFrom: '2.5850009999999998e+04' " would answer 25850.01 , but in Pharo 3.0 it answers: 2.5850009999999997 which is a kind of WTF to me. Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number >> readFrom: ) implemented: allowPlusSign ^true However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number >> readFrom: uses this class now). But.. (and this is the difference), NumberParser implements: allowPlusSign ^false So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion?? So in my case now I must do an override to: NumberParser >> allowPlusSignInExponent ^ true Thoughts? -- Mariano http://marianopeck.wordpress.com
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys,
In Pharo 2.0, the expression "Number readFrom: '2.5850009999999998e+04' " would answer 25850.01 , but in Pharo 3.0 it answers: 2.5850009999999997 which is a kind of WTF to me.
Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number >> readFrom: ) implemented:
allowPlusSign ^true
However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number >> readFrom: uses this class now).
But.. (and this is the difference), NumberParser implements:
allowPlusSign ^false
So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion??
So in my case now I must do an override to:
NumberParser >> allowPlusSignInExponent ^ true
Thoughts?
-- Mariano http://marianopeck.wordpress.com
On 05 Feb 2015, at 10:36, Ben Coman <btc@openInWorld.com> wrote:
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben
Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose.
On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote: Hi guys,
In Pharo 2.0, the expression "Number readFrom: '2.5850009999999998e+04' " would answer 25850.01 , but in Pharo 3.0 it answers: 2.5850009999999997 which is a kind of WTF to me.
Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number >> readFrom: ) implemented:
allowPlusSign ^true
However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number >> readFrom: uses this class now).
But.. (and this is the difference), NumberParser implements:
allowPlusSign ^false
So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion??
So in my case now I must do an override to:
NumberParser >> allowPlusSignInExponent ^ true
Thoughts?
-- Mariano http://marianopeck.wordpress.com
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit :
On 05 Feb 2015, at 10:36, Ben Coman <btc@openInWorld.com> wrote:
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-)
The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose.
I do not know I think that marcus removed it to avoid to have two parsers in the image.
On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote: Hi guys,
In Pharo 2.0, the expression "Number readFrom: '2.5850009999999998e+04' " would answer 25850.01 , but in Pharo 3.0 it answers: 2.5850009999999997 which is a kind of WTF to me.
Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number >> readFrom: ) implemented:
allowPlusSign ^true
However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number >> readFrom: uses this class now).
But.. (and this is the difference), NumberParser implements:
allowPlusSign ^false
So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion??
So in my case now I must do an override to:
NumberParser >> allowPlusSignInExponent ^ true
Thoughts?
-- Mariano http://marianopeck.wordpress.com
On 06 Feb 2015, at 09:02, stepharo <stepharo@free.fr> wrote:
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit :
On 05 Feb 2015, at 10:36, Ben Coman <btc@openInWorld.com> wrote:
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-)
The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose.
I do not know I think that marcus removed it to avoid to have two parsers in the image.
Maybe this was a mistake⦠Marcus
We have merged the parsers into one, because we had 3 parsers that didnât have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system. As for the expression - yes we have to decide about it. If itâs only about being able to use exponent in float literals, one can use: âNumber readFrom: '2.5850009999999998e04ââ. If itâs about being similar to the other languages, we can also decide does it make sense to have a +2 literal. Uko
On 06 Feb 2015, at 09:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 06 Feb 2015, at 09:02, stepharo <stepharo@free.fr> wrote:
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit :
On 05 Feb 2015, at 10:36, Ben Coman <btc@openInWorld.com> wrote:
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-)
The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose.
I do not know I think that marcus removed it to avoid to have two parsers in the image.
Maybe this was a mistakeâ¦
Marcus
On 06 Feb 2015, at 11:45, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
We have merged the parsers into one, because we had 3 parsers that didnât have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system.
Yes, it was quite hard to understand what was going on. And it is strange to have 3 different parsers for numbers...
As for the expression - yes we have to decide about it. If itâs only about being able to use exponent in float literals, one can use: âNumber readFrom: '2.5850009999999998e04ââ. If itâs about being similar to the other languages, we can also decide does it make sense to have a +2 literal.
If it makes no problems with backward compatibility, why not have both?
Uko
On 06 Feb 2015, at 09:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 06 Feb 2015, at 09:02, stepharo <stepharo@free.fr> wrote:
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit :
On 05 Feb 2015, at 10:36, Ben Coman <btc@openInWorld.com> wrote:
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-)
The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose.
I do not know I think that marcus removed it to avoid to have two parsers in the image.
Maybe this was a mistakeâ¦
Marcus
2015-02-06 16:18 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 06 Feb 2015, at 11:45, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
We have merged the parsers into one, because we had 3 parsers that didnât have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system.
Yes, it was quite hard to understand what was going on. And it is strange to have 3 different parsers for numbers...
No it's not strange. 2 different parsers respond to 2 different syntax and expectations. To me it's quite clear: - The SmalltalkNumberParser was there to parse a Smalltalk syntax (badly named SqNumberParser in the ages...) It should do this thru Number readSmalltalkSyntaxFrom: '1.0e4' - The ExtendedNumberParser was there to parse an extended syntax (the one most apps handling data from oustide world will wish to parse). It should do this thru Number readFrom: '1.0e+4' - The FortranNumberParser was just an unused experiment. Its sole goal was to expose an example of how a GenericNumberParser could be subclassed. Such class has a better place in a cook-book than in the image, so Bye bye. Date readFrom: '2015/02/06' readStream does not have to follow a Smalltalk syntax, so why Number readFrom: '1.0e+4' readStream would have to? As Yuriy underlined, we might extend the Smalltalk syntax to embrasse some of external world patterns, why not, but it's limited and is going to be a problem with formats like '.2' or '2.e0'. Whether the extended parser should be in the core image or not is a valid question. We all agree that Pharo is all but finished and need to be constantly cleaned up. The challenge is how can Pharo change but remain application-writer-friendly? So two different things are: - the value of the feature: is it worth maintaining it or not? If yes, should it be maintained outside the core, or inside by the Pharo-team? I agree that removing incomplete features is a valid strategy when the team is too small - the quality of implementation And there are two ways of cleaning: - clean a dirty implementation, but keep the feature (eventually with a different API) - remove the feature, based on a value/cost analysis Here, I feel like it's the dictatorship which sounds questionnable. Were the feature understood? There were unit tests and class comments, so pretending to not understand is not really an excuse. Were the value of the features discussed? Maybe in a small core team... From outside, we don't really know. Were an externalisation of the feature and transfer of maintenance to a 3rd party discussed? I'm not aware of. I'm sure it would have been a better decision. So from my POV, such decision process remains to improve. It sounds too light and arbitrary. In some cases, I have the impression that the volunty of cleaning is too much dogmatic. I agree that too much pragmatism won't lead to a clean image any time soon... I agree that Pharo team has a licence to change things and should decide, otherwise let's all stick to Squeak ;) But a bit of democratie, argumentation and COORDINATION does not hurt. Then how can user support be improved? - Is it possible to write release notes helping the transition? (were is located the add-on package that enables compatibility, who maintains it, is there a new and better API, etc...) - Could some automated AST-based refactorings be prepared and applied auto-magically? It's not necessarily the sole business of Pharo-team, user community could help writing such notes. Nicolas
As for the expression - yes we have to decide about it. If itâs only about being able to use exponent in float literals, one can use: âNumber readFrom: '2.5850009999999998e04ââ. If itâs about being similar to the other languages, we can also decide does it make sense to have a +2 literal.
If it makes no problems with backward compatibility, why not have both?
Uko
On 06 Feb 2015, at 09:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 06 Feb 2015, at 09:02, stepharo <stepharo@free.fr> wrote:
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit :
On 05 Feb 2015, at 10:36, Ben Coman <btc@openInWorld.com> wrote:
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-)
The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose.
I do not know I think that marcus removed it to avoid to have two parsers in the image.
Maybe this was a mistakeâ¦
Marcus
Hi nicolas.
No it's not strange. 2 different parsers respond to 2 different syntax and expectations.
To me it's quite clear:
- The SmalltalkNumberParser was there to parse a Smalltalk syntax (badly named SqNumberParser in the ages...) It should do this thru Number readSmalltalkSyntaxFrom: '1.0e4'
- The ExtendedNumberParser was there to parse an extended syntax (the one most apps handling data from oustide world will wish to parse). It should do this thru Number readFrom: '1.0e+4'
I have a question: is ExtendedNumberParser parsing SmalltalkNumberParser numbers? Because we could use by default ExtendedNumberParser. Else we can have an external package to maintain ExtendedNumberParser part of the ecosystem.
- The FortranNumberParser was just an unused experiment. Its sole goal was to expose an example of how a GenericNumberParser could be subclassed. Such class has a better place in a cook-book than in the image, so Bye bye.
We could add it to the PharoExtras.
Date readFrom: '2015/02/06' readStream does not have to follow a Smalltalk syntax, so why Number readFrom: '1.0e+4' readStream would have to?
As Yuriy underlined, we might extend the Smalltalk syntax to embrasse some of external world patterns, why not, but it's limited and is going to be a problem with formats like '.2' or '2.e0'.
Whether the extended parser should be in the core image or not is a valid question. We all agree that Pharo is all but finished and need to be constantly cleaned up. The challenge is how can Pharo change but remain application-writer-friendly? So two different things are: - the value of the feature: is it worth maintaining it or not? If yes, should it be maintained outside the core, or inside by the Pharo-team? I agree that removing incomplete features is a valid strategy when the team is too small - the quality of implementation
And there are two ways of cleaning: - clean a dirty implementation, but keep the feature (eventually with a different API) - remove the feature, based on a value/cost analysis
Here, I feel like it's the dictatorship which sounds questionnable. Were the feature understood? There were unit tests and class comments, so pretending to not understand is not really an excuse.
Were the value of the features discussed? Maybe in a small core team... From outside, we don't really know.
No discussion should happen in the mailing-list but the problem is that the mailing-list is like a stream. I forget things. This is why we should have a better process but if I could get less things to do it would also help me a lot (and I do not mean pharo things :)).
Were an externalisation of the feature and transfer of maintenance to a 3rd party discussed? I'm not aware of. I'm sure it would have been a better decision.
So from my POV, such decision process remains to improve. It sounds too light and arbitrary. In some cases, I have the impression that the volunty of cleaning is too much dogmatic.
I agree. This happens when we are too mcuh stress. When I feel that I want to throw away half of the system (menu, fonts... and many others :)) I just close pharo and do something else
I agree that too much pragmatism won't lead to a clean image any time soon... I agree that Pharo team has a licence to change things and should decide, otherwise let's all stick to Squeak ;) But a bit of democratie, argumentation and COORDINATION does not hurt.
Yes.
Then how can user support be improved? - Is it possible to write release notes helping the transition? (were is located the add-on package that enables compatibility, who maintains it, is there a new and better API, etc...) - Could some automated AST-based refactorings be prepared and applied auto-magically? It's not necessarily the sole business of Pharo-team, user community could help writing such notes.
So what would be a reasonable plan. I have no problem to maintain a nice package in PharoExtras if it helps. Stef
On Fri, Feb 6, 2015 at 7:45 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
We have merged the parsers into one, because we had 3 parsers that didnât have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system. As for the expression - yes we have to decide about it. If itâs only about being able to use exponent in float literals, one can use: âNumber readFrom: '2.5850009999999998e04ââ. If itâs about being similar to the other languages, we can also decide does it make sense to have a +2 literal.
Yes, I would allow that by default. This will ease serialization between Pharo and GemStone for example (which uses +). So..... what I would do is to simply change to NumberParser >> allowPlusSignInExponent ^ true I opened: https://pharo.fogbugz.com/f/cases/14896/By-default-float-parsing-does-not-al... Cheers, Uko
On 06 Feb 2015, at 09:04, Marcus Denker <marcus.denker@inria.fr> wrote:
On 06 Feb 2015, at 09:02, stepharo <stepharo@free.fr> wrote:
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit :
On 05 Feb 2015, at 10:36, Ben Coman <btc@openInWorld.com> wrote:
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-)
The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose.
I do not know I think that marcus removed it to avoid to have two parsers in the image.
Maybe this was a mistakeâ¦
Marcus
-- Mariano http://marianopeck.wordpress.com
participants (7)
-
Ben Coman -
Marcus Denker -
Mariano Martinez Peck -
Nicolas Cellier -
stepharo -
Sven Van Caekenberghe -
Yuriy Tymchuk