Smalltalk › Squeak › Squeak - Dev

Float parsed as a Fraction bug

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

Eliot Miranda-2

Float parsed as a Fraction bug

Hi All,

Squeak trunk also suffers from the Float parsed as a Fraction bug:

1e-8 class Fraction

1.0e8 class Float

--
eek!

Eliot

Levente Uzonyi-2

Re: Float parsed as a Fraction bug

On Wed, 6 Aug 2014, Eliot Miranda wrote:

> Hi All,
> Squeak trunk also suffers from the Float parsed as a Fraction bug:
>
> 1e-8 class Fraction
> 1.0e8 class Float

I'm not entirely sure about it being a bug. I've checked Squeak 3.8
(pre-SqNumberParser), and it also parsed that literal as a Fraction. If I
want a Float, I can be explicit and use 1.0e-8.

I made a modified version of Fraction >> #printOn:base: which outputs the
literal format if possible. The change "fixes" the debugger (note that
itw was way less broken in Squeak than in Pharo anyway).
The only drawback I found is that some fractions become a bit more
"complex" when printed, e.g. 3/4 => 75e-2

Levente

>
> --
> eek! Eliot
>
>

Eliot Miranda-2

Re: Float parsed as a Fraction bug

Hi Levente,

On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <[hidden email]> wrote:

On Wed, 6 Aug 2014, Eliot Miranda wrote:

Hi All,
Squeak trunk also suffers from the Float parsed as a Fraction bug:

1e-8 class Fraction
1.0e8 class Float

