[pet] [delph-in] Poll to identify actively used functionality in PET

Rebecca Dridan bec.dridan at gmail.com
Wed Jul 7 17:11:05 CEST 2010


>> Does this mean that we can either hypothesise every generic entry for
>> every token (and then filter them), or not use generic entries at all? I
>> found this to be a major efficiency issue when large numbers of generic
>> entries were available. I don't have a problem with defaulting to the
>> current "all" setting, but I think there are still possible
>> configurations where one would like to react only when lexical gaps were
>> found.
>
> There is a discussion of this input by Dan, which shows the problems of
> the old variant on
>
> http://wiki.delph-in.net/moin/PetInput
>
> Don't know if you're aware of that.
Very much aware of it, the trade-offs were extensively debated and 
tested during my thesis work and they are not quite as one-sided as that 
page suggests :) But I see that Stephan has answered below and if 
lexical instantiation can be made more efficient, there's no real need 
to keep the gap detection mode. Until then, removing the option will 
limit any further experiments with large sets of generic entries in 
other grammars (which haven't all had Dan's fine-tuning).

>> I celebrate the removal of ECL, but will there be any way of doing more
>> than white space tokenisation natively in PET, or was the decision made
>> that PET will always be run in conjunction with an LKB pre-processing 
>> step?
>
> Which other possibilities were there? The idea is to replace the
> structured input formats by FSC as far as possible.
I just wondered if the idea of native REPP processing had been 
discussed, since it came up on the mailing list lately. For those of us 
using the full LOGON tree, it doesn't really matter, but for anyone 
wanting to use PET in an application, installing LKB just to get the 
tokenisation right is a lot of overhead. Again, Stephan has pretty much 
answered this for me below.


Rebecca



More information about the pet mailing list