Re: Machine epsilon: conclusion

jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
Richard Heathfield wrote:
jacob navia said:
Richard Heathfield wrote:
jacob navia said:
<snip>

For the different representations we have in the standard header
<float.h>:

#define FLT_EPSILON 1.19209290e-07F // float
#define DBL_EPSILON 2.2204460492503131e-16 // double
#define LDBL_EPSILON 1.084202172485504434007452e-19L //long double

Not all C implementations use these specific values for FLT_EPSILON,
DBL_EPSILON, and LDBL_EPSILON. For example, I've worked on a system
where both float and double are 64 bits with a 13-bit exponent
(non-IEEE). You should make it clear that those values are specific
to IEC 60559 implementations -- though even on such systems, Annex F
allows some flexibility in the representation of long double.

// qfloat epsilon truncated so that it fits in this page...
#define QFLT_EPSILON 1.09003771904865842969737513593110651 ... E-106
You have the same bug as last time. No standard-conforming
implementation may define QFLT_EPSILON in the standard header
<float.h>, as I pointed out to you earlier this week.

I have told you thousand times that this can be disabled
by using -ansic.

But you don't mention it in your tutorial.

You don't seem to understand my point, which is that you are
describing <float.h> as a *standard header*, and yet you *also*
describe it as containing QFLT_EPSILON. It can't *both* be a
standard header *and* contain QFLT_EPSILON at the same time. If it
is a standard header, it does not contain QFLT_EPSILON. If it
contains QFLT_EPSILON, it is not a standard header. Your claim that
QFLT_EPSILON is in a standard header is simply wrong, switch or no
switch.


The compiler you use has a file called
"math.h"

Quibble: his *implementation" has such a file; it's not part of the
compiler.

There, I can read

# define M_E 2.7182818284590452354 /* e */
[...]
# define M_SQRT1_2 0.70710678118654752440 /* 1/sqrt(2) */

but that doesn't bother you since when you call that compiler
with the needed flags, those definitions do not appear.

Correct.

When I do exactly the same you will argue without end.

He's not complaining about the behavior of your compiler. If
lcc-win32, with the "-ansic" option, disables the definition of
QFLT_EPSILON in <float.h>, that's great; your compiler is doing
exactly the right thing.

He's complaining about the contents of your tutorial, in which you
present QFLT_EPSILON as part of the <float.h> header. If you were to
make it clear in your tutorial that <float.h> only defines
QFLT_EPSILON when lcc-win32 is invoked in a non-conforming mode, I
think that would address his complaint.

The suggestion that such extensions should be in separate headers is
also a good one, but I suppose making such a change would break
existing code that depends on the way lcc-win32 has already
implemented these extensions. You might keep it in mind when you add
other extension to your implementation in the future, though.

Personally, I think your tutorial should make a much clearer
distinction between what's defined by the ISO C standard and what's
defined only by a particular implementation. I'd probably put all
implementation-specific information in an appendix, with brief
references at the relevant points of the tutorial. Something like:

<float.h> defines FLT_EPSILON, DBL_EPSILON, and LDBL_EPSILON as
follows: ... [See Appendix A section 42 for information about
lcc-win32 extensions in <float.h>.]

I believe such a structure would be much more useful if your target
audience is programmers who are interested in standard C.

If that's *not* your target audience, then I suggest you should be
having this discussion in comp.compilers.lcc.

The fact that my compiler is the only C compiler giving to the user
105 digits floating point precision is not important to you.

It's not important to me either. I don't say that to be insulting.
I'm sure it's useful to some people. I just don't happen to do C
programming under Win32.

Polemic, polemic without end, but you did not contribute anything
to this discussion.

He's contributed a great deal.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: Automatically generate variables
    ... stdlib.h is a standard header. ... paragraph 3: ... because the compiler wouldn't see it. ... magically make my implementation 100% conforming (though not usefully ...
    (comp.lang.c)
  • Re: Standard header and using
    ... It makes the iostream facilities (which has to do with ... if the standard header iostream defines the names cout then why in ... the compiler has to know what it is before it can be used. ... namespace is completely separate. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: .h for standard headers
    ... >> entry in a ToDo list. ... > Did that era include, say, 1999? ... Adding .h to the standard header files ... change/upgrade your compiler and/or the standard library implementation. ...
    (comp.lang.cpp)
  • Re: Headers/Libraries default locations
    ... There is no guarantee that there are "standard header files". ... In any case, *THE* compiler installs where ... There is no guarantee that there are "standard library files". ...
    (comp.lang.c)