From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25712 invoked from network); 14 Jun 2023 10:42:27 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2023 10:42:27 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 9263440C02; Wed, 14 Jun 2023 20:42:21 +1000 (AEST) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) by minnie.tuhs.org (Postfix) with ESMTPS id 11A9440BD8 for ; Wed, 14 Jun 2023 20:42:07 +1000 (AEST) Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-555508fd7f9so354726eaf.3 for ; Wed, 14 Jun 2023 03:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686739326; x=1689331326; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jD/nN/Oh9Tqi1moKO8kLNmlKSTh7viNns5b47q+rtmY=; b=PSDLyYc3S28LlreOvPv/8D90bqF3WacjbkUK2++E8H7GZcQFY2/YrcmqiTLl1j5a8Q NjHPXpHEYvJ3JxzRCht2ncjDQUr6JDlT/SieX61rELmwzQ5f4x4FOuPuIZDZF5QDFnmw lM2+4LlMF2IcxobuAG0ex7TP3bznPUnJkNgidKP5nkOfCSvv4Py6xlrb0BiXW/Y/EWFs PcnZBIWpi7vk5ltn5Sf9+HM1PhbBX5KbImQ9pdM8w5jZ+ZLZPngPuwQCCVpCSa4vm1HZ Px9XfdK2d8aebDj8dk6CTFfRKQnYVN+xZqB7YMpTcr/OXIRjNBm66A4S/tO7lFlMcWNt UkXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686739326; x=1689331326; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jD/nN/Oh9Tqi1moKO8kLNmlKSTh7viNns5b47q+rtmY=; b=cEhMNH9cnAeXMGbNh+vfBqs7mGb3afQXx1wkZWOnf9gLZv4VBajQjyZohzx8WXhDDd 0bQUMo4sI+NLUUjaT0wCLVAHVhIH4ewolIJFaFn6+3sB3aOe2AHWfMaWNvxbBAc+auuE momdl3JbxOkogy7+UKDJrV/Dtgz3tc1LhH3JjsK/TuWnCikSwrVbEbuPLSFH0KoAMZFf xmZJZhXTpsXKMYWTlYqSSgKky57s/qazuXRyYwcQwso2gvcFhv8Wl6ulkbo/9U/X5iFq 1XomyXmZ+IKJYBL3Brx577F4BRniGq88SOoGoPqm6g2kMzREqc3ZXLCD1U3ciPtOwqFi UDnA== X-Gm-Message-State: AC+VfDwOmNv4CCA6dY0SnmExE1B4bUUzn31mFZ3bZaAk3NaVXfbe7y08 1k87gd6yMzQQQxax9Qb6sw925NxjvIeLqhLcj8I= X-Google-Smtp-Source: ACHHUZ7QddhrAxB6Hgg4mPzK7ailY+cwAs9nJwi6GTP1ruQMGAm1kUXq/+kL0uW9LIKWkCdA2sKdNTyFjwQG34vJoyE= X-Received: by 2002:a4a:a50e:0:b0:558:ad63:af2d with SMTP id v14-20020a4aa50e000000b00558ad63af2dmr8783622ook.8.1686739325759; Wed, 14 Jun 2023 03:42:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marc Donner Date: Wed, 14 Jun 2023 06:41:53 -0400 Message-ID: To: Douglas McIlroy Content-Type: multipart/alternative; boundary="0000000000005734ae05fe149a4f" Message-ID-Hash: S6NX77O56N2KH5JRIPS47WKGIAFNA4IO X-Message-ID-Hash: S6NX77O56N2KH5JRIPS47WKGIAFNA4IO X-MailFrom: marc.donner@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: TUHS main list X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: undiagnosed pic error List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000005734ae05fe149a4f Content-Type: text/plain; charset="UTF-8" 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 --0000000000005734ae05fe149a4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How sparse is the 35x35 matrix?=C2=A0 For comprehensibili= ty would it be the best way to do it?

On Tue, Jun 13, 2023 at 9:59 PM D= ouglas McIlroy <douglas= .mcilroy@dartmouth.edu> wrote:
There may b= e 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
-- <= br>
--0000000000005734ae05fe149a4f--