All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ealdwulf Wuffinga <ealdwulf@googlemail.com>
To: Steven Tweed <orthochronous@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	John Tapsell <johnflux@gmail.com>,
	Christian Couder <chriscool@tuxfamily.org>,
	Git List <git@vger.kernel.org>
Subject: Re: Generalised bisection
Date: Mon, 16 Mar 2009 22:08:15 +0000	[thread overview]
Message-ID: <efe2b6d70903161508i19c16f6bm7f695452748a06a1@mail.gmail.com> (raw)
In-Reply-To: <d9c1caea0903160329v3c1a1600m9913eafa00cc2f37@mail.gmail.com>

On Mon, Mar 16, 2009 at 10:29 AM, Steven Tweed <orthochronous@gmail.com> wrote:

> 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 must have been unclear somewhere, because I do indeed assume that
a single observation of the symptom rules out the origin of the bug being
later than that observation.

 If you have a play with the software in manual mode, you can see that its
behaviour reflects this  - it starts out doing something like an
ordinary binary search, albeit skewed towards older revisions (it
seems to go for
a roughly 1:2 division, rather than the usual 1:1). Then once it has got to the
point where a deterministic search would end, it hammers away at the parent(s)
of the newest revision where the fault was observed, until it is satisfied that
it cannot be found there. All this just emerges from the generic least-entropy
algorithm; I didn't know what it would do until I got it running.

> I wonder what your thoughts are on this? (I started formulating a
> model over the weekend, but work is a bit hectic so I may not get to
> write it up in LaTeX very quickly.)

It will be interesting to see whether your model turns out to be different from
mine. I'm only doing this in my spare time, so I'm in no hurry.

Ealdwulf

  parent reply	other threads:[~2009-03-16 22:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09  1:40 Generalised bisection Ealdwulf Wuffinga
2009-03-10  7:08 ` Christian Couder
2009-03-11  8:59   ` Ealdwulf Wuffinga
2009-03-11  9:35     ` John Tapsell
2009-03-11 12:05       ` Johannes Schindelin
2009-03-11 12:08         ` John Tapsell
2009-03-11 13:04           ` Johannes Schindelin
2009-03-11 13:24             ` John Tapsell
2009-03-11 22:14               ` Ealdwulf Wuffinga
2009-03-11 22:15       ` Ealdwulf Wuffinga
2009-03-12  6:45         ` John Tapsell
2009-03-12 10:55           ` Johannes Schindelin
2009-03-12 18:02             ` Steven Tweed
2009-03-13 10:00               ` Ealdwulf Wuffinga
2009-03-13 12:49               ` Ealdwulf Wuffinga
2009-03-13 15:19                 ` Steven Tweed
2009-03-15 19:16                   ` Ealdwulf Wuffinga
2009-03-16 10:29                     ` Steven Tweed
2009-03-16 10:37                       ` John Tapsell
2009-03-16 22:47                         ` Ealdwulf Wuffinga
2009-03-16 22:08                       ` Ealdwulf Wuffinga [this message]
2009-03-13  9:58           ` Ealdwulf Wuffinga
2009-03-13 10:55             ` Johannes Schindelin
2009-03-13 12:42               ` John Tapsell
2009-03-13 13:56                 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=efe2b6d70903161508i19c16f6bm7f695452748a06a1@mail.gmail.com \
    --to=ealdwulf@googlemail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=johnflux@gmail.com \
    --cc=orthochronous@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.