Next Meeting: July 7: Social gathering Next Installfest: TBD Latest News: Jun. 14: June LUGOD meeting cancelled Page last updated: 2001 Dec 30 17:02
Re: [vox-tech] detecting overflows

# Re: [vox-tech] detecting overflows

• Subject: Re: [vox-tech] detecting overflows
• From: jdnewmilMAPS@dcn.davis.ca.us
• Date: Mon, 12 Mar 2001 14:12:34 -0800
• References: 20010312100837.A28062@dirac.org

```On Mon, 12 Mar 2001, Peter Jay Salzman wrote:

> dear all,

Not my name... but I'll open my trap anyway... :)

>
> i have code which looks like:
>
>    long double dr;
>    long double dt;
>    long double rend;
>    long double ratio;
>    long int    N;
>    long unsigned int max_tstep;
>
>    ratio      = 2.0L;
>    N          = 800;
>    dr         = rend / ((long double)N - 1.0L);

what kind of number is "rend"? It isn't initialized here...

also..

dr         = rend / ((long double)(N - 1));

is more efficient and accurate.

>    dt         = ratio*pow(dr, 2.0L);

dt = ratio * dr * dr

is faster and numerically more stable.

>    max_tstep  = (long unsigned int) ceil(endtime / dt);
>
> sometimes ceil(endtime / dt) is very large, like 2.10944e+85.  this is too
> large even for a long long int.  max_tstep overflows.
>
> sometimes i don't catch the overflow, and my program can run for a long
> time, producing garbage.

The garbage results not because the program runs for a long time, but
because the number of iterations is wrong as a result of the
overflow... or is that right?

Is there some number of iterations beyond which your numerical errors
dominate? Shouldn't you limit your number of calculations anyway to avoid
this?

> is there some kind of flag that i can check that gets raised when a
> calculation overflows?   i have many such calculations (which are performed
> once at the beginning, so i'm not worried about performance penalty).
>
> i guess i can take a look at limit.h to and compare the maximum long
> unsigned int to the value of endtime / dt, but i'd prefer a different
> solution if one exists. surely there's got to be SOME way of detecting this
> kind of error?

To avoid division by zero, you usually check that the denominator is not
zero before proceeding.  To avoid inaccurate results, you may extend this
type of test to verify that abs(n) * epsilon < abs(d).  Your definition of
epsilon may depend on the problem at hand, so it is not a good idea to
depend on a library to make that decision for you.

IEEE 754 includes provisions for overflow notification through NaNs or
flags, but most implementations seem to support these features poorly.

There is also SVID math library, which calls a "matherr" function when a
library error occurs.  However, typecasting overflows would not be
affected by the use of matherr. (See
http://src.openresources.com/debian/src/libs/HTML/S/glibc-pre2.1_2.0.93-980414.orig\
%20glibc-pre2.1-2.0.93-980412.orig%20math%20test-matherr.c.html)

> i care not for portability.

Then at least care for reproducibility... and numerically unstable
calculations are difficult to reproduce independently.  Use sanity checks
to avoid singularities... don't depend on the defaults to do it for you.

[...]

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
Work:<JeffN@endecon.com>              Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------

```