l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:02

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] detecting overflows
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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...


   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

> 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

> 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

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.