https://github.com/pharo-project/pharo/issues/5443
> On 20 Dec 2019, at 13:37, Sven Van Caekenberghe <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> >> >
