underflow exception (was Re: float limits)
alf at leo.logilab.fr
Fri Feb 1 10:40:38 CET 2002
On Thu, 31 Jan 2002 18:42:33 -0500, Tim Peters <tim.one at home.com> wrote:
>In that case I'd try explicitly checking the intermediate products, from
>time to time, to see whether they've gotten so small as to be
>indistinguishable from 0 for the app's purposes. Depending on the whole
>algorithm, it may be quite sensible to treat a probability of (say) 1e-20 as
>if exactly zero, and may even speed things up to do so. The difference
>between a probability of 1e-100 and one of 1e-300 has no consequence in any
>universe I've visited <wink>, and if so there's no point burning cycles to
>put an ever-finer point on a useless distinction.
I would have agreed with you, but in this case, there is a point, because
these small values are not probabilities, but they are used to compute
probabilities from other probabilities. The algorithm I use has something
like pi = a/b where both a and b are in the aforementionned order of magnitude
(they can be expressed roughly as the products of 100~1000 floats smaller than
The solution is to use a clever scaling of a and b to avoid numerical
underflow, but the computation of the scaling factor is a costly operation,
so I'd like to perform it only when needed. Right now, the scaling is triggered
by a division by zero, but I'm afraid this is too late, and that some of the
terms already have been rounded down. I'll probably have to add an explicit
check that the values are not getting smaller than 1e-200, and trigger the
scaling at that point instead of relying on the exception.
By the way, in case you're interested, the module I'm working on is for
training hidden markov models (HMMs). It's available at
Thanks for your advice.
LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
Narval, the first software agent available as free software (GPL).
More information about the Python-list