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] |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.