well, in a sense, exhausting the edge limit is a crash, since the parser was not able to find the solution within limited memory, and just aborted. In other words, the parser did not even know whether there was a parse or not. With selective unpacking (-packing=15), the parser spends much more time in searching before hitting the limit. Yi <div>On 7/12/07, Sergio Roa <<a href="mailto:sergior@coli.uni-sb.de">sergior@coli.uni-sb.de</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi Yi, On Thursday 12 July 2007, Yi Zhang wrote: > > I mean leaving it as default, so, the options now are: > > > >   cheap -limit=100000 -tok=fsr -nsolutions=10 > > Oh, I just checked the code. It seems that if ``-packing'' is not given, > then packing is disabled (=0, no packing). If ``-packing'' is given without > ``=n'', then it's defaulted to 15. > > So in your case, you are running without packing. I just tried again, and > it leads to immediate out of memory failure. Therefore, what you got > without packing is a crash, rather than real results. How can  you know this  is a crash?  The verbose output I  get without packing is: 69133 types in 7.5 s edge limit exhausted (100000 pedges) id: 1 trees: 0 readings: 0 words: 200 words_pruned: 37 mtcpu: 0 first: -1 tcpu: 14290 utcpu: 0 ftasks_fi: 16514325 ftasks_qc: 4671458 fsubs_fi: 0 fsubs_qc: 0 etasks: 175805 stasks: 150097 aedges: 50281 pedges: 100000 upedges: 0 raedges: 0 rpedges: 0 medges: 0 unifications_succ: 175421 unifications_fail: 25708 subsumptions_succ: 0 subsumptions_fail: 0 copies: 200660 dyn_bytes: 908659104 stat_bytes: 904933232 p_dyn_bytes: 0 p_nstat_bytes: 0 cycles: 0 fssize: 1 unify_cost_succ: 409 unify_cost_fail: 109 equivalent: 0 proactive: 0 retroactive: 0 frozen: 0 failures: 0 I thought it means that the edge limit is exhausted. -- Sergio. </blockquote></div>