Topic: FWD: problem with numeric_limits::min
Author: James Kuyper <kuyper@wizard.net>
Date: 2000/06/28 Raw View
Fernando Cacciola wrote:
....
> The standard says:
>
> [lib.numeric.limits.members]
> 18.2.1.2 numeric_limits members
> static T min() throw();
> 1 Minimum finite value. 172)
> 2 For floating types with denormalization, returns the minimum positive
> normalized value.
> 3 Meaningful for all specializations in which is_bounded != false, or
> is_bounded == false
> && is_signed == false.
>
> 172) Equivalent to CHAR_MIN, SHRT_MIN, FLT_MIN, DBL_MIN, etc.
....
> It seems that there is an inconsistency in the meaning of _MIN.
This inconsistency has been around for a long time, and has a simple
reason. For signed integers, the minimum value is very important number
to know, while the smallest value of any integer type is always known to
be exactly 0.
For floating point numbers, the smallest non-zero value is very
important number to know, while the minimum value is -DOUBLE_MAX.
> For integral types, it is the minimum finite value (just as one would have
> expected),
> but for floating point types, it is the SMALLEST.
Exactly as stated in the clause you quoted.
> This causes an inconsistency in the meaning of numeric_limits::min.
But it's an inconsistency that's very familiar to long-time users of
<limits.h>. Now, in C you'll never use TYPE_MIN without knowing whether
TYPE is a floating point type or an integer type. However, in C++ you
could be tempted to use numeric_limits<T>::min inside a template without
knowing that information. Resist that temptation: always check
numeric_limits<T>::is_integer first.
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Fernando Cacciola" <fcacciola@fibertel.com.ar>
Date: 2000/06/28 Raw View
I've posted this in comp.lang.c++.moderated, but received just a single
answer. So I'll try it here.
Hi,
I got very confused about numeric_limits::min.
I wrote a piece of code which verifies if a given signed number falls into
the range of
a certain arithmetic type.
The code (very simplified) looks like:
if ( num < 0 )
{
if ( num < numeric_limits<T>::min() )
out of range error.
}
else
{
if ( num > numeric_limits<T>::max() )
out of range error.
}
The idea is simple: just check if the number falls outside the range of
representable
values for the type T. (The actual code takes care of all the conversions)
Now, I figured that this range would be:
[numeric_limits<T>::min(),numeric_limits<T>::max()]
This is true for the signed and unsigned integral types, but isn't for
floating point types:
That is, numeric_limits<double>::min() is 2.2250738585072014E-308 in my
implementation.
The standard says:
[lib.numeric.limits.members]
18.2.1.2 numeric_limits members
static T min() throw();
1 Minimum finite value. 172)
2 For floating types with denormalization, returns the minimum positive
normalized value.
3 Meaningful for all specializations in which is_bounded != false, or
is_bounded == false
&& is_signed == false.
172) Equivalent to CHAR_MIN, SHRT_MIN, FLT_MIN, DBL_MIN, etc.
This means that the C++ standard just borrows the ANSI C old limits.
Now, in limits.h (the C limits header) I found, for example:
#define SHRT_MIN (-32767-1) /* minimum signed short value */
#define SHRT_MAX 32767 /* maximum signed short value */
#define LONG_MIN (-2147483647L-1) /* minimum signed long value */
#define LONG_MAX 2147483647L /* maximum signed long value */
And in float.h:
/* smallest positive IEEE normal numbers */
#define DBL_MIN 2.2250738585072014E-308
#define FLT_MIN 1.17549435E-38F
It seems that there is an inconsistency in the meaning of _MIN.
For integral types, it is the minimum finite value (just as one would have
expected),
but for floating point types, it is the SMALLEST.
This causes an inconsistency in the meaning of numeric_limits::min.
Any ideas?
--
Fernando Cacciola
Sierra s.r.l.
fcacciola@fibertel.com.ar
www.gosierra.com
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]