I'm not entirely sure about it being a bug. I've checked Squeak 3.8 (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I want a Float, I can be explicit and use 1.0e-8.

IMO it very much *is* a bug. Smalltalk-80 has never supported Fraction literals. They're always written as division expressions. Fraction answers false to isLiteral. Just because it worked that way doesn't mean it was right. I suspect no one noticed. Allowing Fraction literals feels like a big change to me.

I made a modified version of Fraction >> #printOn:base: which outputs the literal format if possible. The change "fixes" the debugger (note that itw was way less broken in Squeak than in Pharo anyway).
The only drawback I found is that some fractions become a bit more "complex" when printed, e.g. 3/4 => 75e-2

OK, but is this the right fix? What does everybody think? Keep the language unchanged or add Fraction literals and add another incompatibility with other dialects?

If Fractions are literals

- what is the semantics of 1/0 (easy, it is not a literal, but needs to be stated)?

- what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Is it 10.0 or #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1?

Levente
--
eek! Eliot

--
best,

Eliot

Levente Uzonyi-2

Re: Float parsed as a Fraction bug

On Wed, 6 Aug 2014, Eliot Miranda wrote:

> Hi Levente,
>
> On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <[hidden email]> wrote:
> On Wed, 6 Aug 2014, Eliot Miranda wrote:
>
> Hi All,
> Squeak trunk also suffers from the Float parsed as a Fraction bug:
>
> 1e-8 class Fraction
> 1.0e8 class Float
>
>
> I'm not entirely sure about it being a bug. I've checked Squeak 3.8 (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I want a Float, I can be explicit and use 1.0e-8.
>
>
> IMO it very much *is* a bug. Smalltalk-80 has never supported Fraction literals. They're always written as division expressions. Fraction answers false to isLiteral. Just because it worked that way
> doesn't mean it was right. I suspect no one noticed. Allowing Fraction literals feels like a big change to me.

It's more like undefined behavior than a bug IMHO, though the lack of
#isLiteral makes me think that the Fractions are not intentional.
Interesting how Nicolas's SqNumberParser behaves the same way as the
previous number parser in this case.

>
> I made a modified version of Fraction >> #printOn:base: which outputs the literal format if possible. The change "fixes" the debugger (note that itw was way less broken in Squeak than in Pharo
> anyway).
> The only drawback I found is that some fractions become a bit more "complex" when printed, e.g. 3/4 => 75e-2
>
>
> OK, but is this the right fix? What does everybody think? Keep the language unchanged or add Fraction literals and add another incompatibility with other dialects?

I don't think that anyone ever used this "feature" before, so doing what
other dialects do is probably the best way to resolve this.

>
> If Fractions are literals
> - what is the semantics of 1/0 (easy, it is not a literal, but needs to be stated)?
> - what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Is it 10.0 or #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1?

I did not propose to make all fractions literals. My implementation simply
prints decimal fractions with the exponent notation, e.g. 3/4 is printed
as 75-e2, but 2/3 is still printed as (2/3).

Levente

>
> Levente
> --
> eek! Eliot
>
> --
> best,Eliot
>
>

Eliot Miranda-2

Re: Float parsed as a Fraction bug

On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <[hidden email]> wrote:

On Wed, 6 Aug 2014, Eliot Miranda wrote:

Hi Levente,

On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <[hidden email]> wrote:
On Wed, 6 Aug 2014, Eliot Miranda wrote:

Hi All,
Squeak trunk also suffers from the Float parsed as a Fraction bug:

1e-8 class Fraction
1.0e8 class Float

I'm not entirely sure about it being a bug. I've checked Squeak 3.8 (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I want a Float, I can be explicit and use 1.0e-8.

IMO it very much *is* a bug. Smalltalk-80 has never supported Fraction literals. They're always written as division expressions. Fraction answers false to isLiteral. Just because it worked that way
doesn't mean it was right. I suspect no one noticed. Allowing Fraction literals feels like a big change to me.

It's more like undefined behavior than a bug IMHO, though the lack of #isLiteral makes me think that the Fractions are not intentional. Interesting how Nicolas's SqNumberParser behaves the same way as the previous number parser in this case.

I made a modified version of Fraction >> #printOn:base: which outputs the literal format if possible. The change "fixes" the debugger (note that itw was way less broken in Squeak than in Pharo
anyway).
The only drawback I found is that some fractions become a bit more "complex" when printed, e.g. 3/4 => 75e-2

OK, but is this the right fix? What does everybody think? Keep the language unchanged or add Fraction literals and add another incompatibility with other dialects?

I don't think that anyone ever used this "feature" before, so doing what other dialects do is probably the best way to resolve this.

Agreed. Smalltalk-80 v2 had no literal fractions. ObjectWorks and VisualWorks have never had literal fractions. I can't speak for other dialects, but I'm fairly sure none of the Smalltalk/V, Team/V lineage had literal Fractions either.

If Fractions are literals
- what is the semantics of 1/0 (easy, it is not a literal, but needs to be stated)?
- what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Is it 10.0 or #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1?

I did not propose to make all fractions literals. My implementation simply prints decimal fractions with the exponent notation, e.g. 3/4 is printed as 75-e2, but 2/3 is still printed as (2/3).

Levente

Levente
--
eek! Eliot

--
best,Eliot

--
best,

Eliot

J. Vuletich (mail lists)

Re: Float parsed as a Fraction bug

Hi Folks,

Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac).
1e-3 "printIt" (1/1000)
1e-3 class "printIt" Fraction
1e3 "printIt" 1000
1e3 class "printIt" SmallInteger

This has always been the behavior in Squeak too.

Also check these comments from Dan: http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html

I don't think this is a bug at all.
BTW, Cuis also supports 1r111111111111 = 12 after this :)

Cheers,
Juan Vuletich

Quoting Eliot Miranda <[hidden email]>:

On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <[hidden email]> wrote:

On Wed, 6 Aug 2014, Eliot Miranda wrote:

Hi Levente,

On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <[hidden email]> wrote:
On Wed, 6 Aug 2014, Eliot Miranda wrote:

Hi All,
Squeak trunk also suffers from the Float parsed as a Fraction bug:

1e-8 class Fraction
1.0e8 class Float

