<div><div><div dir="auto">hi john,</div></div><div dir="auto"><br></div><div dir="auto">peter and i originally designed the formalism, and undoubtedly there are finer points not in the paper or slides. PET can output detailed tracing information (look for the ‘erg’ shell alias in $LOGONROOT/dot.bashrc, which i suspect may be helpful.</div><div dir="auto"><br></div><div dir="auto">from memory, ‘redundancy’ detection means that new chart items are discarded if an equivalent item exists, and processing that role stopped for that position. i used to try and write rules that could not feed indefinitely on their own OUTPUT, but in at least some cases i allowed myself to take advantage of the redundancy check.</div><div dir="auto"><br></div><div dir="auto">regarding non-determinism in matching a rule LHS, from memory i would expect that all possibilities are explored.</div><div dir="auto"><br></div><div dir="auto">yes, copying into the rule RHS is certainly not limited to INPUT matches.</div><div dir="auto"><br></div><div dir="auto">if you were game, maybe we should video-conference at some point to go through other subtleties (that you are bound to uncover :-)? i would be thrilled if the LKB were to acquire an implementation of chart mapping (which i believe would also have several prospective use cases in generation)!</div><div dir="auto"><br></div><div dir="auto">best wishes, oe</div></div><div><div dir="auto"><br></div><div dir="auto"><br></div><div><div><img src="cid:17280675b7fcf9fb31e1" style="max-width: 100%;"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">tor. 4. jun. 2020 kl. 19:11 skrev John Carroll <<a href="mailto:J.A.Carroll@sussex.ac.uk" target="_blank">J.A.Carroll@sussex.ac.uk</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi developers,<br> <br> I've started to look at chart mapping and how it might be implemented. I've been reading the following:<br> <br> 'Tutorial - Chart Mapping in PET' at DELPH-IN Summit 2009 <a href="http://www.delph-in.net/2009/cm.pdf" rel="noreferrer" target="_blank">http://www.delph-in.net/2009/cm.pdf</a><br> LREC 2008 paper <a href="http://www.lrec-conf.org/proceedings/lrec2008/pdf/349_paper.pdf" rel="noreferrer" target="_blank">http://www.lrec-conf.org/proceedings/lrec2008/pdf/349_paper.pdf</a><br> <br> I've also been checking my understanding of the formalism by looking at the token mapping rules in the ERG 2018 directory tmr/. I have a few questions below which I've tried to contextualise with respect to the tutorial slides. I hope an expert can answer them.<br> <br> > Copying Information<br> > <br> > * reentrancies can be used to copy information from INPUT to OUTPUT<br> <br> Presumably reentrancies can also be used to copy information from CONTEXT to OUTPUT?<br> <br> > Chart Mapping Procedure<br> > <br> > * a rule match is completed if all CONTEXT and INPUT arguments are bound<br> <br> What happens if there are several ways of matching chart edges to CONTEXT in a rule? Is the rule applied repeatedly, once for each alternative match? Or is only one of the alternative matches considered? This could matter if feature values or regular expression captures are copied from the context to the output.<br> <br> > * each rule is applied until its fixpoint is reached<br> <br> If I've understood the formalism correctly, I can imagine a rule that doesn't ever reach a fixpoint for some inputs (e.g. a rule in which the input and output unify, with the output building structure). Is the intended interpretation the following: a rule is never applied more than once to the same combination of input and context edges? And it's up to the grammarian to avoid writing infinitely looping rules?<br> <br> If this is the correct interpretation, then I'm puzzled by a few rules in the ERG: bridge_tmr in tmr/bridge.tdl, and the four rules default_(ld|lb|rd|rb)_tmr in tmr/gml.tdl. Their inputs seem to unify with their outputs, so surely each would apply in an infinite loop (i.e. an input edge would match and be replaced with a new output edge, and since this new edge had not previously been used as an input the rule would pick this up and apply again, etc etc)?<br> <br> Aside from the fixpoint issue, I'm not sure I understand the purpose of the rules default_(ld|lb|rd|rb)_tmr. At first glance they seem to merely replace their input. Is their purpose to remove all features that are not specified on the input side?<br> <br> I'm also puzzled by the following comment on bridge_tmr:<br> <br> > ;; ... here, we take advantage of redundancy detection built into<br> > ;; token mapping, i.e. even though the rule is written as if it could apply any<br> > ;; number of times per cell, there shall not be duplicates in the token chart.<br> <br> What enforces the restriction that "there shall not be duplicates in the token chart"? I can't see any mention of redundancy detection or of this restriction in the paper or tutorial slides. Is the restriction somehow enforced by the fixpoint condition?<br> <br> Thanks in advance for clarification on these points.<br> <br> John<br> <br> <br> </blockquote></div></div> </div>