On 3 September 2011 20:43, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2011/9/3 Frank Shearar <frank.shearar@gmail.com>:
On 3 September 2011 19:35, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2011/9/3 Frank Shearar <frank.shearar@gmail.com>:
On 3 September 2011 18:50, Lukas Renggli <renggli@gmail.com> wrote:
I think it is a good idea to have the number parser separate, after all it might also make sense to use it separately.
It seems that the new Smalltalk grammar is significantly slower. The benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the source code of the collection hierarchy and does not especially target number literals runs 30% slower.
Also I see that "Number readFrom: ..." is still used within the grammar. This seems to be a bit strange, no?
Yes: it's a double-parse, which is a bit lame. First, we parse the literal with PPSmalltalkNumberParser, which ensures that the thing given to Number class >> #readFrom: is a well-formed token (so, in particular, Squeak's Number doesn't get to see anything other than a well-formed token).
It sounds like you're happy with the basic concept, so maybe I should remove the Number class >> #readFrom: stuff, see if I can't remove the performance issues, and resubmit the patch.
frank
Yes, a NumberParser is essentially parsing, and this duplication sounds useless.
It's bad for performance but it's definitely not useless: it removes the platform-dependent issues around Number class >> #readFrom:. In Squeak we use the ExtendedNumberParser which will quite happily accept '1.' as a valid number. This way, #readFrom: definitely gets a valid Smalltalk number literal.
frank
My question was why using NumberParser at all? I indicated one essential feature of interest that should be ported to a PetitNumberParser (round to nearest Float), and another optional one for optimization.
I'm not arguing at all. The first instance - turning the radix digits into a number - is trivial to remove. The second use of NumberParser's next on the hit list. If you have any further suggestions on efficient conversions from collection-of-digit-characters to numbers that aren't already in NumberParser, I'm all ears. My use of Number class >> #readFrom: was entirely a pragmatic first step - it let me write the grammar while keeping the test suite green. Now I need just address your and Lukas' suggestions, before I resubmit. Most importantly, I know that the basic idea/structure's not crazy. frank
Nicolas
The main feature of interest in NumberParser that I consider a requirement and should find its equivalence in a PetitNumberParser is: - round a decimal representation to nearest Float It's simple, just convert a Fraction asFloat in a single final step to avoid cumulating round off errors - see #makeFloatFromMantissa:exponent:base:
The second feature of interest in NumberParser is the ability to parser LargeInteger efficiently by avoiding (10 * largeValue + digitValue) loops, and replacing them with a log(n) cost. This would be a simple thing to implement in a functional language.
Nicolas
Lukas
On 3 September 2011 17:18, Frank Shearar <frank.shearar@gmail.com> wrote:
On 3 September 2011 15:56, Lukas Renggli <renggli@gmail.com> wrote:
On 3 September 2011 16:51, Frank Shearar <frank.shearar@gmail.com> wrote:
Hi Lukas,
I haven't :) mainly because I'm unsure where to put it - is there perhaps a PP Inbox, or shall I just post the merged version, or what's your preference? (How about an mcd between my merge and PP's head?)
Just put the .mcz at some public URL (dropbox, squeak source, ...) or attach it to a mail.
Ah, great - here it is. You'll see I've written the grammar as a separate class. That was really more to make what I'd done more obvious and to minimise the change to PPSmalltalkGrammar, but perhaps it's not a bad idea anyway: it's easy to see the number literal subgrammar.
frank
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch