pharo compiler on scientific notation
In pharo 7, inspecting: 1.0e3333 gives: "Reading a number failed -> " it works for: 1.0e333 (only three "3") is that the expected behaviour ? nicolas -- Nicolas Anquetil RMod team -- Inria Lille
Because your exponent is not between: Float emin and: Float emax ? In other words it is too large and not representable in a https://en.wikipedia.org/wiki/IEEE_754 double.
On 19 Dec 2019, at 16:02, Nicolas Anquetil <nicolas.anquetil@inria.fr> wrote:
In pharo 7, inspecting: 1.0e3333
gives: "Reading a number failed -> "
it works for: 1.0e333 (only three "3")
is that the expected behaviour ?
nicolas
-- Nicolas Anquetil RMod team -- Inria Lille
I would expect that both would result in +Inf. A IEEE-754 'double' overflows around 2e308. Surely both cases should behave the same way..?? -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Yes, the difference is not good. Indeed, Float fmax. "1.7976931348623157e308" The reason Number readFrom: '7.5e333'. gives infinity is actual not because of the reading, but because of 75e332 asFloat. Which is probably correct. The failure of Number readFrom: '7.5e3333'. is because of NumberParser>>#readExponent However, the test at the end is probably wrong. Float emax is a binary number, not a decimal one, IIUC. Nicolas (nice) ?
On 19 Dec 2019, at 19:28, tbrunz <wild.ideas@gmail.com> wrote:
I would expect that both would result in +Inf.
A IEEE-754 'double' overflows around 2e308.
Surely both cases should behave the same way..??
-t
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
actually the problem arose from some old code that I tried to load and failed to. So I guess at some point in the past (pharo4 or prior) it was working : --- PPExpressParserTests>>testReal3 self parse: '-1.1333e3333' rule: #literal. self assert: (result value = -1.1333e3333). self assert: (PPSmalltalkParser parseExpression: '- 1.1333e3333') = result rbNode --- nicolas On Fri, 2019-12-20 at 10:21 +0100, Sven Van Caekenberghe wrote:
Yes, the difference is not good.
Indeed,
Float fmax. "1.7976931348623157e308"
The reason
Number readFrom: '7.5e333'.
gives infinity is actual not because of the reading, but because of
75e332 asFloat.
Which is probably correct.
The failure of
Number readFrom: '7.5e3333'.
is because of NumberParser>>#readExponent
However, the test at the end is probably wrong.
Float emax
is a binary number, not a decimal one, IIUC.
Nicolas (nice) ?
On 19 Dec 2019, at 19:28, tbrunz <wild.ideas@gmail.com> wrote:
I would expect that both would result in +Inf.
A IEEE-754 'double' overflows around 2e308.
Surely both cases should behave the same way..??
-t
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- Nicolas Anquetil RMod team -- Inria Lille
The tests you refer to would basically test Float infinity = Float infinity. If you change NumberParser>>#readExponent "read the exponent if any (stored in instVar). Answer true if found, answer false if none. If exponent letter is not followed by a digit, this is not considered as an error. Exponent are always read in base 10." | eneg epos | exponent := 0. sourceStream atEnd ifTrue: [ ^ false ]. (self exponentLetters includes: sourceStream peek) ifFalse: [ ^ false ]. sourceStream next. eneg := sourceStream peekFor: $-. epos := eneg not and: [ self allowPlusSignInExponent and: [ sourceStream peekFor: $+ ] ]. (exponent := self nextUnsignedIntegerOrNilBase: 10) ifNil: [ "Oops, there was no digit after the exponent letter.Ungobble the letter" exponent := 0. sourceStream skip: ((eneg or: [ epos ]) ifTrue: [ -2 ] ifFalse: [ -1 ]). ^ false ]. eneg ifTrue: [ exponent := exponent negated ]. ^ true You will get Float infinity for exponents that are too large. The test on the exponent range was bogus anyway.
On 20 Dec 2019, at 10:58, Nicolas Anquetil <nicolas.anquetil@inria.fr> wrote:
actually the problem arose from some old code that I tried to load and failed to.
So I guess at some point in the past (pharo4 or prior) it was working :
--- PPExpressParserTests>>testReal3 self parse: '-1.1333e3333' rule: #literal. self assert: (result value = -1.1333e3333). self assert: (PPSmalltalkParser parseExpression: '- 1.1333e3333') = result rbNode ---
nicolas
On Fri, 2019-12-20 at 10:21 +0100, Sven Van Caekenberghe wrote:
Yes, the difference is not good.
Indeed,
Float fmax. "1.7976931348623157e308"
The reason
Number readFrom: '7.5e333'.
gives infinity is actual not because of the reading, but because of
75e332 asFloat.
Which is probably correct.
The failure of
Number readFrom: '7.5e3333'.
is because of NumberParser>>#readExponent
However, the test at the end is probably wrong.
Float emax
is a binary number, not a decimal one, IIUC.
Nicolas (nice) ?
On 19 Dec 2019, at 19:28, tbrunz <wild.ideas@gmail.com> wrote:
I would expect that both would result in +Inf.
A IEEE-754 'double' overflows around 2e308.
Surely both cases should behave the same way..??
-t
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- Nicolas Anquetil RMod team -- Inria Lille
https://github.com/pharo-project/pharo/issues/5443
On 20 Dec 2019, at 13:37, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The tests you refer to would basically test Float infinity = Float infinity.
If you change
NumberParser>>#readExponent "read the exponent if any (stored in instVar). Answer true if found, answer false if none. If exponent letter is not followed by a digit, this is not considered as an error. Exponent are always read in base 10."
| eneg epos | exponent := 0. sourceStream atEnd ifTrue: [ ^ false ]. (self exponentLetters includes: sourceStream peek) ifFalse: [ ^ false ]. sourceStream next. eneg := sourceStream peekFor: $-. epos := eneg not and: [ self allowPlusSignInExponent and: [ sourceStream peekFor: $+ ] ]. (exponent := self nextUnsignedIntegerOrNilBase: 10) ifNil: [ "Oops, there was no digit after the exponent letter.Ungobble the letter" exponent := 0. sourceStream skip: ((eneg or: [ epos ]) ifTrue: [ -2 ] ifFalse: [ -1 ]). ^ false ]. eneg ifTrue: [ exponent := exponent negated ]. ^ true
You will get Float infinity for exponents that are too large.
The test on the exponent range was bogus anyway.
On 20 Dec 2019, at 10:58, Nicolas Anquetil <nicolas.anquetil@inria.fr> wrote:
actually the problem arose from some old code that I tried to load and failed to.
So I guess at some point in the past (pharo4 or prior) it was working :
--- PPExpressParserTests>>testReal3 self parse: '-1.1333e3333' rule: #literal. self assert: (result value = -1.1333e3333). self assert: (PPSmalltalkParser parseExpression: '- 1.1333e3333') = result rbNode ---
nicolas
On Fri, 2019-12-20 at 10:21 +0100, Sven Van Caekenberghe wrote:
Yes, the difference is not good.
Indeed,
Float fmax. "1.7976931348623157e308"
The reason
Number readFrom: '7.5e333'.
gives infinity is actual not because of the reading, but because of
75e332 asFloat.
Which is probably correct.
The failure of
Number readFrom: '7.5e3333'.
is because of NumberParser>>#readExponent
However, the test at the end is probably wrong.
Float emax
is a binary number, not a decimal one, IIUC.
Nicolas (nice) ?
On 19 Dec 2019, at 19:28, tbrunz <wild.ideas@gmail.com> wrote:
I would expect that both would result in +Inf.
A IEEE-754 'double' overflows around 2e308.
Surely both cases should behave the same way..??
-t
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- Nicolas Anquetil RMod team -- Inria Lille
participants (3)
-
Nicolas Anquetil -
Sven Van Caekenberghe -
tbrunz