Loopy rule warning

I am seeing this warning a lot when parsing an inferred grammar with Ace:
WARNING: grammar rule `n14-bottom-coord’ is loopy
WARNING: edge #835 [n14-bottom-coord] == edge #593 [n14-bottom-coord]

It’s coming from one of the coordination rules. What does this warning mean practically speaking? Is the sentence not parsing because the rule is loopy and it runs out of edges, or is it just telling me that I have a bad/inefficient rule? Or something else?

I suspect this means that a unary rule is applying to its own mother, leading to an infinite search space for the parser.

Hm. Is that expected? None of these grammars are failing validation. Do you have any idea what choice/combination of choices would lead to that?

Definitely not expected! The thing to do would be to look at the rule in question, I guess. I wonder if we’re somehow landing on a particular combination that isn’t well represented in the regression tests?

I would debug by loading the grammar into the LKB, limiting the search space with this command at the LKB prompt:

(setf *maximum-number-of-edges* 200)

… and then parsing an appropriate sentence. This should lead to a parse chart you can examine that shows the behavior…

Okay, I’ll take a look and report back (maybe tomorrow). Where do I use that command? In emacs when parsing? ctrl+y?

I think it is under Options -> Set Options (in the GUI) but there is probably also a config file somewhere.

1 Like

I actually think that this is a pydelphin message. I suppose I’m not too worried about it, but I am curious. It’s difficult to tell which test items are causing the warning to be thrown. For example, the first item in the file fails due to an unknown lexical item and the second parses, but I get the warning after the first documentation of the error.

NOTE: lexemes do not span position 0 s'tolen'! NOTE: post reduction gap NOTE: ignoring s’tolen t’q’uiħe .’
WARNING: grammar rule n9-bottom-coord' is loopy WARNING: edge #364 [n9-bottom-coord] == edge #324 [n9-bottom-coord] WARNING: grammar rule n9-bottom-coord’ is loopy

Is there a way to find out what sentences are causing this warning in order to do some interactive unification? If not I suppose I can make a dummy sentence with np coordination. But I’m just not sure if “loopy” is something to be concerned about or not.

@kphowell these are ACE messages, not PyDelphin ones. By the way, the first (“lexemes do not span position 0”) means your first word s’tolen’ is not represented by your lexicon + morphological rules. Maybe you need something in the lexicon or a new/updated rule.

I don’t think ACE has an command-line option to limit the number of edges (see AceOptions) but you could limit the memory available with --max-chart-megabytes=X. Choose an appropriate value for X.

If you parse with ace on the command line (and not redirecting output into log files) instead of via pydelphin, the error messages and warnings should be printed in the right order and determining what sentence was being processed should be easy. Something like:

ace -g mygram.dat -1 sentences.txt

The sentence being processed is given in the closest following SENT or SKIP line. Once you know which sentence it is, you can inspect the chart in LUI to see what the edge numbers it cites are and find out what sequence of rule applications results in the loopy behavior.

Woodley