On Mon, Apr 01, 2013 at 10:44:51PM +0900, Kota Mizushima 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
I meant that there are other methods to prune backtracking stack than automaticaly inserting cut. Most flexible is add to each branch flag and disable branch when we know it cannot succeed. This, when we transform ~A X | ~B Y | A W | B Z into 1. ~A Cut(3.) X | 2. ~B Cut(4.) Y | 3. A W | 4. B Z Allows us when we reached Cut(4.) and previously did Cut(3.) forget memory positions. I added switch that does lookahead to distinguish first terminal, So I could transform a | [bc] | [ac] to 'a' => a | [ac], 'b' => [bc], 'c' => [ac] | [bc] which does same without having to insert cuts. (I have something more general to represent choice, lookaheads and cut.) > > 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. Idea of paper was good but it was problematic to implement from paper. _______________________________________________ PEG mailing list [email protected] https://lists.csail.mit.edu/mailman/listinfo/peg
