Binary number

[Peter Nilsson]

Re: Binary number

CBFalconer wrote:[color=blue]
> Peter Nilsson wrote:[color=green]
> > CBFalconer wrote:[color=darkred]
> >> ...
> >> What issue? A value of LONG_MIN is immediately converted to an
> >> unsigned long with a '-' sign emitted.[/color]
> >
> > The conversion of LONG_MIN to unsigned long may yield 0.
> >
> > It's not likely to on any implementation in existance, but
> > the standard allows it. [Genuine strictly conforming itoa
> > functions have previously been posted to clc.][/color]
>
> I see no way for a non-zero integer to be converted to zero.
> Show me. Remember that ULONG_MAX has to be odd, as implied
> by the imposed weighted bit construction.[/color]

6.2.6.2p2 "...(if there are M value bits in the signed type
and N in the unsigned type, then M <= N). ..."

Thus, ULONG_MAX == LONG_MAX is allowed by the standards (other
constraints notwithstanding .) On such a machine, conversion of
LONG_MIN to unsigned long may produce 0.

--
Peter

[CBFalconer]

Re: Binary number

Peter Nilsson wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> Peter Nilsson wrote:[color=darkred]
>>> CBFalconer wrote:
>>>> ...
>>>> What issue? A value of LONG_MIN is immediately converted to
>>>> an unsigned long with a '-' sign emitted.
>>>
>>> The conversion of LONG_MIN to unsigned long may yield 0.
>>>
>>> It's not likely to on any implementation in existance, but
>>> the standard allows it. [Genuine strictly conforming itoa
>>> functions have previously been posted to clc.][/color]
>>
>> I see no way for a non-zero integer to be converted to zero.
>> Show me. Remember that ULONG_MAX has to be odd, as implied
>> by the imposed weighted bit construction.[/color]
>
> 6.2.6.2p2 "...(if there are M value bits in the signed type
> and N in the unsigned type, then M <= N). ..."
>
> Thus, ULONG_MAX == LONG_MAX is allowed by the standards (other
> constraints notwithstanding .) On such a machine, conversion of
> LONG_MIN to unsigned long may produce 0.[/color]

Following from N869

[#2] For signed integer types, the bits of the object
representation shall be divided into three groups: value
bits, padding bits, and the sign bit. There need not be any
padding bits; there shall be exactly one sign bit. Each bit
that is a value bit shall have the same value as the same
bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type
and N in the unsigned type, then M<=N). If the sign bit is
zero, it shall not affect the resulting value. If the sign
bit is one, then the value shall be modified in one of the
following ways:

-- the corresponding value with sign bit 0 is negated;

-- the sign bit has the value -2N;

-- the sign bit has the value 1-2N.

And there is a silly contradiction. The above specifies the
evaluation of the sign bit in the unsigned version. The sign bit
is NOT a value bit in the signed version. Thus there has to be an
extra bit position in the unsigned version. i.e. the <= above
should be <.

--
Some informative links:
news:news.annou nce.newusers

http://www.geocities.com/nnqweb/

http://www.catb.org/~esr/faqs/smart-questions.html

http://www.caliburn.nl/topposting.html

http://www.netmeister.org/news/learn2quote.html

[Keith Thompson]

Re: Binary number

