[Top][All Lists]

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

Re: [Help-gsl] IEEE doubles/ANSI C questions

From: Michael Mair
Subject: Re: [Help-gsl] IEEE doubles/ANSI C questions
Date: Fri, 29 Oct 2004 19:38:24 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1

Hello Brian,

thank you very much for your answer!

Brian Gough wrote:
Michael Mair writes:
 >    Even if we for a moment assume that C doubles on the considered
 >    architectures are IEEE doubles, there is the still the
 >    overprecision on x86 systems, so the result will of course not
 >    be the same if -ffloat-store is not used (which OTOH would
 >    deteriorate the performance considerably).

x86 chips can be put in double precision mode (which is much more
efficient than -ffloat-store).  It happens that the default with most
operating systems is to use extended precision mode, but it's not
necessary.  See the IEEE chapter for details.

I shall -- that is really interesting. I had some problems when
I gave as an exercise to my students to find out FLT_EPSILON,
DBL_EPSILON, and LDBL_EPSILON (without trying out all ways to do
it) and the (double) casts did not work; we just used -ffloat-store
which just is close to insane.
So, next time, when this comes around, I will know better :-)

 >    Is there a better rationale why one should not prefer long
 >    double?

The size of double is specifically defined (52bit mantissa), while
long double size is always implementation dependent.

Umh, the C standard just demands
 DBL_EPSILON <= 1e-9
 DBL_MAX >= 1e37
 DBL_MIN >= 1e-37
which is why I asked for a "better" rationale than hoping that
double equals IEEE double; or is it demanded that __STDC_IEC_559__
(means: conforming with IEC559/IEEE754) is defined?

 >    Now, I would like to know whether there are experiences or
 >    known problems using GSL with C99 (or the gcc C99 subset
 >    available by gcc -std=c99 -pedantic). The semantics of the
 >    inline keyword differ in gcc -std=gnu89 and C99, but maybe the
 >    referred-to extended autoconf checking helps finding out
 >    whether this works or not.

I haven't tested it with -std=c99 -pedantic but I wouldn't expect any

Sounds good :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]