I'm not entirely sure about it being a bug. I've checked Squeak 3.8 (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I want a Float, I can be explicit and use 1.0e-8.

IMO it very much *is* a bug. Smalltalk-80 has never supported Fraction literals. They're always written as division expressions. Fraction answers false to isLiteral. Just because it worked that way
doesn't mean it was right. I suspect no one noticed. Allowing Fraction literals feels like a big change to me.

It's more like undefined behavior than a bug IMHO, though the lack of #isLiteral makes me think that the Fractions are not intentional. Interesting how Nicolas's SqNumberParser behaves the same way as the previous number parser in this case.

I made a modified version of Fraction >> #printOn:base: which outputs the literal format if possible. The change "fixes" the debugger (note that itw was way less broken in Squeak than in Pharo
anyway).
The only drawback I found is that some fractions become a bit more "complex" when printed, e.g. 3/4 => 75e-2

OK, but is this the right fix? What does everybody think? Keep the language unchanged or add Fraction literals and add another incompatibility with other dialects?

I don't think that anyone ever used this "feature" before, so doing what other dialects do is probably the best way to resolve this.

Agreed. Smalltalk-80 v2 had no literal fractions. ObjectWorks and VisualWorks have never had literal fractions. I can't speak for other dialects, but I'm fairly sure none of the Smalltalk/V, Team/V lineage had literal Fractions either.

If Fractions are literals
- what is the semantics of 1/0 (easy, it is not a literal, but needs to be stated)?
- what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Is it 10.0 or #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1?

I did not propose to make all fractions literals. My implementation simply prints decimal fractions with the exponent notation, e.g. 3/4 is printed as 75-e2, but 2/3 is still printed as (2/3).

Levente

Levente
--
eek! Eliot

--
best,Eliot

--
best,
Eliot

Eliot Miranda-2

Re: Float parsed as a Fraction bug

Hi Juan,

On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) <[hidden email]> wrote:

Hi Folks,

Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac).
1e-3 "printIt" (1/1000)
1e-3 class "printIt" Fraction
1e3 "printIt" 1000
1e3 class "printIt" SmallInteger

This has always been the behavior in Squeak too.

What happens if you try compiling a method containing a literal Fraction and both debug it and decompile it.

Also check these comments from Dan: http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html

Dan doesn't say anything about Fraction literals in this message.

I don't think this is a bug at all.

What, that 1e-3 is a Fraction, not a Float?

BTW, Cuis also supports 1r111111111111 = 12 after this :)

Cheers,
Juan Vuletich

Quoting Eliot Miranda <[hidden email]>:

On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <[hidden email]> wrote:

On Wed, 6 Aug 2014, Eliot Miranda wrote:

Hi Levente,

On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <[hidden email]> wrote:
On Wed, 6 Aug 2014, Eliot Miranda wrote:

Hi All,
Squeak trunk also suffers from the Float parsed as a Fraction bug:

1e-8 class Fraction
1.0e8 class Float

I'm not entirely sure about it being a bug. I've checked Squeak 3.8 (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I want a Float, I can be explicit and use 1.0e-8.

IMO it very much *is* a bug. Smalltalk-80 has never supported Fraction literals. They're always written as division expressions. Fraction answers false to isLiteral. Just because it worked that way
doesn't mean it was right. I suspect no one noticed. Allowing Fraction literals feels like a big change to me.

It's more like undefined behavior than a bug IMHO, though the lack of #isLiteral makes me think that the Fractions are not intentional. Interesting how Nicolas's SqNumberParser behaves the same way as the previous number parser in this case.

I made a modified version of Fraction >> #printOn:base: which outputs the literal format if possible. The change "fixes" the debugger (note that itw was way less broken in Squeak than in Pharo
anyway).
The only drawback I found is that some fractions become a bit more "complex" when printed, e.g. 3/4 => 75e-2

OK, but is this the right fix? What does everybody think? Keep the language unchanged or add Fraction literals and add another incompatibility with other dialects?

I don't think that anyone ever used this "feature" before, so doing what other dialects do is probably the best way to resolve this.

Agreed. Smalltalk-80 v2 had no literal fractions. ObjectWorks and VisualWorks have never had literal fractions. I can't speak for other dialects, but I'm fairly sure none of the Smalltalk/V, Team/V lineage had literal Fractions either.