CBFalconer <cbfalconer@yah oo.com> writes:
[...][color=blue]
> Following from N869
>
> [#2] For signed integer types, the bits of the object
> representation shall be divided into three groups: value
> bits, padding bits, and the sign bit. There need not be any
> padding bits; there shall be exactly one sign bit. Each bit
> that is a value bit shall have the same value as the same
> bit in the object representation of the corresponding
> unsigned type (if there are M value bits in the signed type
> and N in the unsigned type, then M<=N). If the sign bit is
> zero, it shall not affect the resulting value. If the sign
> bit is one, then the value shall be modified in one of the
> following ways:
>
> -- the corresponding value with sign bit 0 is negated;
>
> -- the sign bit has the value -2N;
>
> -- the sign bit has the value 1-2N.
>
> And there is a silly contradiction. The above specifies the
> evaluation of the sign bit in the unsigned version. The sign bit
> is NOT a value bit in the signed version. Thus there has to be an
> extra bit position in the unsigned version. i.e. the <= above
> should be <.[/color]

No, I don't think so. This only specifies the evaluation of the sign
bit in the *signed* version.

In particular, an implementation with the following characteristics
could be conforming:

CHAR_BIT == 8
sizeof(int) == 2
sizeof(unsigned int) == 2
int has 1 sign bit and 15 value bits (two's-complement)
unsigned int has 1 padding bit and 15 value bits
INT_MIN == -32768
INT_MAX == +32767
UINT_MAX == +32767

If this is non-conforming, please indicate why.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[infobahn]

Re: Binary number

Keith Thompson wrote:[color=blue]
>[/color]
<snip>
[color=blue]
> In particular, an implementation with the following characteristics
> could be conforming:
>
> CHAR_BIT == 8
> sizeof(int) == 2
> sizeof(unsigned int) == 2
> int has 1 sign bit and 15 value bits (two's-complement)
> unsigned int has 1 padding bit and 15 value bits
> INT_MIN == -32768
> INT_MAX == +32767
> UINT_MAX == +32767
>
> If this is non-conforming, please indicate why.[/color]

It's non-conforming because UINT_MAX must equal or exceed 65535.

[Peter Nilsson]

Re: Binary number

CBFalconer wrote:[color=blue]
> Peter Nilsson wrote:[color=green]
> >
> > 6.2.6.2p2 "...(if there are M value bits in the signed type
> > and N in the unsigned type, then M <= N). ..."
> >
> > Thus, ULONG_MAX == LONG_MAX is allowed by the standards (other
> > constraints notwithstanding .) On such a machine, conversion of
> > LONG_MIN to unsigned long may produce 0.[/color]
>
> Following from N869
>
> [#2] For signed integer types, the bits of the object
> representation shall be divided into three groups: value
> bits, padding bits, and the sign bit. There need not be any
> padding bits; there shall be exactly one sign bit. Each bit
> that is a value bit shall have the same value as the same
> bit in the object representation of the corresponding
> unsigned type (if there are M value bits in the signed type
> and N in the unsigned type, then M<=N). ...[/color]

Exactly!
[color=blue]
> If the sign bit is
> zero, it shall not affect the resulting value. If the sign
> bit is one, then the value shall be modified in one of the
> following ways:
>
> -- the corresponding value with sign bit 0 is negated;
>
> -- the sign bit has the value -2N;
>
> -- the sign bit has the value 1-2N.
>
> And there is a silly contradiction.[/color]

Only if you make the assumption that the sign bit contributes
as a value bit in the unsigned type. The standard does not
state that it does.
[color=blue]
> The above specifies the
> evaluation of the sign bit in the unsigned version.[/color]

No. Only 6.2.6.2p5 states that the corresponding sign bit in
an unsigned ingteger type is required to be 0 for all non-
negative values of the signed integer type.
[color=blue]
> The sign bit is NOT a value bit in the signed version.[/color]

True!
[color=blue]
> Thus there has to be an extra bit position in the unsigned
> version.[/color]

Yes, but it needn't contribute a value.
[color=blue]
> i.e. the <= above should be <.[/color]

No.

C89 has the same statement about the number of value bits,
although it doesn't _explicitly_ allow padding bits. Hence
the change in wording in C99.

The purpose of this clause is apparently to allow for
implementations that use floating point mechanics to mimic
signed and unsigned integer types.

--
Peter

[Peter Nilsson]

Re: Binary number

Keith Thompson wrote:[color=blue]
>
> ... an implementation with the following characteristics
> could be conforming:
>
> CHAR_BIT == 8
> sizeof(int) == 2
> sizeof(unsigned int) == 2[/color]

sizeof(unsigned ) must equal sizeof(int)
[color=blue]
> int has 1 sign bit and 15 value bits (two's-complement)
> unsigned int has 1 padding bit and 15 value bits
> INT_MIN == -32768
> INT_MAX == +32767
> UINT_MAX == +32767
>
> If this is non-conforming, please indicate why.[/color]

5.2.4.2.1 Sizes of integer types <limits.h>

- [minimum] maximum value for an object of type unsigned int
UINT_MAX 65535

But if you say...

CHAR_BIT == 9
sizeof(int) == 2
int has 1 padding bit, 1 sign bit and 16 value bits
unsigned int has 2 padding bits and 16 value bits
INT_MIN == -65535
INT_MAX == +65535
UINT_MAX == +65535

....this is allowed.

--
Peter

[Keith Thompson]

Re: Binary number

infobahn <infobahn@btint ernet.com> writes:[color=blue]
> Keith Thompson wrote:[color=green]
>>[/color]
> <snip>
>[color=green]
>> In particular, an implementation with the following characteristics
>> could be conforming:
>>
>> CHAR_BIT == 8
>> sizeof(int) == 2
>> sizeof(unsigned int) == 2
>> int has 1 sign bit and 15 value bits (two's-complement)
>> unsigned int has 1 padding bit and 15 value bits
>> INT_MIN == -32768
>> INT_MAX == +32767
>> UINT_MAX == +32767
>>
>> If this is non-conforming, please indicate why.[/color]
>
> It's non-conforming because UINT_MAX must equal or exceed 65535.[/color]

Oops. Good catch, thanks.

Amend the above to:

CHAR_BIT == 8
sizeof(int) == 4
sizeof(unsigned int) == 4
int has 1 sign bit and 31 value bits (two's-complement)
unsigned int has 1 padding bit and 31 value bits
INT_MIN == -2147483648 /* -2**31 */
INT_MAX == +2147483647 /* 2**31-1 */
UINT_MAX == +2147483647 /* 2**31-1 */

There are, of course, many other possibilities.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[websnarf@gmail.com]

Re: Binary number

Davey wrote:[color=blue]
> How do I display an integer in binary format in C?
>
> e.g. 4 displayed as "100"[/color]

Just because I can't resist:

static void outBinaryInt (unsigned int l) {
if (!l) return;
outBinaryInt (l >> 1);
putchar ("01"[l&1]);
}

void outBinary (unsigned int l) {
if (l) outBinaryInt (l);
else putchar ("0");
}

Its not fast, but it will get the job done. :)

---
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sf.net/

[pete]

Re: Binary number

CBFalconer wrote:[color=blue]
>
> Peter Nilsson wrote:[color=green]
> > Stan Milam wrote:[color=darkred]
> >> CBFalconer wrote:[/color]
> >
> > <snip>
> >[color=darkred]
> >> CB, keep it small, keep it simple, keep it readable and you
> >> will be more productive and live longer.[/color]
> >
> > Any reason why you quoted the whole thing?
> >
> > Your post would be more productive if you pointed out the
> > issue with LONG_MIN within CBF's code. ;)[/color]
>
> What issue? A value of LONG_MIN is immediately converted to an
> unsigned long with a '-' sign emitted.[/color]

If LONG_MIN equals (-ULONG_MAX - 1), then there's the problem.
You didn't seem to understand the issue concerning INT_MIN
way back when we discussed itoa, either.

--
pete