[developers] LKB vs. PET divergences
johnca at sussex.ac.uk
johnca at sussex.ac.uk
Tue Feb 15 17:26:21 CET 2005
Quoting Ann Copestake <Ann.Copestake at cl.cam.ac.uk>:
>
> > There's just not
> > much freedom to do things differently, or incorrectly.
>
> I recall a series of cases where we had differences in the past.
> Anyway, do
> you have a formal definition anywhere? The situation is analogous
> to:
>
> a := top.
>
> b := top.
>
> c := top.
>
> d := a & b & c.
>
> e := a & b & c.
>
> where what's happening now in the LKB is that we introduce a glb as
> follows:
>
> glb := a & b & c.
>
> d := glb.
>
> e := glb.
>
> I am reasonably certain that we discussed this a few years ago and
> agreed this
> was the preferred behaviour, but I am not sure that I could decide
> for more
> complex cases. It'd be nice to have a declarative definition
> somewhere.
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
For Ann's example:
a := top.
b := top.
c := top.
d := a & b & c.
e := a & b & c.
the types might get the following codes:
e 100000
d 010000
c 111000
b 110100
a 110010
top 111111
and one new glb type would be constructed, with code 110000. This would be inserted into
the type hierarchy between a,b,c and d,e.
John
More information about the developers
mailing list