[developers] lkb/ace difference on generation

David Brodbeck brodbd at uw.edu
Fri Feb 20 22:14:55 CET 2015


This is a good detail for students to learn, anyway, because they *will*
encounter compilers and other systems later that are picky about line
endings.  I've seen more than one student beat their head against a problem
for hours that I was able to solve for them with dos2unix.

On Thu, Feb 19, 2015 at 9:07 PM, Woodley Packard <sweaglesw at sweaglesw.org>
wrote:

> 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
> ====================================
>
>
>


-- 
D. Brodbeck
System Administrator, Linguistics
University of Washington
GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20150220/5c9b871c/attachment.html>


More information about the developers mailing list