underflow exception (was Re: float limits)

Alexandre Fayolle alf at leo.logilab.fr
Fri Feb 1 04:40:38 EST 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.

Alexandre Fayolle
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 mailing list