[developers] LKB vs. PET divergences

Ann Copestake Ann.Copestake at cl.cam.ac.uk
Tue Feb 15 23:07:08 CET 2005


thanks.  Just to make sure I understand something (I've just checked the code) 
- when the process is iterated for the new glbtypes, you just iterate it on 
pairs of new types and you don't add any further bits.  So this is just for 
the case where two distinct glb types have a set of descendants in common 
which doesn't correspond to any existing type.

> I'm not sure how to express this declaratively, but the LKB does the following:
> 
> for each type, assign it a code which is the logical OR of its subtypes' codes with one 
> additional unique bit set
> 
> for every pair of types
>   if they have one or more common subtypes (i.e. the logical AND of the type codes is non-
> zero)
>     but no type currently exists with exactly this code
>   then add a newly constructed glb type with this code
> iterate this process with any new glb types
> 
> insert the newly constructed glb types at approriate points in the type hierarchy, according to 
> their codes

If so, I believe I can declaritivize this in terms of a notion of the set of 
subtypes of a type t, and making a distinction between the original types and 
the glbtypes.  I'm not sure this is very revealing, but it might be worth 
writing down somewhere.

BTW, when I looked at the code, I couldn't see why in check-type-table the 
partitions were being sorted.  I think this may be a hang-over from the old 
code?  This isn't going to give a unique ordering on partitions since there 
may be two the same length, so the glb numbering won't necessarily be 
consistent.

(dolist
               (partition
                  ;; sort so behaviour reproducible if grammar has not changed
                  (sort *partitions* #'> :key #'length))
               (setq glbp (compute-and-add-glbtypes partition glbp)))

Ann





More information about the developers mailing list