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:
2002 Mar 14 09:25

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] help with signals and C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] help with signals and C

begin Mark K. Kim <markslist@cbreak.org> 
> keywords: signal, signals, SIGFPE, floating point numbers, inf, nan
> keywords: divide-by-zero, round-off error
> Pete,
> Your test program works if you do an integer division, but not for
> floating point division.  I think I read on one of Jeff's links that
> SIGFPE isn't just for floating point numbers, so perhaps division by zero
> is caught only for integer division on x86.
hi mark,

yeah, i read about this in jeff's 1st link.  i'm not really doing much
integer stuff, so it wasn't an issue and i didn't check it.  interesting
that integer divide by zero gets caught!

> I'm not sure what kind of errors your program would have if it's not
> generating "inf" or "nan".  If you're getting calculations errors, I think
> you're getting floating point round-off errors, rather than
> overflow/underflow.  If that's the case, you'd need a higher precision
> numbers (double, long double, or the arbitrary-precision numbers
> library...)


temperature = 1.0

trials          Energy per site
1,000          -2.000000
10,000         -1.998448
100,000        -1.997171
1,000,000      -1.997530
10,000,000     -1.997312           <-- very close
100,000,000   -14.163610           <-- very not correct

> One more thing - If you have a really big number plus a really small
> number, the smaller number gets thrown out.

yeah, i know.  the details are actually outlined in float.h where alot
of limits of computation are given, like the max normalized double, max
integer N such that 2.0^N is a normalized long double, etc.

> In that case, you'll need a
> really high precision number type that can span across the big and the
> small number to avoid the round-off error.  If you have this type of
> problem, and if you can't use the high-enough precision number type
> (either because you don't have one available or it's too slow), there's no
> way around it except rewriting the code.

mark, did you mention arbitrary precision library?  just out of
curiosity, what is it called?

vox-tech mailing list

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:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.