[developers] lkb/ace difference on generation

Fri Feb 20 06:07:20 CET 2015

Hi Emily,

Thanks Sanghoun for checking the behavior at your end.

The problem, as Sanghoun guessed, is that the VPM is not kicking in.  You can see that in the MRS that came out of parsing, the variables have types like "ref-ind" and "event," rather than "x" and "e," with the exception of the LTOP, which gets "h."  On the way back in for generation, the "ref-ind" etc are types that the system knows about but "h" is not.  The reason the LTOP got "h" is that it is manufactured (using the "handle-type" configuration parameter) instead of read off the AVM.  The configuration setting is correct; you normally want "h" rather than "handle," but it wasn't felicitous when the VPM was broken.

I think if you look carefully, you will find an error message in the grammar compilation log that looks like:

vpm: syntax error on line 10, 1/1 context but 1/-1 rule

Unfortunately, in ACE 0.9.17 that was a non-fatal error, so it is easy to overlook.  In ACE 0.9.19 it is fatal, so it was easy for Sanghoun to spot.  The reason for the syntax error is the DOS line endings.  Probably the system should be a bit more flexible about accepting non-UNIX line endings (I guess LKB didn't have any trouble), but that's how it is for right now.

Hope that helps,
-Woodley

On Feb 19, 2015, at 7:19 PM, Sanghoun Song <sanghoun at uw.edu> wrote:

> Dear Emily,
> 
> On my machine, I could get the generation results as follows. 
> 
> $ echo "mʔ-piri-ɣʔe-n" | ace -g ckt.dat | ace -g ckt.dat -e
> NOTE: 1 readings, added 41 / 34 edges to chart (34 fully instantiated, 2 actives used, 2 passives used)    RAM: 539k
> NOTE: parsed 1 / 1 sentences, avg 539k, time 0.02247s
> Mʔ-piri-n
> Mʔ-piri-ɣʔe-n
> Mʔ-piri-ɣʔi-n
> NOTE: 322 passive, 119 active edges in final generation chart; built 579 passives total. [3 results]
> NOTE: generated 1 / 1 sentences, avg 2311k, time 0.35266s
> NOTE: transfer did 0 successful unifies and 0 failed ones
> 
> One reason might be the difference in ACE version. Your ckt.dat was compiled by 0.9.17, and my ACE engine is ver. 0.9.19. 
> 
> Another reason that I can think of is the carriage return in semi.vpm. When I compile the data file on my machine, I couldn't at the beginning. It was because semi.vpm had the Windows carriage return. I did the following command, and then could use the grammar.
>  
> $ dos2unix semi.vpm
> 
> Sanghoun
> 
> 
> On Fri, Feb 20, 2015 at 8:56 AM, Emily M. Bender <ebender at uw.edu> wrote:
> Hi,
> 
> I'm encouraging the current crop of 567 students to try
> out ace for generation, and we've turned up a case where
> the LKB is happy to generate and ace complains that
> the input MRS is ill-formed.  The grammar (for Chukchi)
> can be found here:
> 
> http://courses.washington.edu/ling567/ckt.tgz
> 
> And at least one sentence with this behavior is the following:
> 
> mʔ-piri-ɣʔe-n
> 1sgA.INT-capture-TH-3sgO
> "I would have captured it/him/her." 
> 
> Both the LKB and ace are happy to parse this, with ace giving
> the output below, but when I try:
> 
> echo "mʔ-piri-ɣʔe-n" | ace -g ckt.dat | ace -g ckt.dat -e
> 
> I get:
> 
> WARNING: illformed input MRS
> NOTE: 0 passive, 0 active edges in final generation chart; built 921998632 passives total. [0 results]
> NOTE: 1 readings, added 41 / 34 edges to chart (34 fully instantiated, 2 actives used, 2 passives used)    RAM: 535k
> NOTE: parsed 1 / 1 sentences, avg 535k, time 0.01259s
> NOTE: generated 0 / 1 sentences, avg 3k, time 0.00032s
> NOTE: transfer did 0 successful unifies and 0 failed ones
> 
> Any suggestions on how to go about figuring out what
> ace doesn't like about the MRS here?  (I tried another grammar
> from the same generation and can generate with ace, so I'm
> guessing it's not a core matrix property [this time].)
> 
> Thanks,
> Emily
> 
> ace parsing output:
> 
> ubuntu at UbuntuLKB:~/567/ckt$ echo "mʔ-piri-ɣʔe-n" | ace -g ckt.dat 
> SENT: mʔ-piri-ɣʔe-n
> [ LTOP: h0 INDEX: event2 [ event SORT: semsort E.TENSE: nonfuture E.ASPECT: non-progressive E.MOOD: conditional SF: prop-or-ques ] RELS: < [ "_take_v_rel"<-1:-1> LBL: handle1 ARG0: event2 ARG1: ref-ind3 [ ref-ind SORT: semsort COG-ST: in-foc SPECI: bool PNG.PER: 1st PNG.NUM: singular PNG.GEND: gender ] ARG2: ref-ind4 [ ref-ind SORT: semsort COG-ST: cog-st SPECI: bool PNG.PER: 3rd PNG.NUM: singular PNG.GEND: gender ] ] > HCONS: < h0 qeq handle1 > ICONS: < event2 non-focus ref-ind4 event2 non-focus ref-ind3 > ] ;  (189 decl-head-opt-subj 0.000000 0 1 (188 basic-head-opt-comp 0.000000 0 1 (187 3sg-O-suffix 0.000000 0 1 (186 thematic-suffix4a 0.000000 0 1 (185 not-prog-lex 0.000000 0 1 (184 not-tku-lex 0.000000 0 1 (183 not-ne-lex 0.000000 0 1 (182 1st-sg-conditional-prefix 0.000000 0 1 (181 not-future-lex 0.000000 0 1 (180 not-ine-lex 0.000000 0 1 (2 piri 0.000000 0 1 ("mʔ-piri-ɣʔe-n"))))))))))))
> NOTE: 1 readings, added 41 / 34 edges to chart (34 fully instantiated, 2 actives used, 2 passives used)    RAM: 535k
> 
> 
> NOTE: parsed 1 / 1 sentences, avg 535k, time 0.00543s
> 
> 
> 
> -- 
> Emily M. Bender
> Professor, Department of Linguistics
> Check out CLMS on facebook! http://www.facebook.com/uwclma
> 
> 
> 
> -- 
> ====================================
> Sanghoun Song
> Ph.D. in Computational Linguistics | http://corpus.mireene.com
> NTU Computational Linguistics Lab. | http://compling.hss.ntu.edu.sg
> ====================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20150219/3d9c2dd0/attachment.html>