Marco Manfredini <marco@technoboredom.net> writes:

> whatiscpp@yahoo.com (John the newbie) wrote:
>
> > I say "left-most" instead of "most significant" because I wonder (3rd
> > question :)): does the term "most significant" make sense for signed
> > values?
>
> Of course. The most significant bit is the one that does the greatest change
> to a number's value if toggled...

But then, it may depend on the number:

On a sign/magnitude representation, according to your definition the
sign bit will be the least significant bit for zero (because it
changes between plus zero and minus zero, which is actually a change
by zero), and it will be the most significant bit for the maximum
absolute value (because it will change the number by twice the maximum
absolute value, which no other bit will be able to do). For other
numbers, it will be somewhere in between those extremes (e.g. for 10,
it will be more significant than the bits at magnitude positions 0 to
4 [because they change the value by 1 to 16, while the sign bit
changes it by 20], but less significant then all higher value bits
[which change the value by at least 32, which is more than 20]).

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ron Natalie wrote:

>
> John the newbie wrote:
>
>
>>a) is it true?
>>
>
> No.  But it's hard to conceive of a design that would work that didn't
> use one.  The rule says that a signed type must have the same representation
> for it's positive values than an unsigned type, so unless you have a really
> screwy unsigned representation, the difference is going to be one bit.


     There have been machines with non-obvious integer representations.
You can still order a Unisys ClearPath server with a Burroughs
MCP compatibility processor.  The Burroughs machines treated
integers as small floating point numbers.  Numbers were
48 bits wide, with 32 bits of mantissa, 14 bits of exponent,
one bit of exponent sign, and one bit of mantissa sign.
The binary point was at the RIGHT end of the mantissa.
The effect of this was that if the high 16 bits were zero,
the low 32 bits represented an unsigned integer which was also
a valid floating-point number with the same value.  The
sign bit was not at the left of the mantissa bits; it was
left of the exponent and its sign bit.  Note also that
this was a signed-magnitude machine.

Admittedly, very few people today are likely to encounter
anything other than a twos-complement binary machine.


    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

> > No.  But it's hard to conceive of a design that would work that didn't
> > use one.  The rule says that a signed type must have the same representation
> > for it's positive values than an unsigned type, so unless you have a really
> > screwy unsigned representation, the difference is going to be one bit.
>
>      There have been machines with non-obvious integer representations.
> You can still order a Unisys ClearPath server with a Burroughs
> MCP compatibility processor.
[ Discussion of wierd Burroughs representation deleted]

But your example still uses a sign bit.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze <kanze@alex.gabi-soft.de> wrote :
(and again OE won't quote, maybe 8859-1??!@#$%?!)
>>>
Sort of.  The standard requires that the representation of common
values in the signed and unsigned types be identical.  About the only
way I can think of doing this without a sign bit is to have a sign
field, with some invalid values.
<<<
Or multiple sign bits, which is the slightly less unrealistic case.
E.g. on a machine with only signed 24-bit-word arithmetic, you might
construct 46-magnitude-bit (or less) long from two words by requiring
the sign bits be equal -- or use one and make the other padding.
Either way you'll have to do corrections on some operations, and
I haven't worked out which is better (which is to say, less awful).

>>>
The C99 standard goes further, and allows exactly three
representations for negative numbers: 2's complement, 1's complement
and signed magnitude.  In all of these representations, there is
exactly one bit which can be tested for the sign.
<<<
C99 requires exactly one sign bit, and & and << etc. provide
a way to test at least any nonpadding bit.  But AFAIK there's
no guaranteed way to _find_ it, only runtime trial and error
that risks overflow/UB.

--
- David.Thompson 1 now at worldnet.att.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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <EToB8.7683$vT1.656031@bgtnsc04-news.ops.worldnet.att.net>,
David Thompson <david.thompson1@worldnet.att.net> writes
>James Kanze <kanze@alex.gabi-soft.de> wrote :
>(and again OE won't quote, maybe 8859-1??!@#$%?!)
>>>>
>Sort of.  The standard requires that the representation of common
>values in the signed and unsigned types be identical.  About the only
>way I can think of doing this without a sign bit is to have a sign
>field, with some invalid values.

Well negative binary provides a mechanism where there is no sign bit,
but it fails to meet the other requirements of the standards (both C and
C++)


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ron Natalie wrote:
>
> >
> > |>  b) if it is true, am I garanteed that the sign bit is the left-most?
> > |>  Or can it be at the end, or even in the middle? This is, of course,
> > |>  important when converting from signed to unsigned or viceversa.
> >
> > The requirement is that the signed and unsigned representations have
> > the same representation for common values.  And that the
> > representation be binary.  This pretty much means that the only place
> > a signed representation can put the sign is in the high order bit (or
> > bits, if it uses several).
>
> No it doesn't say that (I assume we are talking C99, there isn't any
> statement in the other two standards).  It says the representation
> has value bits and pad bits (and a sign bit for the signed case).
> It doesn't say anything about the ordering of them.  You can stick a
> pad bit in the middle of the word if you want.  At least one implementation

