First, make sure that you have #included
<math.h>, and correctly
declared other functions returning
If the problem isn't that simple, recall that most digital computers use floating-point formats which provide a close but by no means exact simulation of real number arithmetic. Underflow, cumulative precision loss, and other anomalies are often troublesome.
Don't assume that floating-point results will be exact, and especially don't assume that floating-point values can be compared for equality. (Don't throw haphazard "fuzz factors" in, either.)
These problems are no worse for C than they are for any other computer language. Floating-point semantics are usually defined as "however the processor does them;" otherwise a compiler for a machine without the "right" model would have to do prohibitively expensive emulations.
This article cannot begin to list the pitfalls associated with, and workarounds appropriate for, floating-point work. A good programming text should cover the basics.
References: EoPS Sec. 6 pp. 115-8.
<math.h>, but I keep getting "
undefined: _sin" compilation errors.
Make sure you're linking with the correct math library. For
instance, under Unix, you usually need to use the
and at the end of the command line, when compiling/linking.
See also question 12.14.
Because few processors have an exponentiation instruction.
Instead, you can
#include <math.h> and use the
although explicit multiplication is often better for small
positive integral exponents.
References: ANSI Sec. 188.8.131.52 .
The simplest and most straightforward way is with code like
(int)(x + 0.5)
This won't work properly for negative numbers, though.
Many systems with high-quality IEEE floating-point implementations provide facilities (e.g. an isnan() macro) to deal with these values cleanly, and the Numerical C Extensions Group (NCEG) is working to formally standardize such facilities. A crude but usually effective test for NaN is exemplified by
#define isnan(x) ((x) != (x))
although non-IEEE-aware compilers may optimize the test away.
Some compilers for small machines, including Turbo C (and
Ritchie's original PDP-11 compiler), leave out floating point
support if it looks like it will not be needed. In particular,
the non-floating-point versions of printf and scanf save space
by not including code to handle
%g. It happens that
Turbo C's heuristics for determining whether the program uses
floating point are insufficient, and the programmer must
sometimes insert an extra, explicit call to a floating-point
library routine to force loading of floating-point support.