> Let us be friends and hug each other. Thanks. I apologize to everyone (Of course, James, Ondřej, and you are included) for being too offensive against Ondřej's argument and wasting your time. I'll do more constructive discussion.
2013/4/2 James Pike <jp...@chilon.net> > Let us be friends and hug each other. > > On Mon, Apr 01, 2013 at 09:44:02am -0430, Juancarlo Añez wrote: > > So... > > You're just long-time enemies, > > and I'm wasting my time in this forum. > > I'm translating 600K lines of COBOL into C# in under 4min per CPU > core, > > and that means nothing. > > Onegai shimasu, > > > > On Mon, Apr 1, 2013 at 9:14 AM, Kota Mizushima <[1]mizuk...@gmail.com > > > > wrote: > > > > > And that was precisely my point. You did not mention that this is > > most > > > important part (Name of section is "3.3 properties"). > > > Also you did not mentioned counter in paper. > > > > Yes. This is not most important part in our paper since the notion of > > our cut operator > > > > and its effectiveness were described in our earlier work.  However, > > our earlier paper > > > > has been written in Japanese.  Then, the overview of cut was needed. > >  That's all. > > > > And I think that it's not need to mention counters in our paper since > > it's **trivial** optimization > > > > and the all implementation detail cannot be written in our paper that > > has page limit. > > > > > It looks that main idea of paper is how to insert cut. > > > > It's not correct in a precise sense.  the main idea of the paper is > > how to insert cut **automatically* without > > > > changing grammar meanings. > > > > > It looks that main idea of paper is how to insert cut. > > > Actually that section is completely useless. When one incorporated > > > first, follow optimization and does not increase counter when it is > > > predicated then for any cut that you may insert counter is already > > zero. > > > You only increased possibility of bugs without any real benefit. > > > > What do you mean? Certainly, hand-written cut operators may increase > > > > bugs.  Then, we explored the way to decrease space complexity without > > > > hand-written cut operators in our paper.  Of course, our methods is > > too > > > > conservative to cover all practical grammars.  But, we don't > > say such things > > > > and I've written as the followings: > > > > " We believe that this problem can be solved by some extensions to > our > > methods > > > >  (e.g. increasing the number of lookahead nonterminal expressions > > like LL(k)). > > > > We intend to address the problem in future work."  (Sorry for not > > continuing this > > > > research since I work as a software engineer in a company). > > > > Although forms of writing paper maybe poor, it seems that you > > misunderstand about > > > > our paper and the proposed methods. > > > > 2013/03/31 18:19 "OndÅej BÃlka" <[2]nel...@seznam.cz>: > > > > On Sun, Mar 31, 2013 at 03:06:30PM +0900, Kota Mizushima wrote: > > >   Hi, OndÅej. > > >   > I found that paper poorly writen, main idea is: > > >   > Create counter c. In c maintain number of pending ordered > > choice > > >   branches in > > >   > current derivation. > > >   > When c==0 then you can obviously discard entries before > > current > > >   > position. > > >   > This idea is hidden in paper and mentioned only implicitly. > > >   The idea you said is the same thing that we said in our > > paper.  In our > > >   paper[1] Section 3.3, > > >   We explained our idea using "backtracking stack" and how cut > > operators > > >   reduce size of "backtracking stack". > > >   Counter-based approach you said is just a trivial > > optimization in real > > >   parser generator implementation. > > >   Actually, in our parser generator (Yapp) implementation, > > since preparing > > >   "real" backtracking stack explicitly sacrifices execution > > speed because of > > >   too much allocation and GC, > > >   We implemented our idea using one counter (32-bit integer) as > > you said.  > > And that was precisely my point. You did not mention that this is > > most > > important part (Name of section is "3.3 properties"). > > Also you did not mentioned counter in paper. > > It looks that main idea of paper is how to insert cut. > > Actually that section is completely useless. When one incorporated > > first, follow optimization and does not increase counter when it is > > predicated then for any cut that you may insert counter is already > > zero. > > You only increased possibility of bugs without any real benefit. > > As for real parsers do you know implementation other at yapp that > > implements [1]? > > Also experiments in [1] are java and xml. Java grammar was designed > > to > > minimize stack usage, and xml is simple. How does your results > > change > > when you parse c for example? > > >   [1] [1]Packrat Parsers Can Handle Practical Grammars in > > Mostly Constant > > >   Space (PDF). Kota Mizushima, Atusi Maeda, and Yoshinori > > >   Yamaguchi. [2]PASTE, June > > >  > >  2010.[3][3] > http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/pa > > ste513-mizushima.pdf > > > > > >   2013/3/29 OndÅej BÃlka <[4][4]nel...@seznam.cz> > > > > > >    On Thu, Mar 28, 2013 at 03:55:28PM -0430, Juancarlo Añez > > wrote: > > >    >   Hello Kota, > > >    >   I'm reading your paper more carefully now (Packrat > > Parsers can > > >    Handle > > >    >   Practical Grammars in Mostly Constant Space). > > >    >   If I understand correctly, if a cut is seen at > > position P in the > > >    input, > > >    >   then all memoization for positions prior to P can > > be discarded? > > >    >   Thanks in advance! > > >    >   Cheers, > > >    >   -- > > > > > >    Not exactly, > > >    I found that paper poorly writen, main idea is: > > >    Create counter c. In c maintain number of pending ordered > > choice > > >    branches in > > >    current derivation. > > >    When c==0 then you can obviously discard entries before > > current > > >    position. > > >    This idea is hidden in paper and mentioned only > > implicitly. > > > > > >    This is interwined with transformation that allow us say > > that some > > >    branches are not possible. > > > > > >    How they write paper it forces you to use certain > > representation to > > >    carry transformations. This is problem as your > > representation is almost > > >    certainly incompatible. > > > > > >    It is better to use generic optimizations (predication > > gives most) and > > >    get > > >    better space utilization for free > > > > > >    See my thesis for other improvements, chapter 2.6 most of > > ideas apply > > >    [5][5]http://kam.mff.cuni.cz/~ondra/thesis.pdf > > > > > >    Ondra > > > > > >    >   Juancarlo Añez > > > > > >    _______________________________________________ > > >    PEG mailing list > > >    [6][6]PEG@lists.csail.mit.edu > > >    [7][7]https://lists.csail.mit.edu/mailman/listinfo/peg > > > > > >   -- > > >   Kota Mizushima > > >   e-mail: [8][8]mizuk...@gmail.com > > > > > > References > > > > > >   Visible links > > >   1. > > [9] > http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/paste513-miz > > ushima.pdf > > >   2. [10]http://cseweb.ucsd.edu/paste2010/program.html > > >   3. > > [11] > http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/paste513-mi > > zushima.pdf > > >   4. mailto:[12]nel...@seznam.cz > > >   5. [13]http://kam.mff.cuni.cz/~ondra/thesis.pdf > > >   6. mailto:[14]PEG@lists.csail.mit.edu > > >   7. [15]https://lists.csail.mit.edu/mailman/listinfo/peg > > >   8. [GMCP] Compose a new mail to [16]mizuk...@gmail.com > > >    > > [17] > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=mizukota@ > > gmail.com > > -- > > Interference from lunar radiation > > > > -- > > Juancarlo Añez > > > > References > > > > 1. mailto:mizuk...@gmail.com > > 2. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=nel...@seznam.cz > > 3. > http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/paste513-mizushima.pdf > > 4. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=nel...@seznam.cz > > 5. http://kam.mff.cuni.cz/~ondra/thesis.pdf > > 6. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=PEG@lists.csail.mit.edu > > 7. https://lists.csail.mit.edu/mailman/listinfo/peg > > 8. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=mizuk...@gmail.com > > 9. > http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/paste513-mizushima.pdf > > 10. http://cseweb.ucsd.edu/paste2010/program.html > > 11. > http://ialab.cs.tsukuba.ac.jp/~mizusima/publications/paste513-mizushima.pdf > > 12. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=nel...@seznam.cz > > 13. http://kam.mff.cuni.cz/~ondra/thesis.pdf > > 14. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=PEG@lists.csail.mit.edu > > 15. https://lists.csail.mit.edu/mailman/listinfo/peg > > 16. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=mizuk...@gmail.com > > 17. > https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=mizuk...@gmail.com > > > _______________________________________________ > > PEG mailing list > > PEG@lists.csail.mit.edu > > https://lists.csail.mit.edu/mailman/listinfo/peg > > > -- > http://chilon.net > -- Kota Mizushima e-mail: mizuk...@gmail.com<https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&to=mizuk...@gmail.com>
_______________________________________________ PEG mailing list PEG@lists.csail.mit.edu https://lists.csail.mit.edu/mailman/listinfo/peg
