pharo compiler on scientific notation

> On 19 Dec 2019, at 16:02, Nicolas Anquetil <[hidden email]> 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
>
>

> On 19 Dec 2019, at 19:28, tbrunz <[hidden email]> 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
>

> 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 <[hidden email]> 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
> >
>
>

> On 20 Dec 2019, at 10:58, Nicolas Anquetil <[hidden email]> 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 <[hidden email]> 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
>
>

> On 20 Dec 2019, at 13:37, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>
>>
>