Daryle Walker wrote:
...
> 3.  For the digits and digits10 members, what does "can be represented
> without change" mean?  And what happens for types that don't have
> place-value systems?  (Rational numbers could be considered such an
> example.)

For 'digits', footnote 183 points you to the *_MANT_DIG macros, whose
definition is contained in the C++ standard only by cross-reference to
the C90 standard. I don't have a copy of that standard, but the current
C99 standard says:

| number of decimal digits, n, such that any floating-point number in
the widest
| supported floating type with pmax radix b digits can be rounded to a
floating-point
| number with n decimal digits and back again without change to the
value,"
|
| pmax log10(b) if b is a power of 10
| 1+pmax log10(b) [rounded up to next integer] otherwise

b is the base of the representation, equivalent to
numeric_limits<T>::radix, 'p' is the precision of the representation.
'pmax' is defined by this clause itself: it's the precision of the
widest supported floating type.

For 'digits10',  footnote 184 points you to the *_DIG macros, defined by
C99 as follows:

| number of decimal digits, q, such that any floating-point number with
q decimal digits
| can be rounded into a floating-point number with p radix b digits and
back again
| without change to the q decimal digits,
|
| p log10(b) if b is a power of 10
| (p-1) log10(b) [rounded down to previous integer] otherwise

> 5.  A more fundamental problem is that some descriptions seem to assume
> that the type must be integral or floating-point?  What about other
> number systems?  (For example, other langauges have built-in fixed-point
> types.)  Maybe the next standard needs to change numeric_limits to be
> friendlier to unusual numeric types.

18.2.1p2 specifies that "Specializations shall be provided for each
fundamental type...", and paragraph 4 says that "Non-fundamental
standard types shall not have specialization". Every fundamental type IS
either integral or floating-point; the standard allows for no other
possibilities (see section 3.9.1).
This leaves open a couple of possiblities: non-standard types can be
defined, either by the implementation or by the user, and numeric_limits
can be specialized for such a type. The standard mentions both rational
numbers and arbitrary precision numbers, so it's clear that they
intended numeric_limits to be specializable for non-standard types. How
it's to be specialized for this is unclear to me, however.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Daryle Walker" <dwalker07@snet.net.invalid> wrote...
>
> ...section 18.2.1.5, paragraph 1, only needs is_integer to
> be false for epsilon() to be meaningful.  So where do numeric types that
> aren't integral nor floating-point go?
>
> 5.  A more fundamental problem is that some descriptions seem to assume
> that the type must be integral or floating-point?  What about other
> number systems?  (For example, other langauges have built-in fixed-point
> types.)

The real problem with numeric_limits with anything other than
built-in types (and their typedefs) is that the person USING
the specialisation doesn't know how the person WRITING the
specialisation answered all these questions. (We've already seen
people query the decision that min() is a large negative number
for a signed integral type, but a small positive one for a
floating point type.)

Sometimes those two persons are one and the same. Several
readers of this thread have probably written a semi-numerical
type and specialised numeric_limits for it. To them, it will
be fairly obvious how to interpret the various members to fit
the new type, and they will have little trouble using it in
their own code. They may find that problems show up when they
share their new class with others, for whom the "correct"
definitions are "obviously" different.

I'd be surprised if more than a handful of people are in the
situation whereby person A writes a type (and specialises
numeric_limits), person B writes a template that uses it, and
person C instantiates B's template with A's type and experiences
no problems. To take two more examples...

  What is numeric_limits::epsilon() for a complex type? Is it purely
  real, purely imaginary or a bit of both? If it is fair to specialise
  numeric_limits for complex numbers, is it fair to specialise for
  2D vectors, n-D vectors, tensors...?

  What is numeric_limits::epsilon() for an interval arithmetic class?
  It could be either the smallest representable value, or it could be
  the epsilon of the underlying type. How about is_exact, or the
  round_style?

I think there are no indisputable answers to these questions.

> Maybe the next standard needs to change numeric_limits to be
> friendlier to unusual numeric types.

Maybe, or maybe we just accept that, in practice, numeric_limits
has only two uses. The integer subset does a good job of describing
the properties of integer types which vary with the platform or
implementation. The other half of the template does a fairly good
job of describing the scalar floating point types. We'd be better
off with two separate templates, integer_traits<> and float_traits<>.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <newscache$gqnd4g$896$1@firewall.thermoteknix.co.uk>,
  "Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote:
> "Daryle Walker" <dwalker07@snet.net.invalid> wrote...

    [...]
> I'd be surprised if more than a handful of people are in the
> situation whereby person A writes a type (and specialises
> numeric_limits), person B writes a template that uses it, and
> person C instantiates B's template with A's type and experiences
> no problems. To take two more examples...

>   What is numeric_limits::epsilon() for a complex type? Is it purely
>   real, purely imaginary or a bit of both? If it is fair to specialise
>   numeric_limits for complex numbers, is it fair to specialise for
>   2D vectors, n-D vectors, tensors...?

IMHO, no.  I think it fair to limit numeric_limits to simple numeric
types: it should work for all types whose abstraction is a subset of
the real numbers; I would hesitate to ask more of it.

>   What is numeric_limits::epsilon() for an interval arithmetic
>   class?  It could be either the smallest representable value, or it
>   could be the epsilon of the underlying type. How about is_exact,
>   or the round_style?

> I think there are no indisputable answers to these questions.

I think that interval arithmetic is a problem.  Logically, the
abstraction *IS* over a subset of the real numbers; I would expect,
for example, to be able to use interval arithmetic with any template
which handled float and double.

> > Maybe the next standard needs to change numeric_limits to be
> > friendlier to unusual numeric types.

> Maybe, or maybe we just accept that, in practice, numeric_limits has
> only two uses. The integer subset does a good job of describing the
> properties of integer types which vary with the platform or
> implementation. The other half of the template does a fairly good
> job of describing the scalar floating point types. We'd be better
> off with two separate templates, integer_traits<> and
> float_traits<>.

With a common base class to be used by the algorithms which can
reasonably be used on both integers and real numbers:-).

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

1.  The part of the C++ standard describing the members of
std::numeric_limits, section 18.2.1.2, doesn't give statements of
meaningfullness for all the members.  The members missing these
statements are:

static  const int  digits;
static  T  round_error()  throw();
static  const bool  has_denorm_loss;

2.  For the min() member, why do floating types with denormalization get
special treatment?  What if I want the actual minimum finite value of
that type, if it even exists?

3.  For the digits and digits10 members, what does "can be represented
without change" mean?  And what happens for types that don't have
place-value systems?  (Rational numbers could be considered such an
example.)

4.  Some of the descriptions are contradictory.  Section 18.2.1.2,
paragraph 21, says that epsilon() is only meaningful for floating-point
types.  However, section 18.2.1.5, paragraph 1, only needs is_integer to
be false for epsilon() to be meaningful.  So where do numeric types that
aren't integral nor floating-point go?

5.  A more fundamental problem is that some descriptions seem to assume
that the type must be integral or floating-point?  What about other
number systems?  (For example, other langauges have built-in fixed-point
types.)  Maybe the next standard needs to change numeric_limits to be
friendlier to unusual numeric types.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]