(In all the text I refer to ISO/IEC 14882:2003(E) as the Standard.)

Point 18.2.1.2$18 states (on numeric_limits::radix):
?For integer types, specifies the base of the representation.?
with a footnote:
?Distinguishes types with bases other than 2 (e.g. BCD).?

On the other hand point 3.9.1$7 states
?Types bool, char, wchar_t, and the signed and unsigned integer types
are collectively called integral types. A synonym for integral type is
integer type. The representations of integral types shall define
values by use of a pure binary numeration system. [Example: this
International Standard permits 2?s complement, 1?s complement and
signed magnitude representations for integral types.]?
with two footnotes:
?Therefore, enumerations (7.2) are not integral; however, enumerations
can be promoted to int, unsigned int, long, or unsigned long, as
specified in 4.5.?
and
?A positional representation for integers that uses the binary digits
0 and 1, in which the values represented by successive bits are
additive, begin with 1, and are multiplied by successive integral
power of 2, except perhaps for the bit with the highest position.
(Adapted from the American National Dictionary for Information
Processing Systems.)?

Thous the build-in integral types must behave like they were binary.
However Standard does not enforce (directly) numeric_limits::radix of
those types to be 2. Is it on purpose? Are any other values
acceptable?

Also points 18.2.1.2$6 and $7 state (in description of
numeric_limits::digits):
$6 ? ?Number of radix digits that can be represented without change.?
$7 ? ?For built-in integer types, the number of non-sign bits in the
representation.?
If radix for those types was forced (directly or indirectly) to be 2
then point $7 (special case for build-in integral types) would be
pointless as the primal definition (point $6) would be true (at least
for unsigned integral types ? I am not so sure with signed ones).

Another clue is point 3.9.1$4
?Unsigned integers, declared unsigned, shall obey the laws of
arithmetic modulo 2^n where n is the number of bits in the value
representation of that particular size of integer.?
with a footnote:
?This implies that unsigned arithmetic does not overflow because a
result that cannot be represented by the resulting unsigned integer
type is reduced modulo the number that is one greater than the largest
value that can be represented by the resulting unsigned integer type.?
If radix of a build-in unsigned integral type was chosen so that not
all the bits would participate in creation of the value of the object
(like radix 10 for 11 bits numbers leaves the last bit never used) or
even with a weaker condition of not all bit patterns to be valid (like
radix 10 for 10 bits numbers) then a valid arithmetic operation could
lead to a bit pattern which is representable but is not a correct
value. Again for 10 bits unsigned int with radix 10 the representable
values are in range [0; 999] (forth digit cannot be used since not all
values on 4 digits are representable without change) and the operation
999 + 1 gives 1000 which has a proper bit pattern (even without the
modulo rule) but is out of range. (Or maybe I am abusing the digits
value here? ? Because from my understanding for build-in unsigned
integral types numeric_limits::min is always 0 while
numeric_limits::max is always radix^digits-1.)

One could think that maybe this implies somehow set of possible values
for radix of build-in integral types (at least those unsigned).
Especially for unsigned char as the point 3.9.1$1 (fragment) states:
?(...) For character types, all bits of the object representation
participate in the value representation. For unsigned character types,
all possible bit patterns of the value representation represent
numbers. These requirements do not hold for other types. (...)?
But it would be strange that the Standard enforces binary
representation for build-in integer types (disallowing use of machine
BCD types for example) while on the same leaving free hand as for the
radix value.

What am I missing here?

Adam Badura


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Feb 4, 5:38 pm, Adam Badura <abad...@o2.pl> wrote:
> (In all the text I refer to ISO/IEC 14882:2003(E) as the Standard.)

> Point 18.2.1.2$18 states (on numeric_limits::radix):
> ?For integer types, specifies the base of the representation.?
> with a footnote:
> ?Distinguishes types with bases other than 2 (e.g. BCD).?

      [...]
> Thous the build-in integral types must behave like they were binary.
> However Standard does not enforce (directly) numeric_limits::radix of
> those types to be 2. Is it on purpose? Are any other values
> acceptable?

For the standard integral types, no.

      [...]
> What am I missing here?

That a user can define a DecimalInteger class, for example, and
specialize numeric_limits on it; in such cases, 10 would be an
appropriate value.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                  Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 6 Lut, 10:39, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 4, 5:38 pm, Adam Badura <abad...@o2.pl> wrote:
>
> > (In all the text I refer to ISO/IEC 14882:2003(E) as the Standard.)
> > Point 18.2.1.2$18 states (on numeric_limits::radix):
> > ?For integer types, specifies the base of the representation.?
> > with a footnote:
> > ?Distinguishes types with bases other than 2 (e.g. BCD).?
>
>       [...]
>
> > Thous the build-in integral types must behave like they were binary.
> > However Standard does not enforce (directly) numeric_limits::radix of
> > those types to be 2. Is it on purpose? Are any other values
> > acceptable?
>
> For the standard integral types, no.

    But why? What prevents (except for sanity) a conforming
implementation on PC with unsigned int being 4 bytes (32 bits) to
define numeric_limits<unsigned int>::radix as 16 (so unsigned int
stores value in hex digits). This will result in 8 such digits to fit
into unsigned int (however Standard enforces numeric_limits<unsigned
int>::digits to be 32 and not 8 as it would be with non-build-in
integral types). (Note that this example skips most of described
problems as radix 16 results in entire coverage of the unsigned int
with the radix-based digits.)

    Adam Badura


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Feb 6, 4:43 pm, Adam Badura <abad...@o2.pl> wrote:
> On 6 Lut, 10:39, James Kanze <james.ka...@gmail.com> wrote:
> > On Feb 4, 5:38 pm, Adam Badura <abad...@o2.pl> wrote:

> > > (In all the text I refer to ISO/IEC 14882:2003(E) as the
> > > Standard.) Point 18.2.1.2$18 states (on
> > > numeric_limits::radix): ?For integer types, specifies the
> > > base of the representation.?  with a footnote:
> > > ?Distinguishes types with bases other than 2 (e.g. BCD).?

> >       [...]

> > > Thous the build-in integral types must behave like they
> > > were binary.  However Standard does not enforce (directly)
> > > numeric_limits::radix of those types to be 2. Is it on
> > > purpose? Are any other values acceptable?

> > For the standard integral types, no.

> But why? What prevents (except for sanity) a conforming
> implementation on PC with unsigned int being 4 bytes (32 bits)
> to define numeric_limits<unsigned int>::radix as 16 (so
> unsigned int stores value in hex digits). This will result in
> 8 such digits to fit into unsigned int (however Standard
> enforces numeric_limits<unsigned int>::digits to be 32 and not
> 8 as it would be with non-build-in integral types). (Note that
> this example skips most of described problems as radix 16
> results in entire coverage of the unsigned int with the
> radix-based digits.)

The requirements that built-in integral types use a pure binary
representation.

--
James Kanze (GABI Software)             email:james.ka...@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> The requirements that built-in integral types use a pure binary
> representation.

I am not so convinced that fact of build-in integral types being pure
binary implies numeric_limits::radix to be 2. Why would it? But even
if we assumed so then why 18.2.1.2$7 makes an explicit definition of
numeric_limits::digits for build-in integral type? If
numeric_limits::radix was forced to be 2 (for build-in integral types)
then the definition from 18.2.1.2$6 is good enough.

Adam Badura

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]