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