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
>
>
