[TUHS] Re: undiagnosed pic error

[TUHS] Re: undiagnosed pic error

[Douglas McIlroy]

There may be a simple generic way to correct pic's habit of accepting
any set of object modifiers on any object, but obeying only a
compatible subset.

Pic already collects a bit vector of modifier types attached to the
current object. If that were extended with a few more bits that
designate the object types, the size, B, of the bit vector would be
about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could
record both modifier/modifier incompatibilities and object/modifier
incompatibilities. The collected bit vector needs to be tested against
the matrix once per object definition.

It seems to be harder to catch duplication of modifiers, requiring
extra code at all points where bits are set. Nevertheless, this kind
of error also merits detection.

Some questions

Does anybody think the issue is not worth addressing?

Is there a better scheme than that suggested above?

Is the scheme adequate? It would not, for example, catch a three-way
incompatibility that does not entail any pairwise incompatibility,
should such an incompatibility exist.

Any other thoughts?

Doug

[TUHS] Re: undiagnosed pic error

[Marc Donner]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

How sparse is the 35x35 matrix?  For comprehensibility would it be the best
way to do it?

On Tue, Jun 13, 2023 at 9:59 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> There may be a simple generic way to correct pic's habit of accepting
> any set of object modifiers on any object, but obeying only a
> compatible subset.
>
> Pic already collects a bit vector of modifier types attached to the
> current object. If that were extended with a few more bits that
> designate the object types, the size, B, of the bit vector would be
> about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could
> record both modifier/modifier incompatibilities and object/modifier
> incompatibilities. The collected bit vector needs to be tested against
> the matrix once per object definition.
>
> It seems to be harder to catch duplication of modifiers, requiring
> extra code at all points where bits are set. Nevertheless, this kind
> of error also merits detection.
>
> Some questions
>
> Does anybody think the issue is not worth addressing?
>
> Is there a better scheme than that suggested above?
>
> Is the scheme adequate? It would not, for example, catch a three-way
> incompatibility that does not entail any pairwise incompatibility,
> should such an incompatibility exist.
>
> Any other thoughts?
>
> Doug
>
-- 
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

[-- Attachment #2: Type: text/html, Size: 2105 bytes --]

[TUHS] Re: undiagnosed pic error

[Douglas McIlroy]

It's fairly sparse, e.g. "at" is compatible with most everything
except "from" and "to". Setup might look like this:

long int compat[] = {
[HAS_AT] = HAS_FROM | HAS_TO,


On Wed, Jun 14, 2023 at 6:42 AM Marc Donner <marc.donner@gmail.com> wrote:
>
> How sparse is the 35x35 matrix?  For comprehensibility would it be the best way to do it?
>
> On Tue, Jun 13, 2023 at 9:59 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>>
>> There may be a simple generic way to correct pic's habit of accepting
>> any set of object modifiers on any object, but obeying only a
>> compatible subset.
>>
>> Pic already collects a bit vector of modifier types attached to the
>> current object. If that were extended with a few more bits that
>> designate the object types, the size, B, of the bit vector would be
>> about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could
>> record both modifier/modifier incompatibilities and object/modifier
>> incompatibilities. The collected bit vector needs to be tested against
>> the matrix once per object definition.
>>
>> It seems to be harder to catch duplication of modifiers, requiring
>> extra code at all points where bits are set. Nevertheless, this kind
>> of error also merits detection.
>>
>> Some questions
>>
>> Does anybody think the issue is not worth addressing?
>>
>> Is there a better scheme than that suggested above?
>>
>> Is the scheme adequate? It would not, for example, catch a three-way
>> incompatibility that does not entail any pairwise incompatibility,
>> should such an incompatibility exist.
>>
>> Any other thoughts?
>>
>> Doug
>
> --
> =====
> nygeek.net
> mindthegapdialogs.com/home

[TUHS] Re: undiagnosed pic error

[Douglas McIlroy]

Google claims I just sent another unintended reply, this time unfinished.

Apologies,
Doug

On Wed, Jun 14, 2023 at 6:42 AM Marc Donner <marc.donner@gmail.com> wrote:
>
> How sparse is the 35x35 matrix?  For comprehensibility would it be the best way to do it?
>
> On Tue, Jun 13, 2023 at 9:59 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>>
>> There may be a simple generic way to correct pic's habit of accepting
>> any set of object modifiers on any object, but obeying only a
>> compatible subset.
>>
>> Pic already collects a bit vector of modifier types attached to the
>> current object. If that were extended with a few more bits that
>> designate the object types, the size, B, of the bit vector would be
>> about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could
>> record both modifier/modifier incompatibilities and object/modifier
>> incompatibilities. The collected bit vector needs to be tested against
>> the matrix once per object definition.
>>
>> It seems to be harder to catch duplication of modifiers, requiring
>> extra code at all points where bits are set. Nevertheless, this kind
>> of error also merits detection.
>>
>> Some questions
>>
>> Does anybody think the issue is not worth addressing?
>>
>> Is there a better scheme than that suggested above?
>>
>> Is the scheme adequate? It would not, for example, catch a three-way
>> incompatibility that does not entail any pairwise incompatibility,
>> should such an incompatibility exist.
>>
>> Any other thoughts?
>>
>> Doug
>
> --
> =====
> nygeek.net
> mindthegapdialogs.com/home

[TUHS] Re: undiagnosed pic error

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]

You did.

You forgot the trailing }


Syntax error

See previous email...


On Sat, Jun 17, 2023, 12:00 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> Google claims I just sent another unintended reply, this time unfinished.
>
> Apologies,
> Doug
>
> On Wed, Jun 14, 2023 at 6:42 AM Marc Donner <marc.donner@gmail.com> wrote:
> >
> > How sparse is the 35x35 matrix?  For comprehensibility would it be the
> best way to do it?
> >
> > On Tue, Jun 13, 2023 at 9:59 PM Douglas McIlroy <
> douglas.mcilroy@dartmouth.edu> wrote:
> >>
> >> There may be a simple generic way to correct pic's habit of accepting
> >> any set of object modifiers on any object, but obeying only a
> >> compatible subset.
> >>
> >> Pic already collects a bit vector of modifier types attached to the
> >> current object. If that were extended with a few more bits that
> >> designate the object types, the size, B, of the bit vector would be
> >> about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could
> >> record both modifier/modifier incompatibilities and object/modifier
> >> incompatibilities. The collected bit vector needs to be tested against
> >> the matrix once per object definition.
> >>
> >> It seems to be harder to catch duplication of modifiers, requiring
> >> extra code at all points where bits are set. Nevertheless, this kind
> >> of error also merits detection.
> >>
> >> Some questions
> >>
> >> Does anybody think the issue is not worth addressing?
> >>
> >> Is there a better scheme than that suggested above?
> >>
> >> Is the scheme adequate? It would not, for example, catch a three-way
> >> incompatibility that does not entail any pairwise incompatibility,
> >> should such an incompatibility exist.
> >>
> >> Any other thoughts?
> >>
> >> Doug
> >
> > --
> > =====
> > nygeek.net
> > mindthegapdialogs.com/home
>

[-- Attachment #2: Type: text/html, Size: 2978 bytes --]