Yes, but that bit, in the middle of the word, must either represent a
higher value in the unsigned type than any bit used by the signed type,
or be a padding bit for the unsigned type. That's because all of the
bits which have the same value as bits in the signed type, have to be in
the same location as they are in the signed type. It is therefore either
a higher order bit, or a padding bit.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3CCF3195.4513C2CC@wizard.net>...
> Ron Natalie wrote:
> >
> > >
> > > |>  b) if it is true, am I garanteed that the sign bit is the left-most?
> > > |>  Or can it be at the end, or even in the middle? This is, of course,
> > > |>  important when converting from signed to unsigned or viceversa.
> > >
> > > The requirement is that the signed and unsigned representations have
> > > the same representation for common values.  And that the
> > > representation be binary.  This pretty much means that the only place
> > > a signed representation can put the sign is in the high order bit (or
> > > bits, if it uses several).
> >
> > No it doesn't say that (I assume we are talking C99, there isn't any
> > statement in the other two standards).  It says the representation
> > has value bits and pad bits (and a sign bit for the signed case).
> > It doesn't say anything about the ordering of them.  You can stick a
> > pad bit in the middle of the word if you want.  At least one implementation
>
> Yes, but that bit, in the middle of the word, must either represent a
> higher value in the unsigned type than any bit used by the signed type,
> or be a padding bit for the unsigned type. That's because all of the
> bits which have the same value as bits in the signed type, have to be in
> the same location as they are in the signed type. It is therefore either
> a higher order bit, or a padding bit.


Yes, mathematically the only places where zeros are not significant is
at the left. Anyhow, I'm not convinced that sign bit(s) must be at
left for 3 reasons:

a) Herb Sutter says (if I understood him correctly) the contrary (see
http://groups.google.it/groups?selm=331326c7.223749034%40herbs)

b) the C++ standard doesn't limit representations to 2's complement,
1's complement and signed magnitude (3.9.1/7 gives them as examples
only)

c) the value representation of an object is defined (3.9/4) as "set of
bits" instead of "sequence of bits" (even though I'm pretty sure that
the intent was to mean the same as "sequence")


Where am I wrong?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

whatiscpp@yahoo.com (John the newbie) writes:

|>  "James Kuyper Jr." <kuyper@wizard.net> wrote in message
|>  news:<3CCF3195.4513C2CC@wizard.net>...
|>  > Ron Natalie wrote:

|>  Yes, mathematically the only places where zeros are not
|>  significant is at the left. Anyhow, I'm not convinced that sign
|>  bit(s) must be at left for 3 reasons:

|>  a) Herb Sutter says (if I understood him correctly) the contrary (see
|>  http://groups.google.it/groups?selm=3D331326c7.223749034%40herbs)

In that article, Herb was talking in general.  He also says nothing
about "left" or "right" (which I interpret to mean most significant
and least significant).

If you view an int or a long as an array of unsigned char, the sign
bit can appear elsewhere than in the first or the last byte.  There
have even been cases where this was true; in early versions of the
Microsoft C++ compiler (and, I think, the PDP-11 C compilers), the
sign bit was in the second byte.

However, the sign bit was in the second byte because this WAS the most
significant (left-most) byte of the representation of a long.  If you
shifted the long left, the sign bit was the first to go.  If you
masked all of the bits but the most significant (e.g. with &=3D
0x80000000), you were left with the sign bit, etc.

|>  b) the C++ standard doesn't limit representations to 2's complement,
|>  1's complement and signed magnitude (3.9.1/7 gives them as examples
|>  only)