If Fractions are literals
- what is the semantics of 1/0 (easy, it is not a literal, but needs to be stated)?
- what is [1/0.1] on: ZeroDivide do: [:ex| #error] ? Is it 10.0 or #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1?

I did not propose to make all fractions literals. My implementation simply prints decimal fractions with the exponent notation, e.g. 3/4 is printed as 75-e2, but 2/3 is still printed as (2/3).

Levente

Levente
--
eek! Eliot

--
best,Eliot

--
best,
Eliot

--
best,

Eliot

Levente Uzonyi-2

Re: Float parsed as a Fraction bug

On Thu, 7 Aug 2014, Eliot Miranda wrote:

> Hi Juan,
>
> On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) <[hidden email]> wrote:
>
> Hi Folks,
>
> Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac).
> 1e-3 "printIt" (1/1000)
> 1e-3 class "printIt" Fraction
> 1e3 "printIt" 1000
> 1e3 class "printIt" SmallInteger
>
> This has always been the behavior in Squeak too.
>
>
> What happens if you try compiling a method containing a literal Fraction and both debug it and decompile it.
>
> Also check these comments from Dan: http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html
>
>
> Dan doesn't say anything about Fraction literals in this message.

I guess the key parts are

>>Lowercase 'e' is used to designate the exponent of a floating point
>>number (as are 'd' and 'q'). It is illegal to specify an exponent for
>>what is otherwise an integer--eg, 10e10 is illegal, while 10.0e10 is
>>legal.

and

"Radix, digits and exponent defined analogously over ints, largeInts, and
Floats."

>
>
> I don't think this is a bug at all.
>
>
> What, that 1e-3 is a Fraction, not a Float?

If 1e-3 is a Float, shouldn't 1e3 be a Float too?

Levente

Eliot Miranda-2

Re: Float parsed as a Fraction bug

Hi Levente,

On Thu, Aug 7, 2014 at 11:47 AM, Levente Uzonyi <[hidden email]> wrote:

On Thu, 7 Aug 2014, Eliot Miranda wrote:

Hi Juan,

On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) <[hidden email]> wrote:

Hi Folks,

Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac).
1e-3 "printIt" (1/1000)
1e-3 class "printIt" Fraction
1e3 "printIt" 1000
1e3 class "printIt" SmallInteger

This has always been the behavior in Squeak too.

What happens if you try compiling a method containing a literal Fraction and both debug it and decompile it.

Also check these comments from Dan: http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html

Dan doesn't say anything about Fraction literals in this message.

I guess the key parts are

Lowercase 'e' is used to designate the exponent of a floating point
number (as are 'd' and 'q'). It is illegal to specify an exponent for
what is otherwise an integer--eg, 10e10 is illegal, while 10.0e10 is
legal.

Right, which I see as orthogonal to the literal Fractions issue.

and

"Radix, digits and exponent defined analogously over ints, largeInts, and Floats."

I don't think this is a bug at all.

What, that 1e-3 is a Fraction, not a Float?

If 1e-3 is a Float, shouldn't 1e3 be a Float too?

I don't see that follows. If 1e3 is an Integer, does that imply 1e-3 is a Fraction? The point is that 1e-3 can be represented either as a Float or a Fraction, but that Fraction is not a literal. So in choosing how it is represented the choice having the least impact on the language semantics is as a Float. At least, for me.

If people feel strongly that Fraction should be literal then let's make it so. But so far I'e not seen much passion or any compelling arguments that we make that choice. However, compatibility with other dialects, and the existing definitions of isLiteral imply using Floats not Fractions.

--
best,

Eliot

J. Vuletich (mail lists)

Re: Float parsed as a Fraction bug

In reply to this post by Eliot Miranda-2

Hi Eliot,

Quoting Eliot Miranda <[hidden email]>:

> Hi Juan,
>
> On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists)
> <[hidden email]> wrote:
>
>> Hi Folks,
>>
>> Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini
>> vMac).
>> 1e-3 "printIt" (1/1000)
>> 1e-3 class "printIt" Fraction
>> 1e3 "printIt" 1000
>> 1e3 class "printIt" SmallInteger
>>
>> This has always been the behavior in Squeak too.
>
>
> What happens if you try compiling a method containing a literal
> Fraction and both debug it and decompile it.
>

