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.


Right- the sentence containing s’tolen’ isn’t the one throwing the loopy warning-- it’s failing because it’s not in the lexicon. But I’m trying to figure out which sentence is responsible for this warning.

Can I process an item file from the command line? When I use pydelphin the warnings seem to be out of order (even if I do it by with python in the command line) and when I use art, stdout only shows the results, but no errors/warnings.

If not, it sounds like the solution is to create sentences file from the item file and then parse that with ace?

Ace cannot read tsdb files. Getting the items out is trivial though, something like:

cut tsdb/item -d@ -f 2 > sentences.txt

(Not sure off hand if 2 is the right field… some small integer.)


PyDelphin can make that step easier, at least:

$ delphin select 'i-input' path/to/profile > sentences.txt

Also, if the loopy error message is stored in the profile, you might be able to find it with a select query like this:

$ delphin select 'i-id i-input error' path/to/profile

If you want to debug this in the LKB, there’s advice in the Grammar Engineering FAQs: http://moin.delph-in.net/GeFaqRunawayRule1 . First create a sentences.txt file as suggested previously, do a batch parse and then look out for the error message “probable runaway rule”.

Thanks everyone! Parsing a sentences file allowed me to isolate a sentence causing this warning. Interestingly, that sentence gets the loopy warning, but it does parse! So I don’t think that the warning is indicative of an infinite search space. …unless ace breaks the loop at some point? So returning to my initial question- what is the warning telling me?

So in the case of ACE, the loopy behavior is detected when trying to pack the new edge. The search space when unpacking, or when parsing without packing, would be infinite. When building the packed chart, the search space is not infinite. ACE discards the loopy edge, so the unpacking search space is also made non-infinite.


1 Like

Oh! That makes sense (and is good behavior on ACE’s part!) Thanks for the explanation.