[developers] LOGON: error `input fix-up ambiguity: 2 outputs'

Emily M. Bender ebender at uw.edu
Sat Mar 1 22:14:00 CET 2014


Thanks, Stephan and Woodley.  To recap for future reference, the problem
was in fact that the target-side grammar was also loading transfer rules
(without specifying them as such with :task :transfer) and so in this
lightweight LKB-LKB MT set up (which is not MMT, but what I have the
students use as they work out transfer rules for translating to their
languages), the target-side grammar was also trying to apply transfer rules
to the (post-transfer) generator input.

The solution is to either not load the rules in the target-side grammar, or
to be explicit about what they are for, as so:

(mt:read-transfer-rules
 (list
  (lkb-pathname (parent-directory) "acm.mtr"))
 "A place to put your transfer rules"
 :filter nil :task :transfer)

Emily


On Sat, Mar 1, 2014 at 7:09 AM, Stephan Oepen <oe at ifi.uio.no> wrote:

> yes, exactly: the 'fixup' mechanism in the generator, i.e. the optional
> transfer grammar invoked on generator inputs prior to lexical lookup,
> is defined to be ambiguity-free, i.e. must not contain optional rules.
>
> this step is not really intended for transfer, but rather to make minor
> adjustments to one generator input, resulting in one generator input
> that has a higher chance of success, for example making sure that
> all instance variables are quantified (if a grammar requires that) or
> that labels are linked up right between a quantifier and its entity.
>
> in case you need a full-fledged transfer step, i think that should be
> separated from generation, such that it can fan-out appropriately.
>
> i realize the explanation offered by woodley (and seconded by me
> now) seems at odds with your observation that it does not matter
> whether or not the rule in question is activated.  but maybe there
> are other optional rules in the 'fixup' transfer grammar?
>
> best, oe
>
> On Sat, Mar 1, 2014 at 6:27 AM, Woodley Packard <sweaglesw at sweaglesw.org>
> wrote:
> > Hi Emily,
> >
> > The message means that the translation rules (acm.mtr) produce multiple
> > possible outputs.  This is because the pro-drop transfer rule is marked
> as
> > optional (type "monotonic_omtr" as opposed to "monotonic_mtr").  I'm not
> > sure if that was intentional or?  I tried translating eng2eng with ACE
> and
> > got a related message (I assume you're using the LKB for translation -
> ACE
> > issues the warning but proceeds with generation with just the first
> transfer
> > result).
> >
> > In general it is legal to have multiple transfer results, but when
> transfer
> > is done as part of the "fixup" stage, there is no opportunity for
> > disambiguation, so the LKB and ACE both (apparently) assume there will
> only
> > be one.  If you want the ambiguity (e.g. if you want to try generating
> both
> > ways), perhaps explicitly separating the transfer step from the
> generation
> > step is called for.
> >
> > You say that the error appears whether or not the pro-drop rule is
> enabled
> > as part of the grammar or not.  That is not the case on my end
> (admittedly a
> > different setup -- eng2eng instead of frr2eng, and ACE instead of LKB),
> so
> > I'm not sure what to suggest there.
> >
> > Good luck,
> > -Woodley
> >
> > On Feb 28, 2014, at 7:54 PM, "Emily M. Bender" <ebender at uw.edu> wrote:
> >
> > Hi,
> >
> > I'm trying to get the LOGON MT set up ready for my students to work with,
> > and I've hit an error message that's new to me (in the message subject).
> > This comes about when I try to translate from Frisian (frr) to English
> (eng)
> > for any sentence with a pronoun in it.  Sentences without pronouns work
> > fine, and eng2frr works, even with pronouns.
> >
> > Perhaps relatedly, the pro-drop rule I've defined (for other output
> > languages) doesn't fire for frr inputs though it does for eng inputs,
> though
> > I've been unable to spot the difference in the (relevant portions of) the
> > MRSs.   (And the `input fix-up ambiguity' error appears whether or not
> that
> > rule is enabled as part of the grammar.)
> >
> > I'm attaching the grammars in case anyone is curious, but what I'm really
> > looking for is any leads on what the error indicates.
> >
> > I suspect the difference has to do with the fact that the frr grammar was
> > built last year, while eng was (re)built this year, so the Matrix
> versions
> > are not the same.  But I haven't yet been able to pinpoint a relevant
> > difference.
> >
> > (This is all with Ubuntu+LKB 17, 64-bit version.)
> >
> > Thanks for any leads,
> > Emily
> >
> > --
> > Emily M. Bender
> > Associate Professor
> > Department of Linguistics
> > Check out CLMS on facebook! http://www.facebook.com/uwclma
> > <eng.tgz><frr.tgz>
> >
> >
>



-- 
Emily M. Bender
Associate Professor
Department of Linguistics
Check out CLMS on facebook! http://www.facebook.com/uwclma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20140301/0fe0576d/attachment-0001.html>


More information about the developers mailing list