Hi All,
Squeak trunk also suffers from the Float parsed as a Fraction bug: 1e-8 class Fraction 1.0e8 class Float eek!
Eliot
|
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 <[hidden email]> wrote: --
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). 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-- best, Eliot
|
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. #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 > > |
On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <[hidden email]> wrote:
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.
best, Eliot
|
Hi Folks,
|
Hi Juan,
On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) <[hidden email]> wrote:
What happens if you try compiling a method containing a literal Fraction and both debug it and decompile it.
Dan doesn't say anything about Fraction literals in this message.
What, that 1e-3 is a Fraction, not a Float?
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) <[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. >>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 <[hidden email]> wrote: --
Right, which I see as orthogonal to the literal Fractions issue. and 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
|
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. > 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 |
On Thu, Aug 7, 2014 at 12:03 PM, J. Vuletich (mail lists) <[hidden email]> wrote: -- Hi Eliot, then if you feel strongly change it back, but you need to fix this:
(1/2) isLiteral false when you do so.
best, Eliot
|
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 |
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 > > > |
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 |
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 |
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 > > |
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 |
Ah, that reminds me that I already played with this "feature". Here is a convenience method attached2014-08-08 19:34 GMT+02:00 Stéphane Rollandin <[hidden email]>:
Fraction-printAsLiteralOn.st (2K) Download Attachment |
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 >> >> |
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 |
Free forum by Nabble | Edit this page |