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
_______________________________________________ PEG mailing list PEG@lists.csail.mit.edu https://lists.csail.mit.edu/mailman/listinfo/peg