The attach shows that in ST-80 a CompiledMethod can contain a Fraction
literal. Source code form for that is '1e-3'. Debugger works as in
Squeak or Cuis.

>> Also check these comments from Dan:
>>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html
>
>
> Dan doesn't say anything about Fraction literals in this message.

He does talk about scientific notation '1e3' and '1e-3' meaning not
Float, but SmallInteger and Fraction. The subject of this thread is
"Float parsed as Fraction bug".

>> I don't think this is a bug at all.
>
>
> What, that 1e-3 is a Fraction, not a Float?

Yes. That, and allowing for Fraction literals in methods.

>> BTW, Cuis also supports 1r111111111111 = 12 after this :)

Cheers,
Juan Vuletich

St80FractionLiteral.PNG (31K) Download Attachment

Eliot Miranda-2

Re: Float parsed as a Fraction bug

On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) <[hidden email]> wrote:

Hi Eliot,

Quoting Eliot Miranda <[hidden email]>:

Hi Juan,

On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists)
<[hidden email]> wrote:

Hi Folks,

Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini
vMac).
1e-3 "printIt" (1/1000)
1e-3 class "printIt" Fraction
1e3 "printIt" 1000
1e3 class "printIt" SmallInteger

This has always been the behavior in Squeak too.

What happens if you try compiling a method containing a literal
Fraction and both debug it and decompile it.

The attach shows that in ST-80 a CompiledMethod can contain a Fraction literal. Source code form for that is '1e-3'. Debugger works as in Squeak or Cuis.

then if you feel strongly change it back, but you need to fix this:

(1/2) isLiteral false

when you do so.

Also check these comments from Dan:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html


Dan doesn't say anything about Fraction literals in this message.

He does talk about scientific notation '1e3' and '1e-3' meaning not Float, but SmallInteger and Fraction. The subject of this thread is "Float parsed as Fraction bug".

I don't think this is a bug at all.


What, that 1e-3 is a Fraction, not a Float?


Yes. That, and allowing for Fraction literals in methods.

BTW, Cuis also supports 1r111111111111 = 12 after this :)

Cheers,
Juan Vuletich

--
best,

Eliot

J. Vuletich (mail lists)

Re: Float parsed as a Fraction bug

Quoting Eliot Miranda <[hidden email]>:

> On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) <
> [hidden email]> wrote:
>
>> The attach shows that in ST-80 a CompiledMethod can contain a Fraction
>> literal. Source code form for that is '1e-3'. Debugger works as in Squeak
>> or Cuis.
>
>
> then if you feel strongly change it back, but you need to fix this:
>
> (1/2) isLiteral false
>
> when you do so.

Well, I don't feel strongly about this, and I don't see what needs to
be changed back in Squeak or Cuis.

What I say is that the behavior we have in ST-80 / Squeak / Cuis seems
right to me, I don't see any problem at all.

So, please elaborate: What should be changed back in Squeak (or Cuis)?
Why does (1/2) isLiteral = false needs fixing? I mean, where is the
bug? (I mean in ST-80, Squeak and Cuis. Not Pharo, where there is a
bug while debugging this stuff.)

> --
> best,
> Eliot

Cheers,
Juan Vuletich

Levente Uzonyi-2

Re: Float parsed as a Fraction bug

On Thu, 7 Aug 2014, J. Vuletich (mail lists) wrote:

> Quoting Eliot Miranda <[hidden email]>:
>
>> On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) <
>> [hidden email]> wrote:
>>
>>> The attach shows that in ST-80 a CompiledMethod can contain a Fraction
>>> literal. Source code form for that is '1e-3'. Debugger works as in Squeak
>>> or Cuis.
>>
>>
>> then if you feel strongly change it back, but you need to fix this:
>>
>> (1/2) isLiteral false
>>
>> when you do so.
>
> Well, I don't feel strongly about this, and I don't see what needs to be
> changed back in Squeak or Cuis.
>
> What I say is that the behavior we have in ST-80 / Squeak / Cuis seems right
> to me, I don't see any problem at all.
>
> So, please elaborate: What should be changed back in Squeak (or Cuis)? Why
> does (1/2) isLiteral = false needs fixing? I mean, where is the bug? (I mean
> in ST-80, Squeak and Cuis. Not Pharo, where there is a bug while debugging
> this stuff.)

