[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