[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