[developers] LOGON: error `input fix-up ambiguity: 2 outputs'
Emily M. Bender
ebender at uw.edu
Mon Mar 3 23:15:03 CET 2014
And one last breadcrumb for posterity:
In fact, it seems that while adding :task :transfer blocks the rules from
being used as post-transfer fix-up rules, it also blocks them (in this
set-up) from being used as transfer rules.
On Sat, Mar 1, 2014 at 1:14 PM, Emily M. Bender <ebender at uw.edu> wrote:
> 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:
> (lkb-pathname (parent-directory) "acm.mtr"))
> "A place to put your transfer rules"
> :filter nil :task :transfer)
> 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>
>> > 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
>> > optional (type "monotonic_omtr" as opposed to "monotonic_mtr"). I'm not
>> > sure if that was intentional or? I tried translating eng2eng with ACE
>> > got a related message (I assume you're using the LKB for translation -
>> > issues the warning but proceeds with generation with just the first
>> > result).
>> > In general it is legal to have multiple transfer results, but when
>> > is done as part of the "fixup" stage, there is no opportunity for
>> > disambiguation, so the LKB and ACE both (apparently) assume there will
>> > be one. If you want the ambiguity (e.g. if you want to try generating
>> > ways), perhaps explicitly separating the transfer step from the
>> > step is called for.
>> > You say that the error appears whether or not the pro-drop rule is
>> > 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),
>> > 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
>> > 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
>> > 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,
>> > I've been unable to spot the difference in the (relevant portions of)
>> > MRSs. (And the `input fix-up ambiguity' error appears whether or not
>> > rule is enabled as part of the grammar.)
>> > I'm attaching the grammars in case anyone is curious, but what I'm
>> > looking for is any leads on what the error indicates.
>> > I suspect the difference has to do with the fact that the frr grammar
>> > built last year, while eng was (re)built this year, so the Matrix
>> > 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
Emily M. Bender
Department of Linguistics
Check out CLMS on facebook! http://www.facebook.com/uwclma
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers