In article <32E2C09E.41C6@wizard.net>, James Kuyper <kuyper@wizard.net>
writes:
|> Nick Maclaren wrote:
|> ...
|> > I don't suppose that there is any chance of fixing <float.h>?  And I DO
|> > mean "fixing" - the current one is of little use except for checking
|> > that your own version corresponds with the compiler's idea of reality.
|> ...
|> Could you expand on that? What doesn't it do right?

Except for FLT_RADIX, none of the the values are required to be
constant expressions.  And why is FLT_RADIX special, anyway?
There used to be (and maybe still are), several systems where
the arithmetic could be performed in more than one radix.  But
let that be.

I believe that this was produced to permit the more egregious
features of the Intel 80387 and its successors, but it was always
obviously a mistake.  Do you KNOW how difficult it is to write
numerical software that can run without changes on systems with a
wide range of arithmetic?  And that pales into insignificance
compared with when the numerical model can change dynamically.

Almost all numerical software either assumes that the <float.h>
values are constant, or has its own version defining the values as
constants and (at most) uses the supplied <float.h> to check.  When
I have done this, I have often found that my header is the one that
is right, and the supplied one that is wrong :-)

I do not know of one single C library, serious numerical application
or anything else that actually supports the values of <float.h>
changing dynamically.  And that includes all of the libraries for
Intel systems that I have used.  In most cases on Intel systems, if
you actually change the arithmetic while the program is running, the
C library gives wrong answers or crashes.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

>James Kuyper <kuyper@wizard.net> writes:
>|> Nick Maclaren wrote:
>|> ...
>|> > I don't suppose that there is any chance of fixing <float.h>?  And I DO
>|> > mean "fixing" - the current one is of little use except for checking
>|> > that your own version corresponds with the compiler's idea of reality.
>|> ...
>|> Could you expand on that? What doesn't it do right?
>
>Except for FLT_RADIX, none of the the values are required to be
>constant expressions.

This problem is at least partially fixed in the C++ numeric_limits template.
The draft C++ standard specifies the following:

 |   18.2.1  Numeric limits                                    [lib.limits]
 |
 | 3 For  all members declared static const in the numeric_limits template,
 |   specializations shall define these values in such a way that they  are
 |   usable as integral constant expressions.

All members of numeric_limits that have an integral type are specified
as static const, so they must be integral constant expressions.

However, the members of numeric_limits<float> which are functions that
return float, namely min(), max(), epsilon(), round_error(),
infinity(), quiet_NaN(), signaling_NaN(), and denorm_min(),
are not constant expressions.  Still, in C++ it's probably not
so important, since in C++ the initializer for a global const
doesn't have to be a constant expression.

 |   18.2.1.1  Template class numeric_limits           [lib.numeric.limits]
 |   namespace std {
 |     template<class T> class numeric_limits {
 |     public:
 |       static const bool is_specialized = false;
 |       static T min() throw();
 |       static T max() throw();
 |       static const int  digits = 0;
 |       static const int  digits10 = 0;
 |       static const bool is_signed = false;
 |       static const bool is_integer = false;
 |       static const bool is_exact = false;
 |       static const int  radix = 0;
 |       static T epsilon() throw();
 |       static T round_error() throw();
 |
 |       static const int  min_exponent = 0;
 |       static const int  min_exponent10 = 0;
 |       static const int  max_exponent = 0;
 |       static const int  max_exponent10 = 0;
 |
 |       static const bool has_infinity = false;
 |       static const bool has_quiet_NaN = false;
 |       static const bool has_signaling_NaN = false;
 |       static const bool has_denorm = false;
 |       static const bool has_denorm_loss = false;
 |       static T infinity() throw();
 |       static T quiet_NaN() throw();
 |       static T signaling_NaN() throw();
 |       static T denorm_min() throw();
 |
 |       static const bool is_iec559 = false;
 |       static const bool is_bounded = false;
 |       static const bool is_modulo = false;
 |
 |       static const bool traps = false;
 |       static const bool tinyness_before = false;
 |       static const float_round_style round_style = round_toward_zero;
 |     };
 |   }

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]