Topic: Proposed extensions to numeric_limits<>
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/12/21 Raw View
Vlad Harchev wrote:
>
> It seems that definition of numeric_limits<> in CD2 lacks a number of
> member functions similar to those required by IEEE for fp numbers
> (IEEE-754?):
> bool finite(T v) throw();
> bool isinf(T v) throw();
> bool isnan(T v) throw();
> T nextafter(T v,int dir) throw();
> int fp_class(T v) throw();
> I think that they will make numeric_limits<> much more usable.
> Implementing only nextafter(T v) and fp_class(T v) will provide the
> functionality of other functions mentioned. Function fp_class(T v)
> is much more important than nextafter(T v,int dir), since implementing
> fp_class(T v) provides the (slow) functionality of
> bool finite(T v) throw();
> bool isinf(T v) throw();
> bool isnan(T v) throw();
> Current definition of numeric_limits<> has one defficienty: having the
> number of type T, we can't tell whether it't Inf, some NAN or 'normal'
> number - for floating point types IEEE 754 says that the variable that
> has the value of Infinity or QNAN, should compare unequal to any number
> (including itself ! ). Introducing the member functions that I suggest to
> add will solve the problem.
Well, if you have IEEE-754-numbers, I think the following definitions
will suffice:
bool finite(T x) { return x==x; } // uses the fact you told
bool isinf(T x) { return (x!=x) && (1/x==1/x); } // not sure about this
bool isnan(T x) { return (x!=x) && (1/x!=1/x); } // not sure either
What you don't get is nextafter, of course. However, this IMHO would be
a very good candidate for numeric_limits, since it makes sense for
_every_ floating point type, even for non-IEEE ones.
>
> PS: quick reference on 'fp_class(T v)': this function returns the code that
> corresponds to the type of the number passed: for example
> 0 for denormalized, 1 for normal, 2 for -0, 3 for +0, 4 for QNAN, 5 for
> +Inf, etc (it distinguish positive and negative Infs, 0, and (as i remember)
> QNANs.
I don't see a way to distinguish positive and negative zero
(and therefore positive and negative inf), since I'm sure that
-0==0 must hold. Detecting denormalized numbers may be done with
nextafter:
bool is_denorm(T x)
{
return x<1 && nextafter(x,1)-x == nextafter(2*x,1)-2*x;
}
[ 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: "Vlad Harchev" <vladhar@imimail.ssau.ru>
Date: 1998/12/23 Raw View
Christopher Eltschka wrote in message
<367E2371.66A213B2@physik.tu-muenchen.de> ...
>Well, if you have IEEE-754-numbers, I think the following definitions
>will suffice:
>
>bool finite(T x) { return x==x; } // uses the fact you told
>bool isinf(T x) { return (x!=x) && (1/x==1/x); } // not sure about this
>bool isnan(T x) { return (x!=x) && (1/x!=1/x); } // not sure either
>
I wish the numeric_limits<> interface to be generalized - so that it will
be availble not only for builtin types (as I wrote in other thread in this
newsgroup ). For multiplie-precision types implementation you suggest can be
much slower than calling appropriate function for that type.
-Vlad
[ 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: AllanW@my-dejanews.com
Date: 1998/12/25 Raw View
In article <36814e8d.0@monster.ssau.ru>,
"Vlad Harchev" <vladhar@imimail.ssau.ru> wrote:
>
>
> Christopher Eltschka wrote in message
> <367E2371.66A213B2@physik.tu-muenchen.de> ...
> >Well, if you have IEEE-754-numbers, I think the following definitions
> >will suffice:
> >
> >bool finite(T x) { return x==x; } // uses the fact you told
> >bool isinf(T x) { return (x!=x) && (1/x==1/x); } // not sure about this
> >bool isnan(T x) { return (x!=x) && (1/x!=1/x); } // not sure either
> >
> I wish the numeric_limits<> interface to be generalized - so that it will
> be availble not only for builtin types (as I wrote in other thread in this
> newsgroup ). For multiplie-precision types implementation you suggest can be
> much slower than calling appropriate function for that type.
If it's defined at all, it should be generalized. But note the use of
type T above; clearly Christopher Eltschka meant these to be part of
some template(s), although he didn't type that part in.
To make these general, add these to numeric_limits<>:
bool isinf(T x) { return false; }
bool isnan(T x) { return false; }
bool isfinite(T x) { return !isinf(x); }
since most numeric types don't have infinity or NAN values. Then
override them for specific cases.
For float, use something CONCEPTUALLY like this:
bool isinf(float x) {
long *y = reinterpret_cast<long*>(&x);
return 0x80000000 == y[0];
};
bool isnan(float x) {
long *y = reinterpret_cast<long*>(&x);
return 0x8000FFFF == y[0];
};
The actual contents will depend on the size of long and float, and the
exact binary representation of INF and NAN. Since this is non-portable,
users doing this are writing non-portable code. But if this was part of
the standard, each compiler would supply the definition and user
programs could portably use them without fear.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/12/26 Raw View
<AllanW@my-dejanews.com> wrote:
> "Vlad Harchev" <vladhar@imimail.ssau.ru> wrote:
>> Christopher Eltschka wrote
>> >Well, if you have IEEE-754-numbers, I think the following definitions
>> >will suffice:
>> >
>> >bool finite(T x) { return x==x; } // uses the fact you told
>> >bool isinf(T x) { return (x!=x) && (1/x==1/x); } // not sure about this
>> >bool isnan(T x) { return (x!=x) && (1/x!=1/x); } // not sure either
>>
>> I wish the numeric_limits<> interface to be generalized - so that it will
>> be availble not only for builtin types (as I wrote in other thread in this
>> newsgroup ). For multiplie-precision types implementation you suggest can
>> be much slower than calling appropriate function for that type.
>
>If it's defined at all, it should be generalized. But note the use of
>type T above; clearly Christopher Eltschka meant these to be part of
>some template(s), although he didn't type that part in.
>
>To make these general, add these to numeric_limits<>:
> bool isinf(T x) { return false; }
> bool isnan(T x) { return false; }
> bool isfinite(T x) { return !isinf(x); }
>since most numeric types don't have infinity or NAN values. Then
>override them for specific cases.
I can predict with near-certainty that nothing like this will be added
to numeric_limits<> in the foreseeable future. (The Standard is _out_,
in print, folks!) At the next round in five or ten years something
might be added, but there's no point in talking about that now.
Implementing your own extensions (e.g. number_traits<>) is a good
way to deal with current problems, and to prepare to have something
ready to add to the standard in some future millennium.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ 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: "Vlad Harchev" <vladhar@imimail.ssau.ru>
Date: 1998/12/18 Raw View
It seems that definition of numeric_limits<> in CD2 lacks a number of
member functions similar to those required by IEEE for fp numbers
(IEEE-754?):
bool finite(T v) throw();
bool isinf(T v) throw();
bool isnan(T v) throw();
T nextafter(T v,int dir) throw();
int fp_class(T v) throw();
I think that they will make numeric_limits<> much more usable.
Implementing only nextafter(T v) and fp_class(T v) will provide the
functionality of other functions mentioned. Function fp_class(T v)
is much more important than nextafter(T v,int dir), since implementing
fp_class(T v) provides the (slow) functionality of
bool finite(T v) throw();
bool isinf(T v) throw();
bool isnan(T v) throw();
Current definition of numeric_limits<> has one defficienty: having the
number of type T, we can't tell whether it't Inf, some NAN or 'normal'
number - for floating point types IEEE 754 says that the variable that
has the value of Infinity or QNAN, should compare unequal to any number
(including itself ! ). Introducing the member functions that I suggest to
add will solve the problem.
PS: quick reference on 'fp_class(T v)': this function returns the code that
corresponds to the type of the number passed: for example
0 for denormalized, 1 for normal, 2 for -0, 3 for +0, 4 for QNAN, 5 for
+Inf, etc (it distinguish positive and negative Infs, 0, and (as i remember)
QNANs.
Any opinions?
- Vlad
[ 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: abrahams@spam.motu.com (David Abrahams)
Date: 1998/12/19 Raw View
On 18 Dec 1998 16:11:34 GMT, "Vlad Harchev" <vladhar@imimail.ssau.ru>
wrote:
<Good ideas snipped>
> Current definition of numeric_limits<> has one defficienty: having the
numeric_limits<> has more than one defficiency! For starters, have you
noticed that min() for floating and integer types does completely
different things? A floating analogue to the integer min() would do
much to make the addition of nextafter() useful, among other things!
> Any opinions?
By all means, numeric_limits<> should be expanded. There are a number
of other obvious things which could be added, like the *portable*
range for a type (e.g. for int, -32767 to 32767).
Since it will be a long time before we can change it in the standard,
now is the time to experiment with your own template and get it right:
namespace Numerics {
template<class T> class numeric_traits : public std::numeric_limits<T>
{
// more stuff here
};
template<>
class numeric_traits<int> {...};
}
-Dave
[ 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: sbnaran@localhost.localdomain.COM (Siemel Naran)
Date: 1998/12/19 Raw View
On 18 Dec 1998 16:11:34 GMT, Vlad Harchev <vladhar@imimail.ssau.ru> wrote:
> bool finite(T v) throw();
> bool isinf(T v) throw();
> bool isnan(T v) throw();
> T nextafter(T v,int dir) throw();
> int fp_class(T v) throw();
"isnan" and "isinf" are namespace level functions in <cmath>.
But I still like the idea of making them functions of numeric_limits.
However, they should be static functions.
A nice solution is to do away with numeric_limits and make the functions
part of the builtin class. Like this,
cout << double::max() << '\n';
which is much nicer than
cout << numeric_limits<double>::max() << '\n';
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/12/19 Raw View
David Abrahams<abrahams@spam.motu.com> wrote:
>Since it will be a long time before we can change it in the standard,
>now is the time to experiment with your own template and get it right:
>
>namespace Numerics {
>template<class T> class numeric_traits : public std::numeric_limits<T>
>{
> // more stuff here
>};
>
>template<>
>class numeric_traits<int> {...};
>}
Every time I see this I think I'm seeing the standard template.
Probably these things should be named "number_traits" instead.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ 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: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
Date: 1998/12/19 Raw View
"Vlad Harchev" <vladhar@imimail.ssau.ru> writes:
> It seems that definition of numeric_limits<> in CD2 lacks a number of
Please, for latter postings do refer to the *Standard*. CD2, as it
suggests was a _draft_.
> member functions similar to those required by IEEE for fp numbers
> (IEEE-754?):
Well, Standard C++ doesn't even require IEEE-754 floating point
arithmetic.
--
Gabriel Dos Reis | Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
[ 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 ]