Hi All,
Squeak trunk also suffers from the Float parsed as a Fraction bug:
1e-8 class Fraction 1.0e8 class Float
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
Hi Levente,
On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi leves@elte.hu 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
On Wed, 6 Aug 2014, Eliot Miranda wrote:
Hi Levente,
On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi leves@elte.hu 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 FloatI'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-2OK, 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
On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 6 Aug 2014, Eliot Miranda wrote:
Hi Levente,
On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi leves@elte.hu wrote: On Wed, 6 Aug 2014, Eliot Miranda wrote:
Hi All, Squeak trunk also suffers from the Float parsed as aFraction bug:
1e-8 class Fraction 1.0e8 class FloatI'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: whichoutputs 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
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.htm...
I don't think this is a bug at all. BTW, Cuis also supports 1r111111111111 = 12 after this :)
Cheers, Juan Vuletich
Quoting Eliot Miranda eliot.miranda@gmail.com:
On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 6 Aug 2014, Eliot Miranda wrote:
Hi Levente,
On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi leves@elte.hu 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
Hi Juan,
On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) < juanlists@jvuletich.org> 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.htm...
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 eliot.miranda@gmail.com:
On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 6 Aug 2014, Eliot Miranda wrote:
Hi Levente,
On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi leves@elte.hu wrote: On Wed, 6 Aug 2014, Eliot Miranda wrote:
Hi All, Squeak trunk also suffers from the Float parsed as aFraction bug:
1e-8 class Fraction 1.0e8 class FloatI'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: whichoutputs 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
On Thu, 7 Aug 2014, Eliot Miranda wrote:
Hi Juan,
On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) juanlists@jvuletich.org 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.htmlDan 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
Hi Levente,
On Thu, Aug 7, 2014 at 11:47 AM, Levente Uzonyi leves@elte.hu wrote:
On Thu, 7 Aug 2014, Eliot Miranda wrote:
Hi Juan,
On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) < juanlists@jvuletich.org> wrote:
Hi Folks, Just tried Smalltalk-80 (actually Apple Smalltalk-80 running inMini 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.
Hi Eliot,
Quoting Eliot Miranda eliot.miranda@gmail.com:
Hi Juan,
On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists)juanlists@jvuletich.org 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 literalFraction 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.htm...
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
On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) < juanlists@jvuletich.org> wrote:
Hi Eliot,
Quoting Eliot Miranda eliot.miranda@gmail.com:
Hi Juan,
On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists)juanlists@jvuletich.org 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 literalFraction 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
Quoting Eliot Miranda eliot.miranda@gmail.com:
On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) < juanlists@jvuletich.org> 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
On Thu, 7 Aug 2014, J. Vuletich (mail lists) wrote:
Quoting Eliot Miranda eliot.miranda@gmail.com:
On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) < juanlists@jvuletich.org> 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
Quoting Levente Uzonyi leves@elte.hu:
On Thu, 7 Aug 2014, J. Vuletich (mail lists) wrote:
Quoting Eliot Miranda eliot.miranda@gmail.com:
On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) < juanlists@jvuletich.org> 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
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)" juanlists@jvuletich.org:
Quoting Levente Uzonyi leves@elte.hu:
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
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)" juanlists@jvuletich.org:
Quoting Levente Uzonyi leves@elte.hu:
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
Hi Levente,
Quoting Levente Uzonyi leves@elte.hu:
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)" juanlists@jvuletich.org:
Quoting Levente Uzonyi leves@elte.hu:
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
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 lecteur@zogotounga.net:
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
Wow, I didn't know this was possible. Thanks Nicolas!
This gem is now part of Cuis (where exponents up to 36 work ok).
Cheers, Juan Vuletich
Quoting Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
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 lecteur@zogotounga.net:
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
Quoting Stéphane Rollandin lecteur@zogotounga.net:
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
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda -
J. Vuletich (mail lists) -
Levente Uzonyi -
Nicolas Cellier -
Stéphane Rollandin