… why I get two different numbers …
Aside from the usual float-point issues, the computation paths to b
and c
are arrived in different ways. c
is calculated by first saving the value as double a
.
double a =(Vmax-Vmin)/step;
int b = (Vmax-Vmin)/step;
int c = a;
C allows intermediate floating-point math to be computed using wider types. Check the value of FLT_EVAL_METHOD
from <float.h>
.
Except for assignment and cast (which remove all extra range and precision), …
-1 indeterminable;
0 evaluate all operations and constants just to the range and precision of the
type;1 evaluate operations and constants of type
float
anddouble
to the
range and precision of thedouble
type, evaluatelong double
operations and constants to the range and precision of thelong double
type;2 evaluate all operations and constants to the range and precision of the
long double
type.C11dr ยง5.2.4.2.2 9
OP reported 2
By saving the quotient in double a = (Vmax-Vmin)/step;
, precision is forced to double
whereas int b = (Vmax-Vmin)/step;
could compute as long double
.
This subtle difference results from (Vmax-Vmin)/step
(computed perhaps as long double
) being saved as a double
versus remaining a long double
. One as 15 (or just above), and the other just under 15. int
truncation amplifies this difference to 15 and 14.
On another compiler, the results may both have been the same due to FLT_EVAL_METHOD < 2
or other floating-point characteristics.
Conversion to int
from a floating-point number is severe with numbers near a whole number. Often better to round()
or lround()
. The best solution is situation dependent.