No.  But it does require that the values common to both the signed and
the unsigned types have the same representation.  And it leaves no
liberty as to the representation of the unsigned types; they must be
pure binary.  This pretty much imposes 1) that all sign bit(s) are 0
in positive numbers, and 2) that the sign bit is located somewhere in
the bits that are not used to represent the range 0...XXX_MAX (where
XXX is INT, LONG, etc., according to the type).

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John the newbie wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3CCF3195.4513C2CC@wizard.net>...
> > Ron Natalie wrote:
....
> > > No it doesn't say that (I assume we are talking C99, there isn't any
> > > statement in the other two standards).  It says the representation
> > > has value bits and pad bits (and a sign bit for the signed case).
> > > It doesn't say anything about the ordering of them.  You can stick a
> > > pad bit in the middle of the word if you want.  At least one implementation
> >
> > Yes, but that bit, in the middle of the word, must either represent a
> > higher value in the unsigned type than any bit used by the signed type,
> > or be a padding bit for the unsigned type. That's because all of the
> > bits which have the same value as bits in the signed type, have to be in
> > the same location as they are in the signed type. It is therefore either
> > a higher order bit, or a padding bit.
>
> Yes, mathematically the only places where zeros are not significant is
> at the left. ...

I didn't say that. I said "either a higher order bit, or a padding bit"
- I didn't say anything to indicate whether the bit was to the left or
the right. The padding bits could be to the right of the value bits, as
easily as to the left. They could even be scattered randomly throughout
the object.

> ... Anyhow, I'm not convinced that sign bit(s) must be at
> left for 3 reasons:

I'm in full agreement with that conclusion, but I don't think your
reasons hold up.

> a) Herb Sutter says (if I understood him correctly) the contrary (see
> http://groups.google.it/groups?selm=331326c7.223749034%40herbs)

It doesn't matter that Herb said it, it only matters what he actually
said. What he said is correct, but that thread contains no specific
arguments for that conclusion, just bald statements of it.

> b) the C++ standard doesn't limit representations to 2's complement,
> 1's complement and signed magnitude (3.9.1/7 gives them as examples
> only)

Even in C99, which does impose those restrictions, the sign bit is still
not required to occupy any particular location, neither in absolute
terms, nor even relative to the other bits.

> c) the value representation of an object is defined (3.9/4) as "set of
> bits" instead of "sequence of bits" (even though I'm pretty sure that
> the intent was to mean the same as "sequence")

I'm not so sure that was the intent. I think that wording was a
deliberate attempt to avoid unnecessary over-specification. After all,
what does "sequence" mean for the bits of a multi-byte object? It's
argueably not even a meaningful concept. Physically, on many
architectures, bit-order is orthogonal to byte order. It's essentially
arbitrary whether the high order bit of a byte is treated as being
adjacent the low-order bit of the preceeding byte, or of the following
byte.
Both the C++ and C99 standard go out of their way to avoid saying that
the high order bit even has to be adjacent to either of those bits. It
could be in the middle of the byte, (or they could be).

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hi everybody,

it has been said me on comp.lang.c++.moderated that the standard
requirements on integers imply that their representation has a "sign
bit".

My questions are:

a) is it true?
b) if it is true, am I garanteed that the sign bit is the left-most?
Or can it be at the end, or even in the middle? This is, of course,
important when converting from signed to unsigned or viceversa.

I say "left-most" instead of "most significant" because I wonder (3rd
question :)): does the term "most significant" make sense for signed
values?

Thanks for your insights :)

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John the newbie wrote:

> a) is it true?

No.  But it's hard to conceive of a design that would work that didn't
use one.  The rule says that a signed type must have the same representation
for it's positive values than an unsigned type, so unless you have a really
screwy unsigned representation, the difference is going to be one bit.

> b) if it is true, am I garanteed that the sign bit is the left-most?
> Or can it be at the end, or even in the middle? This is, of course,
> important when converting from signed to unsigned or viceversa.

