Difference between revisions of "Constraint Grammar/Speed"
Jump to navigation
Jump to search
Line 32: | Line 32: | ||
==See also== |
==See also== |
||
* More tips on p.48 of http://www.hf.uio.no/iln/om/organisasjon/tekstlab/aktuelt/arrangementer/arkiv/CG08/CG3_Oslo.pdf#48 |
* More tips on p.48 and on of http://www.hf.uio.no/iln/om/organisasjon/tekstlab/aktuelt/arrangementer/arkiv/CG08/CG3_Oslo.pdf#48 |
||
[[Category:Constraint Grammar]] |
[[Category:Constraint Grammar]] |
Revision as of 15:24, 20 September 2014
Tips on how to speed up your Constraint Grammar.
Contents
Put popular rules first
If a cohort can be fully disambiguated early on, CG won't have to bother with that cohort later at all.
E.g. if you two rules that work on nouns, but one of them only matches if there's some rare verb in the context, try to put that rule after the first rule (as long as you still get the correct disambiguation!).
Avoid slow rule types
Regexes
Lots of regex matching ("foo.*bar"r) is typically slow.
(*)
A rule like
"<foo>" ADD (bar) (*) IF …
is much slower than
"<foo>" ADD (bar) ("<foo>") IF …
(vislcg3 might optimise that away in the future?)
Speedy alternatives to CG
- apertium-tagger is a lot faster than CG, but only supports the same types of rules that the tagger can learn (e.g. select or remove this bigram).
- fomacg (see User:David Nemeskey/GSOC progress 2013) is a project to create a finite-state version of CG, but is currently research stage.
See also
- More tips on p.48 and on of http://www.hf.uio.no/iln/om/organisasjon/tekstlab/aktuelt/arrangementer/arkiv/CG08/CG3_Oslo.pdf#48