<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I assume no token mapping &nbsp;or YY input is involved which could lead to two underlying tokens. &nbsp;I, like you, find it surprising that two raw instances of the same lexeme would enter the chart for the same token. &nbsp;Have you checked whether other processors give the same result?</div><div><br></div><div>If using ACE, running with -vvv will yield data about tokens and orthographemic exploration near the top of the (generous) log output. &nbsp;You will see lines that look like:</div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">=int=ʔał -&gt; =0 [1 ways]</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">If that line appears twice, that is likely at least an intermediate source of the problem. Also review the list of initial tokens printed before the orthographemic exploration log; two&nbsp;=int=ʔał tokens would be surprising but would explain the problem.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">If there is only one such orthographemic exploration entry, it becomes harder to guess how two identical lexical edges could be generated.</span></div><div><br></div><div>Curious, Woodley</div><div><br>On Apr 12, 2019, at 6:46 AM, Emily M. Bender &lt;<a href="mailto:ebender@uw.edu">ebender@uw.edu</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">From my understanding of looking at this with David, the full rules are constrained regarding their order of application. Instead, it seems to be the first step (stripping the affixes to find the roots) where the order is underspecified. The =0 lexical entry gives rise to two separate edges in the chart, which then each can take the two affixes, in the same fixed sequence. Is there a way to tell the processor not to do that?<div><br></div><div>Emily</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 11, 2019 at 9:51 PM Woodley Packard &lt;<a href="mailto:sweaglesw@sweaglesw.org">sweaglesw@sweaglesw.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>Hi David,</div><div><br></div><div>If I understand correctly you have a lexical entry whose orthography in the lexicon is “=0” but which only ever appears in combination with the prefix or suffix or both, which lets you cover up the fact that the =0 was ever there.&nbsp; Sounds reasonable to me.</div><div><br></div><div>Forgive me if this is too obvious and not what’s going on, but: &nbsp;getting two parses when both suffix and prefix are present seems likely to be caused by unconstrained order of application of those rules.&nbsp; Have you checked whether the two parses you get have the rules applying in opposite orders?&nbsp; If so, the solution is simply to constrain things so that one of them cannot consume the other’s output.</div><div><br></div><div>If on the other hand the two parses have identical derivations then the result is unexpected — at least under the currently used definition of derivation trees.&nbsp; There have been suggestions that derivations with different internal inflected string values resulting from different subrules of the %prefix and %suffix mechanisms should be considered distinct (and that those should be recorded as part of the derivation tree), but to my knowledge none of our systems supports that yet, nor do I believe a format has been decided upon.</div><div><br></div><div>Best,</div><div>Woodley</div><div><br>On Apr 11, 2019, at 8:56 PM, David Inman &lt;<a href="mailto:davinman@uw.edu" target="_blank">davinman@uw.edu</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello developers,<div><br></div><div>I am using the irules to define a null morpheme by having prefixes and suffixes overwrite a string (=0, 3rd person marking on a clitic complex) when they attach to it. The irules look like this:</div><div><br></div><div><div>past-prefix-2 :=</div><div>%prefix (* =int) (=0 =int)</div><div>past-lex-rule.</div></div><div><br></div><div><div>clitic-plural-suffix :=</div><div>%suffix (* =ʔał) (=0 =ʔał)</div><div>clitic-plural-lex-rule.</div></div><div><br></div><div>This works and generates strings that are lacking the =0 morpheme. Except that in the case where both a prefix and a suffix attach, the parser enters two =0 morphemes into the parse chart and will parse it doubly. (This does not happen for contentful roots.) If the =0 has only "suffixes" after it, then I get one parse. If it has only "prefixes" then I also get one parse. I think the parser sees that =0 can be overwritten either by the prefix or the suffix so it hypothesizes it twice. I'm using the morph rules a bit differently than intended, but is this a case that should be supported? Is there any way around this so that I limit the parsers behavior and get one parse?<br></div><div><div><div dir="ltr" class="gmail-m_197534556666039235gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">David Inman</div><div style="font-size:small">PhD Candidate</div><div style="font-size:small">University of Washington Linguistics</div></div></div></div></div></div></div></div></div></div>
</div></blockquote></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Emily M. Bender<br>Professor,&nbsp;<span style="font-size:12.8px">Department of Linguistics</span></div><div><span style="font-size:12.8px">University of Washington</span></div><div>Twitter: @emilymbender</div></div></div></div></div></div></div></div></div></div>
</div></blockquote></body></html>