Try debugging the following snippet:

| x |
x := 5e-1.
x := x + 1

You'll find that in Cuis it'll be decomipled as:

DoIt
| x |
x _ (1/2).
^ x _ x + 1.

And the debugger will get confused (in Squeak and Pharo too), because
there's (1/2) instead of 5e-1, which is not a literal.
Also if you press Over, then Proceed in the debugger, then the image will
become unresponsive in Cuis (Cuis4.2-1766).

Levente

>
>> --
>> best,
>> Eliot
>
> Cheers,
> Juan Vuletich
>
>
>

J. Vuletich (mail lists)

Re: Float parsed as a Fraction bug

Quoting Levente Uzonyi <[hidden email]>:

> On Thu, 7 Aug 2014, J. Vuletich (mail lists) wrote:
>
>> Quoting Eliot Miranda <[hidden email]>:
>>
>>> On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) <
>>> [hidden email]> wrote:
>>>
>>>> The attach shows that in ST-80 a CompiledMethod can contain a Fraction
>>>> literal. Source code form for that is '1e-3'. Debugger works as in Squeak
>>>> or Cuis.
>>>
>>>
>>> then if you feel strongly change it back, but you need to fix this:
>>>
>>> (1/2) isLiteral false
>>>
>>> when you do so.
>>
>> Well, I don't feel strongly about this, and I don't see what needs
>> to be changed back in Squeak or Cuis.
>>
>> What I say is that the behavior we have in ST-80 / Squeak / Cuis
>> seems right to me, I don't see any problem at all.
>>
>> So, please elaborate: What should be changed back in Squeak (or
>> Cuis)? Why does (1/2) isLiteral = false needs fixing? I mean, where
>> is the bug? (I mean in ST-80, Squeak and Cuis. Not Pharo, where
>> there is a bug while debugging this stuff.)
>
> Try debugging the following snippet:
>
> | x |
> x := 5e-1.
> x := x + 1
>
> You'll find that in Cuis it'll be decomipled as:
>
> DoIt
> | x |
> x _ (1/2).
> ^ x _ x + 1.
>
> And the debugger will get confused (in Squeak and Pharo too),
> because there's (1/2) instead of 5e-1, which is not a literal.
> Also if you press Over, then Proceed in the debugger, then the image
> will become unresponsive in Cuis (Cuis4.2-1766).

Thanks, Levente. This is what I needed.

The debugger becoming unresponsive is an unrelated bug, I just fixed it.

The debugger printing the fraction as a division is a rather minor
annoyance, not bad enough for giving up the cool '5e-1' syntax, in my
opinion. But given that the parser can understand '5e-1', the fraction
should be able to print as a literal. Looks like I'm having some
numerics fun tonight :)

> Levente
>
>>
>>> --
>>> best,
>>> Eliot

Cheers,
Juan Vuletich

J. Vuletich (mail lists)

Re: Float parsed as a Fraction bug

Hi Levente,

I just saw your commit to the inbox. I also had fun with this last
night, and the result is attached. I hope you prefer my version. It is
faster and shorter.

It could also make it easier to do the computation just once instead
of twice (with further refactoring to #isLiteral and #storeOn:).

Cheers,
Juan Vuletich

Quoting "J. Vuletich (mail lists)" <[hidden email]>:

> Quoting Levente Uzonyi <[hidden email]>:
>
>>
>> Try debugging the following snippet:
>>
>> | x |
>> x := 5e-1.
>> x := x + 1
>>
>> You'll find that in Cuis it'll be decomipled as:
>>
>> DoIt
>> | x |
>> x _ (1/2).
>> ^ x _ x + 1.
>>
>> And the debugger will get confused (in Squeak and Pharo too),
>> because there's (1/2) instead of 5e-1, which is not a literal.
>> Also if you press Over, then Proceed in the debugger, then the
>> image will become unresponsive in Cuis (Cuis4.2-1766).
>
> Thanks, Levente. This is what I needed.
>
> The debugger becoming unresponsive is an unrelated bug, I just fixed it.
>
> The debugger printing the fraction as a division is a rather minor
> annoyance, not bad enough for giving up the cool '5e-1' syntax, in
> my opinion. But given that the parser can understand '5e-1', the
> fraction should be able to print as a literal. Looks like I'm having
> some numerics fun tonight :)
>
>> Levente
>>
>>>
>>>> --
>>>> best,
>>>> Eliot
>
> Cheers,
> Juan Vuletich

