Re: Generalised bisection

[John Tapsell <johnflux@gmail.com>]

2009/3/16 Steven Tweed <orthochronous@gmail.com>:
> On Sun, Mar 15, 2009 at 7:16 PM, Ealdwulf Wuffinga
> <ealdwulf@googlemail.com> wrote:
>> On Fri, Mar 13, 2009 at 3:19 PM, Steven Tweed <orthochronous@gmail.com> wrote:
>> It is not obvious how to perform this algorithm incrementally, because
>> of the need to
>> marginalise out the fault rate. As I understand it, marginalisation
>> has to be done after you
>> have incorporated all your information into the model, which means we
>> can't use the
>> usual bayesian updating.
>
> I had a look over the weekend, and got a bit sidetracked on one of
> your assumptions. You seem to be assuming that the bug is such that
> observing a single positive observation of the symptom at a position i
> in the linear history _does not_ completely rule out that the guilty
> commit occurs after that point. I would have thought the generally
> more applicable assumption is that, given that generally you don't
> have a bug ridden system where more than one bug causes the same
> symptom _within the history of interest_, that a single observation of
> the symptom does totally rule out the bug after that point (whilst
> intermittency clearly not having observed the bug before that point
> doesn't completely rule out the guilty commit being earlier, although
> it should increase the liklihood estimate of the bug being later).

I think it's reasonable to expect false-positives as well as
false-negatives.  e.g. you're looking for a commit that slows down the
frame rate.  But on one of the good commits the hard disk hits a bad
sector and takes a bit longer to retrieve data and so you get a
false-positive.

It's a bit contrived, but I'm sure you can think of better example

John