That really doesn't matter.
>
> I say "left-most" instead of "most significant" because I wonder (3rd
> question :)): does the term "most significant" make sense for signed
> values?
>
There's no requirements for the arrangment of the bits in any integer.
It's quite possible that the left-most bit (not counting the sign bit)
to be the least significant bit.  Really left and right is sort of a
perception issue anyhow.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

whatiscpp@yahoo.com (John the newbie) wrote:

> I say "left-most" instead of "most significant" because I wonder (3rd
> question :)): does the term "most significant" make sense for signed
> values?

Of course. The most significant bit is the one that does the greatest change
to a number's value if toggled...

Marco

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

whatiscpp@yahoo.com (John the newbie) writes:

|>  it has been said me on comp.lang.c++.moderated that the standard
|>  requirements on integers imply that their representation has a
|>  "sign bit".

|>  My questions are:

|>  a) is it true?

Sort of.  The standard requires that the representation of common
values in the signed and unsigned types be identical.  About the only
way I can think of doing this without a sign bit is to have a sign
field, with some invalid values.

The C99 standard goes further, and allows exactly three
representations for negative numbers: 2's complement, 1's complement
and signed magnitude.  In all of these representations, there is
exactly one bit which can be tested for the sign.

|>  b) if it is true, am I garanteed that the sign bit is the left-most?
|>  Or can it be at the end, or even in the middle? This is, of course,
|>  important when converting from signed to unsigned or viceversa.

The requirement is that the signed and unsigned representations have
the same representation for common values.  And that the
representation be binary.  This pretty much means that the only place
a signed representation can put the sign is in the high order bit (or
bits, if it uses several).

|>  I say "left-most" instead of "most significant" because I wonder
|>  (3rd question :)): does the term "most significant" make sense for
|>  signed values?

The "most significant bit" has a generally recognized meaning, derived
from its meaning for unsigned values, and the mapping of signed to
unsigned.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John the newbie wrote:
>
> Hi everybody,
>
> it has been said me on comp.lang.c++.moderated that the standard
> requirements on integers imply that their representation has a "sign
> bit".
>
> My questions are:
>
> a) is it true?

It doesn't say so, but it is indeed implied. Only for signed types, of
course.

> b) if it is true, am I garanteed that the sign bit is the left-most?
> Or can it be at the end, or even in the middle? This is, of course,
> important when converting from signed to unsigned or viceversa.

The standard says nothing about the physical location of any of the
bits; there's nothing special in this regard about the sign bit. Each
successive bit, in order of their significance, could even be in a
different byte of an integer type, if sizeof(type)>1.

It does say, however, that a signed type and the corresponding unsigned
type have the same value respesentation. This implies that the bit used
by the signed type to store it's sign can't be the same as any of the
bits used to represent any value that it shares with the corresponding
unsigned type. If that bit is used by the unsigned type (which isn't
required, except for unsigned character types), it has to represent a
value higher than any of the values of the corresponding integer type.

> I say "left-most" instead of "most significant" because I wonder (3rd
> question :)): does the term "most significant" make sense for signed
> values?

I think it's correct (in a certain sense) to say that the sign bit is
the most significant bit of a signed type, because it is the bit that,
on the average, causes the largest change in value when it is changed.
However, that fact is completely independent of the physical location of
the bit.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

>
> |>  b) if it is true, am I garanteed that the sign bit is the left-most?
> |>  Or can it be at the end, or even in the middle? This is, of course,
> |>  important when converting from signed to unsigned or viceversa.
>
> The requirement is that the signed and unsigned representations have
> the same representation for common values.  And that the
> representation be binary.  This pretty much means that the only place
> a signed representation can put the sign is in the high order bit (or
> bits, if it uses several).

No it doesn't say that (I assume we are talking C99, there isn't any
statement in the other two standards).  It says the representation
has value bits and pad bits (and a sign bit for the signed case).
It doesn't say anything about the ordering of them.  You can stick a
pad bit in the middle of the word if you want.  At least one implementation
that I know of actually had this.   The Varian V99 (an early C and UNIX
porting target) had a long format that was only 31 bits.  This
16 bit worded machine for some reason skipped over what would have
been the sign bit in one of the two words when making its double
word integer type.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]