[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: t_ncxx - DOUBLE_MAX problem

> Subject: t_ncxx - DOUBLE_MAX problem
>
> hey there,
>
> after playing around a bit I think I have the apparent problem nailed down..
>
> I added the lines
> double temp = X_DOUBLE_MAX;
> double temp2 = 1.6976e308;
>
> to the t_ncxx program and discovered that my compiler (watcom 10.6 win95)
> appears not to like your chosen X_DOUBLE_MAX number (1.7976...e308) .. and
> stores that in my temp var as 0.
>
> The temp2 shows up fine.. so what I did was to change the X_DOUBLE_MAX to
> 1.69...e_308 and everything seems to run fine...
>
> soo.. I assume you chose this value for some reason, but my guess is that it
> pushes past some defined limit in my compiler..
>

(Intel hardware has IEEE floating point.)
IEEE floating point. It is the maximum ieee double which is not ieee
ieee double infinity. It is about (1 - 1.1102230246251565e-16) * 2**1024.

Your compiler is not scanning the constant properly. (Historically, this
is a fairly common problem.) You can substitute whatever value your compiler
#include system has for DBL_MAX, if available. Usually DBL_MAX is defined in
<float.h> or <limits.h> You can also try <math.h>.

If DBL_MAX isn't available,
and the scalb() function (or the ldexp() function) is available, you can do
something like

/* ncx.h */
#include <math.h>
extern const double x_double_max;
#define X_DOUBLE_MAX x_double_max

/* ncx.c */
const double x_double_max = scalb(1. - 1.1102230246251565e-16, (double)1024);

You can also try just printing x_double_max as computed above,
and using that in the #define.

You should probably use the largest value your compiler can scan successfully.
Doubling the 1.11...e-16 fuzz factor (to drop another bit off the mantissa)
gives 1.7976931348623155e+308 on my system. You can probably do better than the
1.69...e_308 number.

-glenn