<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Yi Zhang</b> <<a href="mailto:yzhang@coli.uni-sb.de">yzhang@coli.uni-sb.de</a>><br>Date: Nov 10, 2006 4:10 PM
<br>Subject: Re: [itsdb] parse big corpus with itsdb<br>To: <a href="mailto:oe@csli.stanford.edu">oe@csli.stanford.edu</a><br><br></span>Hi Stephan,<br><br><span class="gmail_quote"></span><div><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
PACKING_NOUNPACK could signal the parser to stop forest creation as soon as there is one tree. should i just add that (as an addition to the two tests i had to touch yesterday already)?
</blockquote></span><div>True. I will vote for using PACKING_NOUNPACK for the purpose. Thanks :-)<br> </div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
as for another parameter to limit forest construction, i would be in no<br>way opposed to extra flexibility. although i might worry slightly that<br>we are already offering (too) many distinct ways of running the parser,
<br>where some today make better sense than others :-).</blockquote></span><div>That's also true. Until we have a proper way to do k-best forest creation, I guess the `nsolutions' for selective unpacking will be enough for the users to play with.
<br><br>Best,<br>yi<br> </div></div><br>