<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi Stephan,</div><div><br></div><div>I agree that the ambiguity you reference, and that David and Emily believe they are experiencing, and I also alluded to a few emails ago, exists in principle and might be interesting in some situations.  I would be surprised to see it result in two identical uninflected lexical edges in the chart, however, at least in ACE’s current implementation.  The ambiguity arises as a result of two ways to apply the first rule, not from two different lexical starting places.  Furthermore I didn’t (?) think ACE was set up to generate multiple output edges from a single rule/daughter combination, as I maintain would be required for this ambiguity.</div><div><br></div><div>To the question of whether ace blocks that ambiguity: the only difference would be in the ORTH feature of the two intermediate edges, I suppose.  Until recently ACE did not even write orthographemic changes to that feature.  I suppose at the moment it arbitrarily picks one or the other.  Just now it seems that approach could theoretically result in inadvertently taking an orthographemic dead-end, although I’m not aware of that issue ever coming up in practice.  I think I could be persuaded that the right thing to do would be to generate both variants (from just one source lexical edge), but before implementing that I think an appropriate improvement to UDF would be in order.</div><div><br></div><div>Enjoy the train ride!</div><div>Woodley</div><div><br>On Apr 12, 2019, at 9:15 AM, Stephan Oepen <<a href="mailto:oe@ifi.uio.no">oe@ifi.uio.no</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div dir="auto">hi woodley, and all,</div></div><div dir="auto"><br></div><div dir="auto">i would have thought our current engines are quite capable of generating seemingly duplicate derivations, owing to incomplete information being recorded about orthographemic segmentation.  in fact, i believe i recall at least JaCY exposing this phenomenon in the LKB and PET.</div><div dir="auto"><br></div><div dir="auto">assume two orthographemic rules, each with two subrules (which both can apply to some stem), maybe something like:</div><div dir="auto"><br></div><div dir="auto">one :-</div><div dir="auto">%suffix (* s) (e ss)</div><div dir="auto">[...].</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">two :=</div><div dir="auto">%suffix (!s !sed) (s ssed)</div><div dir="auto">[...].</div><div dir="auto"><br></div><div dir="auto">not sure the above is quite right, but i want to allow two chains through these rules that only differ in the internal string segmentation, e.g. assuming a stem ‘fore’ and a final surface form ‘foressed’:</div><div dir="auto"><br></div><div dir="auto">fore one fores two foressed</div><div dir="auto">fore one foress two foressed</div><div dir="auto"><br></div><div dir="auto">from what i recall about at least the PET implementation, i would expect the above to result in two distinct lexical sub-trees whose derivations in current UDX will look alike (and which are guaranteed to immediately pack)</div><div dir="auto"><br></div><div dir="auto">would you expect to block such ambiguity (in ACE)?  if so, on what basis, and which of the two variants should prevail?</div><div dir="auto"><br></div><div dir="auto">—ever since yi and others started retracing (with some effort) the exact string-level effects of orthographemic nodes in our derivations i have been thinking we should extend UDX and probably both record which affixation sub-rule applied, and what the strings at the ‘top’ and the ‘bottom’ looked like.</div><div dir="auto"><br></div><div dir="auto">would this extra information seem adequate and sufficient to you (and others)?  if so, i would like to try and work out how to extend the UDX syntax, while maintaining backwards compatibility.</div><div dir="auto"><br></div><div dir="auto">greetings from the train to finse 1222!  oe</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Apr 2019 at 06:51 Woodley Packard <<a href="mailto:sweaglesw@sweaglesw.org">sweaglesw@sweaglesw.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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.  Sounds reasonable to me.</div><div><br></div><div>Forgive me if this is too obvious and not what’s going on, but:  getting two parses when both suffix and prefix are present seems likely to be caused by unconstrained order of application of those rules.  Have you checked whether the two parses you get have the rules applying in opposite orders?  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.  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><div dir="auto"><div><br>On Apr 11, 2019, at 8:56 PM, David Inman <<a href="mailto:davinman@uw.edu" target="_blank">davinman@uw.edu</a>> 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="m_-743657734815425697gmail_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></div> </div></blockquote></body></html>