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: Sun, 15 Mar 2009 19:16:16 +0000	[thread overview]
Message-ID: <efe2b6d70903151216q4a8881e5t797cf5d3bebc5697@mail.gmail.com> (raw)
In-Reply-To: <d9c1caea0903130819u770686b1w867f074ffef8fabf@mail.gmail.com>

On Fri, Mar 13, 2009 at 3:19 PM, Steven Tweed <orthochronous@gmail.com> wrote:

> Underflow when using probabilities and lack of precision (rather than
> overflow) when using negated logarithms are well known problems in the
> kind of probabilistic object tracking, inference in graphical networks
> and object identification processes I work with (in computer vision).
> I there may well be other areas of Bayesian decision theory where this
> doesn't happen, and indeed a _very_ quick scan through your document
> suggests that you're adding to tallying information on each timestep
> and recalcuating the entire model from those tallys, which is one of
> the few cases where you can't really do rescaling. I'll try and have a
> more detailled read over the weekend.

That is useful information, thanks.

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.

> On Fri, Mar 13, 2009 at 12:49 PM, Ealdwulf Wuffinga
> <ealdwulf@googlemail.com> wrote:
>> One issue in BBChop which should be easy to fix, is that I use a dumb
>> way of calculating Beta functions. These
>> are ratios of factorials, so the subexpressions get stupidly big very
>> quickly. But I don't think that is the only problem.
>
> Yes, "Numerical Recipes" seems to suggest that computing with
> log-factorials and exponentiating works reasonably, although I've
> never tried it and NR does occasionally get things completely wrong...

I have implemented this and it does indeed allow the program to work
in more cases
without underflow, with ordinary floating point. However, I think the
underflow can still occur
in plausible use cases.

The problem is still the Beta function. In bbchop it is always passed
D and T where D is
the sum of the number of detecting observations in some of the
revisions, and T is the
same for nondetecting observations. Beta(x,y) underflows a python float
if both x and y are > ~550, and also in other cases when one is
smaller and the other,
larger. BBChop never looks again at a revision if the bug has been
observed there, but if
there are a large number of revisions, it might look at enough of them
to cause a problem.

Obviously no-one is going to manually do hundreds of observations, but
 I want BBChop
to work in the case where someone runs it on a machine in the corner
for a few days,
or even weeks,  to track down a bug which occurs too infrequently to
bisect manually.

Which means I'm still stuck with mpmath, or some equivalent.

Ealdwulf

  reply	other threads:[~2009-03-15 19:17 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 [this message]
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
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=efe2b6d70903151216q4a8881e5t797cf5d3bebc5697@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.