2076-LiteralFractionsFix-JuanVuletich-2014Aug08-09h28m-jmv.1.cs.st (2K) Download Attachment

Levente Uzonyi-2

Re: Float parsed as a Fraction bug

On Fri, 8 Aug 2014, J. Vuletich (mail lists) wrote:

> Hi Levente,
>
> I just saw your commit to the inbox. I also had fun with this last night, and
> the result is attached. I hope you prefer my version. It is faster and
> shorter.

It looks pretty cool. I tried to avoid Floats, that's why it's slower,
but asymptotically they are the same. I'd rewrite the line

exponent5 _ (without2Factors highBit / (5 log / 2 log)) rounded.

to

exponent5 _ (0.43067655807339306 "2 ln / 5 ln" * without2Factors highBit) truncated.

I didn't think too much about why #truncated is enough, but it seems like
it is.

Also, I'm not sure if #storeOn: has to use the literal form. In Squeak the
debugger uses #printOn: during decompilation.

Levente

>
> It could also make it easier to do the computation just once instead of twice
> (with further refactoring to #isLiteral and #storeOn:).
>
> Cheers,
> Juan Vuletich
>
> Quoting "J. Vuletich (mail lists)" <[hidden email]>:
>
>> Quoting Levente Uzonyi <[hidden email]>:
>>
>>>
>>> Try debugging the following snippet:
>>>
>>> | x |
>>> x := 5e-1.
>>> x := x + 1
>>>
>>> You'll find that in Cuis it'll be decomipled as:
>>>
>>> DoIt
>>> | x |
>>> x _ (1/2).
>>> ^ x _ x + 1.
>>>
>>> And the debugger will get confused (in Squeak and Pharo too), because
>>> there's (1/2) instead of 5e-1, which is not a literal.
>>> Also if you press Over, then Proceed in the debugger, then the image will
>>> become unresponsive in Cuis (Cuis4.2-1766).
>>
>> Thanks, Levente. This is what I needed.
>>
>> The debugger becoming unresponsive is an unrelated bug, I just fixed it.
>>
>> The debugger printing the fraction as a division is a rather minor
>> annoyance, not bad enough for giving up the cool '5e-1' syntax, in my
>> opinion. But given that the parser can understand '5e-1', the fraction
>> should be able to print as a literal. Looks like I'm having some numerics
>> fun tonight :)
>>
>>> Levente
>>>
>>>>
>>>>> --
>>>>> best,
>>>>> Eliot
>>
>> Cheers,
>> Juan Vuletich
>
>

Stéphane Rollandin

Re: Float parsed as a Fraction bug

In reply to this post by Levente Uzonyi-2

> The only drawback I found is that some fractions become a bit more
> "complex" when printed, e.g. 3/4 => 75e-2

In my view, this is a *big* drawback. When I print 3/4, I want to see
3/4 printed.

Stef

Nicolas Cellier

Re: Float parsed as a Fraction bug

Ah, that reminds me that I already played with this "feature".

Here is a convenience method attached

2014-08-08 19:34 GMT+02:00 Stéphane Rollandin <[hidden email]>:

The only drawback I found is that some fractions become a bit more
"complex" when printed, e.g. 3/4 => 75e-2

In my view, this is a *big* drawback. When I print 3/4, I want to see 3/4 printed.

Stef

Fraction-printAsLiteralOn.st (2K) Download Attachment

J. Vuletich (mail lists)

Re: Float parsed as a Fraction bug

In reply to this post by Levente Uzonyi-2

Hi Levente,

Quoting Levente Uzonyi <[hidden email]>:

> On Fri, 8 Aug 2014, J. Vuletich (mail lists) wrote:
>
>> Hi Levente,
>>
>> I just saw your commit to the inbox. I also had fun with this last
>> night, and the result is attached. I hope you prefer my version. It
>> is faster and shorter.
>
> It looks pretty cool. I tried to avoid Floats, that's why it's
> slower, but asymptotically they are the same.

At first sight I thought your version would be much slower. So I
benchmarked a bit and you are right. The difference is not big.

> I'd rewrite the line
>
> exponent5 _ (without2Factors highBit / (5 log / 2 log)) rounded.
>
> to
>
> exponent5 _ (0.43067655807339306 "2 ln / 5 ln" * without2Factors
> highBit) truncated.

Thanks. I adopted this.

> I didn't think too much about why #truncated is enough, but it seems
> like it is.

Well, it is because #highBit gives log2 not of our number, but of the
next bigger power of two. So #truncated is ok.

> Also, I'm not sure if #storeOn: has to use the literal form. In
> Squeak the debugger uses #printOn: during decompilation.

At least on Cuis, for any object, #printOn: gives a 'human readable
form' and #storeOn: gives a compilable expression. So, for
decompilation, #storeOn: is used. Having separate methods for these
features is a good thing. For instance, after these changes, (3/4)
still prints as (3/4) in Cuis. The literal form is used in
decompilation, and the way to compile that Fraction literal in the
first place must have been using this syntax. Therefore there are no
new annoyances because of this changes.

I don't know when Cuis and Squeak diverged on this, but the comments
in Object>>printOn: and Object>>storeOn: in Cuis suggest this
behavior, and the method timestamps are older than Cuis itself...

Cheers,
Juan Vuletich

> Levente
>
>>
>> It could also make it easier to do the computation just once
>> instead of twice (with further refactoring to #isLiteral and
>> #storeOn:).
>>
>> Cheers,
>> Juan Vuletich
>>
>> Quoting "J. Vuletich (mail lists)" <[hidden email]>:
>>
>>> Quoting Levente Uzonyi <[hidden email]>:
>>>
>>>>
>>>> Try debugging the following snippet:
>>>>
>>>> | x |
>>>> x := 5e-1.
>>>> x := x + 1
>>>>
>>>> You'll find that in Cuis it'll be decomipled as:
>>>>
>>>> DoIt
>>>> | x |
>>>> x _ (1/2).
>>>> ^ x _ x + 1.
>>>>
>>>> And the debugger will get confused (in Squeak and Pharo too),
>>>> because there's (1/2) instead of 5e-1, which is not a literal.
>>>> Also if you press Over, then Proceed in the debugger, then the
>>>> image will become unresponsive in Cuis (Cuis4.2-1766).
>>>
>>> Thanks, Levente. This is what I needed.
>>>
>>> The debugger becoming unresponsive is an unrelated bug, I just fixed it.
>>>
>>> The debugger printing the fraction as a division is a rather minor
>>> annoyance, not bad enough for giving up the cool '5e-1' syntax, in
>>> my opinion. But given that the parser can understand '5e-1', the
>>> fraction should be able to print as a literal. Looks like I'm
>>> having some numerics fun tonight :)
>>>
>>>> Levente
>>>>
>>>>>
>>>>>> --
>>>>>> best,
>>>>>> Eliot
>>>
>>> Cheers,
>>> Juan Vuletich
>>
>>

J. Vuletich (mail lists)

Re: Float parsed as a Fraction bug

In reply to this post by Stéphane Rollandin

Quoting Stéphane Rollandin <[hidden email]>:

>> The only drawback I found is that some fractions become a bit more
>> "complex" when printed, e.g. 3/4 => 75e-2
>
> In my view, this is a *big* drawback. When I print 3/4, I want to
> see 3/4 printed.
>
> Stef

See my response to Levente from a minute ago. In Cuis, the only place
where it prints '75e-2' is when decompiling a method whose source code
actually said '75e-2'.

Cheers,
Juan Vuletich