ah, these are potentially rather interesting.  until a few weeks ago, (a) PET was not checking for cycles in testing against start symbols (‘sponsors’ in [incr tsdb()] jargon) and (b) [incr tsdb()] was not testing against start symbols during reconstruction.  thus, it is tempting to suspect that these derivations in the gold treebanks would no longer be abailable (with these start symbols) from a current PET (or any other compliant DELPH-IN parser-generator).  dan and i should look at these more and decide on the impact for the imminent 1212 release.<div>
<br></div><div>to work around this problem, ned, i recommend you look for the right [incr tsdb()] variable near the top of ‘redwoods.lisp’ and set it to nil, to suppress testing of start symbols during reconstruction (i.e. what used to be the <span></span>[incr tsdb()] default bahavior until recently).</div>
<div><br></div><div>thanks for alerting us to this issue!  oe</div><div><br><br>On Wednesday, July 17, 2013, Ned Letcher  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Well that makes sense about different versions of the grammar. I had just been assuming I was using the same version without really thinking about whether this was true.<div><br></div><div>I am indeed using the up to date logon. There were also a couple of other problematic items from wescience once I finished process it. Here they all are along with the resultant diagnostic message from [incr tsdb()] after attempting interacting reconstruction.</div>

<div><br></div><div><div>10820520 ws13 incompatible sponsor `ROOT_STRICT&#39;.</div><div>10400970 ws07 incompatible sponsor `ROOT_STRICT&#39;.</div><div>10090110 ws02 incompatible sponsor `ROOT_STRICT&#39;.</div><div>10052180 ws02 incompatible sponsor `ROOT_STRICT&#39;.</div>

<div>10012800 ws01 incompatible sponsor `ROOT_INFORMAL&#39;.</div></div><div><br></div><div>Ned</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, Jul 17, 2013 at 1:08 AM, Stephan Oepen <span dir="ltr">&lt;<a href="javascript:_e({}, &#39;cvml&#39;, &#39;oe@ifi.uio.no&#39;);" target="_blank">oe@ifi.uio.no</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

hi ned,<div><br></div><div>your code looks plausible, and i too would think all derivations in 1212 treebanks should reconstruct successfully (when using the 1212 ERG).  emily rightly cautions this will typically not be the case for the ERG trunk: the treebanks are not maintained up-to-date for each incremental revision in the grammar.</div>


<div><br></div><div>which leaves us to worry about that one WS01 item.  are you sure your LOGON tree is up-to-date (1212 has not been formally released, and there were a few minor updates after tagging the initial release candidate)?  if so, could you ‘Browse|Results’ on WS01, then double-click on the red 1 in the derivations column of the problematic item, then double-click on the (red) derivation.  this will trigger interactive reconstruction, and assuming the derivation really is problematic, there will be diagnostic message in the *common-lisp* buffer.  what does it say?</div>


<div><br></div><div>best, oe</div><div><div><div><br></div><div><span></span><br>On Wednesday, July 17, 2013, Ned Letcher  wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr">Hi all,<div><br></div><div>I&#39;ve run into some strange behaviour which I&#39;m hoping someone can shed some light on. I&#39;ve got some lisp code I&#39;m using to reconstruct the spanning edge of the first reading for items in profiles:</div>



<div><br></div><div><div>(defun get-item (i-id profile)</div><div>  (first (tsdb::analyze profile </div><div>                        :condition (format nil &quot;i-id == ~a&quot; i-id)</div><div>                        :thorough &#39;(:derivation))))</div>



<div>(defun get-item-edge (item) </div><div>  (tsdb::reconstruct </div><div>   (tsdb::get-field :derivation </div><div>                    (first (tsdb::get-field :results item)))))</div><div><br></div><div>The problem is that get-item-edge is returning nil for some items even though they have derivations. For instance I get a nil result for item 10012800 in ws01 using erg 1212 but all the other parsing items from this profile are fine:</div>



<div><br></div><div>(read-script-file-aux &quot;~/logon/lingo/erg/lkb/script&quot;)<br></div><div>(get-item-edge (get-item &quot;10012800&quot; &quot;/gold/erg/ws01&quot;))<br></div><div>(get-item-edge (get-item &quot;10012820&quot; &quot;/gold/erg/ws01&quot;))<br>



</div><div><br></div><div>I&#39;m also getting many more of these nil results when running using trunk erg compared to 1212. When restricted to items with readings, running over ws01, I get only 1 of these nil results for 1212 and 73 for trunk erg. csli yields none with 1212 and 1 of these with trunk erg.</div>



<div><br></div><div>Ned<br></div><div><br></div><div><br></div>-- <br><a href="http://nedned.net" target="_blank">nedned.net</a>
</div></div>
</blockquote></div><br><br></div></div><span><font color="#888888">-- <br>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125<br>

+++    --- <a href="javascript:_e({}, &#39;cvml&#39;, &#39;oe@ifi.uio.no&#39;);" target="_blank">oe@ifi.uio.no</a>; <a href="javascript:_e({}, &#39;cvml&#39;, &#39;stephan@oepen.net&#39;);" target="_blank">stephan@oepen.net</a>; <a href="http://www.emmtee.net/oe/" target="_blank">http://www.emmtee.net/oe/</a> ---<br>


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://nedned.net" target="_blank">nedned.net</a>
</div></div>
</blockquote></div><br><br>-- <br>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125<br>+++    --- <a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>; <a href="mailto:stephan@oepen.net" target="_blank">stephan@oepen.net</a>; <a href="http://www.emmtee.net/oe/" target="_blank">http://www.emmtee.net/oe/</a> ---<br>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br><br>