Re: binary search debugging of compilers

gah4 <gah4@u.washington.edu>
Sun, 14 May 2023 13:38:36 -0700 (PDT)

          From comp.compilers

Related articles
binary search debugging of compilers rsc@swtch.com (Russ Cox) (2023-05-12)
Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-13)
Re: binary search debugging of compilers pronesto@gmail.com (Fernando) (2023-05-13)
Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-14)
Re: binary search debugging of compilers tkoenig@netcologne.de (Thomas Koenig) (2023-05-14)
Re: binary search debugging of compilers gah4@u.washington.edu (gah4) (2023-05-14)
Re: binary search debugging of compilers cameron.mcinally@nyu.edu (Cameron McInally) (2023-05-14)
Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-15)
Re: binary search debugging of compilers 864-117-4973@kylheku.com (Kaz Kylheku) (2023-05-15)
Re: binary search debugging of compilers gah4@u.washington.edu (gah4) (2023-05-16)
Re: binary search debugging of compilers rsc@swtch.com (Russ Cox) (2023-05-17)
Re: binary search debugging of compilers cameron.mcinally@nyu.edu (Cameron McInally) (2023-05-17)
[13 later articles]
| List of all articles for this month |
From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Sun, 14 May 2023 13:38:36 -0700 (PDT)
Organization: Compilers Central
References: 23-05-003 23-05-005 23-05-006
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="85337"; mail-complaints-to="abuse@iecc.com"
Keywords: debug, tools
Posted-Date: 14 May 2023 22:42:20 EDT
In-Reply-To: 23-05-006

On Sunday, May 14, 2023 at 9:20:54 AM UTC-7, Kaz Kylheku wrote:


(snip)


> Setup:
>
> We can (somehow) enumerate the N entities with integers, which we
> express using a pure binary enumeration. Then, we can discover the
> number of an erroneously processed element, one bit at a time.
>
> Procedure:
>
> First we treat all elements numbered ..XXXXXX0 using the new technique
> technique, and all others using the the old technique. If the
> system fails, we know that it's the ..XXXXX0 set which has one or more
> badly processed elements. Otherwise it's the other set, whose
> enumerations end in a 1. Either way, we have discovered the identity of
> the last bit.


There is the assumtion that only one of the N is in error.


Reminds me of ECC memory, which can correct one bit errors, and detect
two bit errors. After log(N) tests, you find the one that it is
supposed to be, fix it, and it either works or doesn't.


Then you work on a new set of tests.


Or start out with a more complicated set, which can learn more in one set.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.