Bit shifts and endianness
gamehack
I was thinking today, suppose we have the number
n = 0xAB 0xFF
which is equivalent to 44031 in decimal. In big endian it will be
stored as
10101011 11111111
but in little endian it will be
11111111 10101011
If we then apply a bit shift n << 2; that would give us completely
different numbers. So is actually a left bit shift done to the left on
a big-endian and left bit shift on little endian is actually a right
shift in the memory?
Thanks a lot
PS. What other problems arise from endianness? Are there any good
resources on that?
Keith Thompson
> I was thinking today, suppose we have the number
> n = 0xAB 0xFF
That's two numbers. Do you mean 0xABFF?
> which is equivalent to 44031 in decimal.
Apparently so.
> In big endian it will be
> stored as
> 10101011 11111111
> but in little endian it will be
> 11111111 10101011
> If we then apply a bit shift n << 2; that would give us completely
> different numbers.
No. Shift operators are defined on the *values* of their operands,
not on their representations.
--
Keith Thompson (The_Other_Keith) ks...@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.
gamehack
Keith Thompson wrote:
> "gamehack" <game...@gmail.com> writes:
> > I was thinking today, suppose we have the number
> > n = 0xAB 0xFF
>
> That's two numbers. Do you mean 0xABFF?
>
> > which is equivalent to 44031 in decimal.
>
> Apparently so.
>
> > In big endian it will be
> > stored as
> > 10101011 11111111
> > but in little endian it will be
> > 11111111 10101011
> > If we then apply a bit shift n << 2; that would give us completely
> > different numbers.
>
> No. Shift operators are defined on the *values* of their operands,
> not on their representations.
>
Mark McIntyre
<ks...@mib.org> wrote:
>"gamehack" <game...@gmail.com> writes:
>> I was thinking today, suppose we have the number
>> 10101011 11111111
>> but in little endian it will be
>> 11111111 10101011
>> If we then apply a bit shift n << 2; that would give us completely
>> different numbers.
>
>No. Shift operators are defined on the *values* of their operands,
>not on their representations.
Clarification: I assume you mean that shift operators operate on a
binary value, irrespective of how that is stored on disk or in memory.
I'm saying this because few humans would think of the value of 0xabff
as the value in binary. :-)
(and please, don't start another one of those tedious "well patently
what I said is 'right', so you're a fool" discussions again, I really
don't want to have to express my opinion of people who can't accept
that there may be more than one way to skin a cat).
Mark McIntyre
--
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
sleb...@gmail.com
> On Thu, 05 Jan 2006 20:26:11 GMT, in comp.lang.c , Keith Thompson
> <ks...@mib.org> wrote:
>
> >"gamehack" <game...@gmail.com> writes:
> >> I was thinking today, suppose we have the number
>
> >> 10101011 11111111
> >> but in little endian it will be
> >> 11111111 10101011
> >> If we then apply a bit shift n << 2; that would give us completely
> >> different numbers.
> >
> >No. Shift operators are defined on the *values* of their operands,
> >not on their representations.
>
> Clarification: I assume you mean that shift operators operate on a
> binary value, irrespective of how that is stored on disk or in memory.
> I'm saying this because few humans would think of the value of 0xabff
> as the value in binary. :-)
>
Yeah, I had this misconception before. 0xabff >> 8 always gives me
0x00ab regardless of weather the machine is big endian or little
endian. Endianness just defines weather 'ab' comes before or after 'ff'
in memory. It doesn't affect binary operations. Endianness is only an
issue when you are transferring data between machines via a file or a
network, not when you are doing the computing.
Richard Heathfield
> On Thu, 05 Jan 2006 20:26:11 GMT, in comp.lang.c , Keith Thompson
> <ks...@mib.org> wrote:
>
>>No. Shift operators are defined on the *values* of their operands,
>>not on their representations.
>
> Clarification: I assume you mean that shift operators operate on a
> binary value,
No, they operate on a value. Values don't have number bases. That's merely a
representation issue.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield
> 0xabff >> 8 always gives me 0x00ab regardless of weather
Even so, I don't recommend that you try this in the rain.
Keith Thompson
> On Thu, 05 Jan 2006 20:26:11 GMT, in comp.lang.c , Keith Thompson
> <ks...@mib.org> wrote:
>>"gamehack" <game...@gmail.com> writes:
>>> I was thinking today, suppose we have the number
>
>>> 10101011 11111111
>>> but in little endian it will be
>>> 11111111 10101011
>>> If we then apply a bit shift n << 2; that would give us completely
>>> different numbers.
>>
>>No. Shift operators are defined on the *values* of their operands,
>>not on their representations.
>
> Clarification: I assume you mean that shift operators operate on a
> binary value, irrespective of how that is stored on disk or in memory.
> I'm saying this because few humans would think of the value of 0xabff
> as the value in binary. :-)
That's one way of looking at it.
The standard describes the result of a shift operator both as "E1
(left|right)-shifted E2 bit positions" and in terms of multiplication
or division by powers of 2. I think the latter is intended to define
what the standard means by the terms "(left|right)-shifted". The
standard could as easily have defined the operators purely in terms of
multiplication or division with no reference to shifting, with the
resulting wording describing exactly the same semantics.
One advantage of describing it this way is that it avoids the OP's
question; "<<" and ">>" don't depend on endianness any more than "+"
and "-" do, and there's no potential ambiguity about the meanings of
"left" and "right".
Jordan Abel
> Mark McIntyre said:
>
>> On Thu, 05 Jan 2006 20:26:11 GMT, in comp.lang.c , Keith Thompson
>> <ks...@mib.org> wrote:
>>
>>>No. Shift operators are defined on the *values* of their operands,
>>>not on their representations.
>>
>> Clarification: I assume you mean that shift operators operate on a
>> binary value,
>
> No, they operate on a value. Values don't have number bases. That's merely a
> representation issue.
The standard mentions "bits" in too many places for me to believe this.
Eric Sosman
> sleb...@yahoo.com said:
>
>
>>0xabff >> 8 always gives me 0x00ab regardless of weather
>
>
> Even so, I don't recommend that you try this in the rain.
... lest the negative sign give you a positive charge ...
--
Eric Sosman
eso...@acm-dot-org.invalid
Chris Torek
sleb...@yahoo.com <sleb...@gmail.com> wrote:
>... Endianness is only an issue when you are transferring
>data between machines via a file or a network ...
More precisely (and more correctly :-) ), "endianness" becomes
an issue whenever someone or something takes a value apart,
so that there is a "before" and an "after", or a "left" and a
"right", or some other way of sequencing parts of the value.
For instance, imagine you are moving from one place of living to
another (e.g., moving apartments). Your car has room for 1/3 of
your bed, but not the whole thing. You take a saw to the bed and
cut it into thirds. You then transport each third to your new
location and reassemble it.
You need to reassemble it in the same order you took it apart, or
it will likely be quite uncomfortable to sleep in. :-)
Endianness in computers arises when you allow the machine to take
a value apart and ship it somewhere, and then allow some other
machine to put it together again. If the two machines use the same
order, all is well, but if they use different orders, your bed is
no longer very useful.
There are a number of ways to handle this, but the simplest is:
do the disassembly and reassembly yourself. Instead of letting
the machine do it in "machine order", do it yourself and control
the order.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Eric Sosman
Yeah. And there's also the requirement for a "pure binary"
representation. Nonetheless, I stick with the Heathfield Maxim:
operators operate on values, not on representations. When the
Standard describes ^ or >> in terms of bits, it does so merely
as a convenience, as an appeal to the readers' understanding of
binary arithmetic. Nowhere (that I can see) is there a requirement
that the arithmetic actually be carried out bit-by-bit or even
bits-in-parallel; it's just easier for the Standard to describe
`x & 17' by referring to binary digits than by avoiding such a
reference. (Quick: Describe `x & 17' without reference to bits.
It can surely be done, but I expect the description would be
verbose and opaque even by the standards of Standardese.)
Let's put it this way: Imagine a machine with two "banks"
of memory, whose stoned-out-of-their-gourds designers have
decided should have different endiannesses. If `x' is in the
BigEndian bank and `y' in the LittleEndian, what is the effect
of `x = 1; y = x << 1;'? I claim that the effect must be the
same as `x = 1; y = 2;', or else the implementation is broken.
The fact that the representations differ just doesn't matter.
--
Eric Sosman
eso...@acm-dot-org.invalid
Keith Thompson
The standard imposes some fairly stringent requirements on how
integer, both signed and unsigned, are represented. These
requirements are tight enough to guarantee (I think) that the
"multiple or divide by powers of 2" and "shift by N bits" models of
the "<<" and ">>" operators turn out to be equivalent (with the
proviso that any padding bits don't participate).
Once could imagine a hypothetical C standard that doesn't place any
requirements on the representations of integers, but that defines "<<"
and ">>" in much the same way as the actual standard does. An
implementation conforming to this hypothetical standard could use,
say, a trinary hardware representation for integers, but would still
have to implement "<<" and ">>" so they yield the same results as on a
binary machine. (In fact, such an implementation would probably be
legal under the actual C standard as long as it does a sufficiently
good job of hiding the trinary hardware behind a binary-looking
interface.)
Keith Thompson
[...]
> The standard imposes some fairly stringent requirements on how
> integer, both signed and unsigned, are represented. These
> requirements are tight enough to guarantee (I think) that the
> "multiple or divide by powers of 2" and "shift by N bits" models of
> the "<<" and ">>" operators turn out to be equivalent (with the
> proviso that any padding bits don't participate).
Since not everyone has a copy of the standard, here's what C99 says in
its description of the bitwise shift operators. (I've replaced the
multiplication symbol 'x' with "*", and the superscript exponent with
a "**" operator.)
The integer promotions are performed on each of the operands. The
type of the result is that of the promoted left operand. If the
value of the right operand is negative or is greater than or equal
to the width of the promoted left operand, the behavior is
undefined.
The result of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are filled with zeros. If E1 has an unsigned type,
the value of the result is E1 * 2**E2, reduced modulo one more
than the maximum value representable in the result type. If E1 has
a signed type and nonnegative value, and E1 * 2**E2 is
representable in the result type, then that is the resulting
value; otherwise, the behavior is undefined.
The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1
has an unsigned type or if E1 has a signed type and a nonnegative
value, the value of the result is the integral part of the
quotient of E1 / 2**E2. If E1 has a signed type and a negative
value, the resulting value is implementation-defined.
Keith Thompson
[...]
> Yeah. And there's also the requirement for a "pure binary"
> representation. Nonetheless, I stick with the Heathfield Maxim:
> operators operate on values, not on representations. When the
> Standard describes ^ or >> in terms of bits, it does so merely
> as a convenience, as an appeal to the readers' understanding of
> binary arithmetic. Nowhere (that I can see) is there a requirement
> that the arithmetic actually be carried out bit-by-bit or even
> bits-in-parallel; it's just easier for the Standard to describe
> `x & 17' by referring to binary digits than by avoiding such a
> reference. (Quick: Describe `x & 17' without reference to bits.
> It can surely be done, but I expect the description would be
> verbose and opaque even by the standards of Standardese.)
I wouldn't try to describe x & 17 without reference to bits. Rather,
I'd define "bits" in terms of the arithmetic properties of the number,
and *then* define x & 17 in terms of the "bits" I've defined.
Something along the lines of:
An integer value in the range 0..2**(n-1) can be uniquely defined
as a sum of powers of two: ... + b3 * 2**3 + b2 * 2**2 + b1 * 2**1
+ b0 * 2**0. Each bn value is referred to as the nth _bit_ of the
integer value.
With this definition, it becomes irrelevant whether these "bits"
correspond to some on-off state in hardware somewhere; the description
applies equally well to numbers represented in decimal or trinary.
Eric Sosman
> Eric Sosman <eso...@acm-dot-org.invalid> writes:
>>It can surely be done, but I expect the description would be
>>verbose and opaque even by the standards of Standardese.)
>
>
> I wouldn't try to describe x & 17 without reference to bits. Rather,
> I'd define "bits" in terms of the arithmetic properties of the number,
> and *then* define x & 17 in terms of the "bits" I've defined.
> Something along the lines of:
>
> An integer value in the range 0..2**(n-1) can be uniquely defined
> as a sum of powers of two: ... + b3 * 2**3 + b2 * 2**2 + b1 * 2**1
> + b0 * 2**0. Each bn value is referred to as the nth _bit_ of the
> integer value.
>
> With this definition, it becomes irrelevant whether these "bits"
> correspond to some on-off state in hardware somewhere; the description
> applies equally well to numbers represented in decimal or trinary.
Right, and that's the point: C's operators[*] are defined
in terms of the values of the operands and the value of the
result. They are not defined in terms of the representations
of those values, but in terms of the values themselves, however
represented.
[*] "Ordinary" operators, anyhow. Special operators like
`.' don't fit well with this way of understanding -- but not
even these oddballs work with the representations of their
operands.
As a concrete example of a situation where values are
represented without any individual "bit-artifacts" being
present, consider the data stream between two modems. If I
understand correctly (I'm not a modem maven), each change in
the signal encodes an entire group of bits: one phase shift
represents 000, another phase shift represents 010, and so
on. "Value bits" are transmitted, but no isolated "signal
bits" are discernible.
--
Eric Sosman
eso...@acm-dot-org.invalid
Jordan Abel
That doesn't mean it's not a "binary value" - which, if you were
paying attention, is the claim you are attempting to refute.
Eric Sosman
>
> That doesn't mean it's not a "binary value" - which, if you were
> paying attention, is the claim you are attempting to refute.
Thank you, Jordan, for drawing my attention to my
inattention. Tracing back the thread, though, I find
this remark from Mark McIntyre:
> No, they operate on a value. Values don't have number bases.
> That's merely a representation issue.
... to which you responded:
> The standard mentions "bits" in too many places for me to
> believe this.
McIntyre says the shift operators work on values, not
representations, and you say you don't believe him. That's
what I'm trying to refute: I add my voice to the McIntyre
(and Heathfield) chorus to say that you are mistaken.
But perhaps the "this" in your response referred to
something else altogether?
--
Eric Sosman
eso...@acm-dot-org.invalid
Walter Roberson
Eric Sosman <eso...@acm-dot-org.invalid> wrote:
> As a concrete example of a situation where values are
>represented without any individual "bit-artifacts" being
>present, consider the data stream between two modems. If I
>understand correctly (I'm not a modem maven), each change in
>the signal encodes an entire group of bits: one phase shift
>represents 000, another phase shift represents 010, and so
>on. "Value bits" are transmitted, but no isolated "signal
>bits" are discernible.
There are a number of different encoding mechanisms used for
modems designed for use with telephone lines (the term 'modem'
applies to a number of other situations as well.) The first standards,
for 110 and 300 baud, were straight single-frequency carriers with
no phase encoding. 1200 baud was, if I recall correctly, dual frequency
but not phase encoded. All of the CCITT standard encodings from 2400 baud
upwards rely upon phase encoding. The proprietary Telebit protocols
worked rather differently (128 or 256 frequency channels but
individual signals were held for long periods.)
It is not exactly accurate to say that -each- change in the signal
encodes a group of bits; rather, the signal is sampled at several
intervals along the cycle, and the details of the "phase breaking"
that is imposed on the base sine wave over that interval encodes
a cluster of bits in a completely non-linear non-binary manner
[i.e., there is no single aspect of the phase changes that encodes
any one particular bit.]
Especially for the higher speeds, extra "logical" bits are encoded into
the signal, and the decoded group of bits is run through a
"constellation" corrector to find the most probable original bit group.
In theory the constellation corrector could map to a bit grouping that
had no obvious resemblance to the bits read off of the signal -- with
the non-linear encoding of bits and taking into account the need for
some slosh while the signal slews, the constellation correction could
decide that one should have chosen a different non-linear decoding.
Another example of non-binary encoding is gigabit ethernet, which
starts with the signaling mechanisms used for 100 megabit ethernet,
raised the carrier frequency from 100 megahertz to 125 megahertz,
but then does phase encoding and constellation correction that extracts
10 databits from each 16 signal values decoded out of the wave.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
Richard Heathfield
> Jordan Abel wrote:
>>
>> That doesn't mean it's not a "binary value" - which, if you were
>> paying attention, is the claim you are attempting to refute.
>
> Thank you, Jordan, for drawing my attention to my
> inattention. Tracing back the thread, though, I find
> this remark from Mark McIntyre:
>
> > No, they operate on a value. Values don't have number bases.
> > That's merely a representation issue.
No, those are my words, not Mark's.
Eric Sosman
> Eric Sosman said:
>
>
>>Jordan Abel wrote:
>>
>>>That doesn't mean it's not a "binary value" - which, if you were
>>>paying attention, is the claim you are attempting to refute.
>>
>> Thank you, Jordan, for drawing my attention to my
>>inattention. Tracing back the thread, though, I find
>>this remark from Mark McIntyre:
>>
>> > No, they operate on a value. Values don't have number bases.
>> > That's merely a representation issue.
>
>
> No, those are my words, not Mark's.
Woops! My apologies for the misattribution.
--
Eric Sosman
eso...@acm-dot-org.invalid
Chuck F.
> Jordan Abel wrote:
>>
>> That doesn't mean it's not a "binary value" - which, if you
>> were paying attention, is the claim you are attempting to
>> refute.
>
> Thank you, Jordan, for drawing my attention to my inattention.
> Tracing back the thread, though, I find this remark from Mark
> McIntyre:
>
>> No, they operate on a value. Values don't have number bases.
>> That's merely a representation issue.
>
>
>> The standard mentions "bits" in too many places for me to
>> believe this.
>
> McIntyre says the shift operators work on values, not
> representations, and you say you don't believe him. That's what
> I'm trying to refute: I add my voice to the McIntyre (and
> Heathfield) chorus to say that you are mistaken.
You can pick out any bit from a value, regardless of the underlying
representation, by dividing by a suitable power of 2, and then
taking the result modulo 2. The latter is simply the Pascal
function odd(n).
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Jordan Abel
>>
>> That doesn't mean it's not a "binary value" - which, if you were
>> paying attention, is the claim you are attempting to refute.
>
> Thank you, Jordan, for drawing my attention to my
> inattention. Tracing back the thread, though, I find
> this remark from Mark McIntyre:
>
> > No, they operate on a value. Values don't have number bases.
> > That's merely a representation issue.
>
> ... to which you responded:
>
> > The standard mentions "bits" in too many places for me to
> > believe this.
>
> McIntyre says the shift operators work on values, not
> representations, and you say you don't believe him.
No. The statement i disbelieved was "Values don't have number bases".
The base of an integer value is 2. The base of a floating-point value is
FLT_RADIX (2 on my system, may be 10 on others for example).
Eric Sosman
> Eric Sosman wrote:
>
>> Jordan Abel wrote:
>>
>>>
>>> That doesn't mean it's not a "binary value" - which, if you
>>> were paying attention, is the claim you are attempting to
>>> refute.
>>
>>
>> Thank you, Jordan, for drawing my attention to my inattention.
>> Tracing back the thread, though, I find this remark from Mark
>> McIntyre:
>>
>>> No, they operate on a value. Values don't have number bases. That's
>>> merely a representation issue.
>>
>>
>> .... to which you responded:
>>
>>> The standard mentions "bits" in too many places for me to believe this.
>>
>>
>> McIntyre says the shift operators work on values, not representations,
>> and you say you don't believe him. That's what
>> I'm trying to refute: I add my voice to the McIntyre (and
>> Heathfield) chorus to say that you are mistaken.
>
>
> You can pick out any bit from a value, regardless of the underlying
> representation, by dividing by a suitable power of 2, and then taking
> the result modulo 2. The latter is simply the Pascal function odd(n).
Right. And you can pick out a trit by dividing by a suitable
power of three and taking the result modulo 3. Or you can pick
out quits with fours, quints with fives, dits with tens, twits
with twelves, and so on. As Richard Heathfield says (misattributed
by me to Mark McIntyre), "values don't have number bases." No
matter how many fingers you have, pi is pi is pi.
--
Eric Sosman
eso...@acm-dot-org.invalid
Richard Heathfield
> The statement i disbelieved was "Values don't have number bases".
Then your beef is with me.
> The base of an integer value is 2.
No, it's not, neither in mathematics nor in C.
int i = 42;
Here, the 42 represents an integer. The representation used is denary, also
known as decimal.
int j = 052;
Here, the 052 represents an integer. The representation used is octal.
int k = 0x2A;
Here, the 0x2A represents an integer. The representation used is
hexadecimal.
In each of these three cases, the value is the same: it's the number of
asterisks in the following collection:
*****
*******
*********
*********
*******
*****
We have seen the same integer value represented in three different bases,
none of which was binary, and in a non-positional representation as well.
Values *don't* have bases. Bases are what we use to /represent/ values.
Mark McIntyre
<ks...@mib.org> wrote:
>Something along the lines of:
>
> An integer value in the range 0..2**(n-1) can be uniquely defined
> as a sum of powers of two: ... + b3 * 2**3 + b2 * 2**2 + b1 * 2**1
> + b0 * 2**0. Each bn value is referred to as the nth _bit_ of the
> integer value.
This is a representation of the value.
Mark McIntyre
<rand...@gmail.com> wrote:
For some reason RJH's original post didn't make it here. However, my
response would have been " Rubbish", which is rare for a response to
an RJH post.
One can I suppose argue that you break the number down into a sum of
powers of two. Er, guys, thats called a "representation".
Richard Heathfield
> On 6 Jan 2006 00:21:20 GMT, in comp.lang.c , Jordan Abel
> <rand...@gmail.com> wrote:
>
>>On 2006-01-05, Richard Heathfield <inv...@invalid.invalid> wrote:
>>> Mark McIntyre said:
>>>
>>>> Clarification: I assume you mean that shift operators operate on a
>>>> binary value,
>>>
>>> No, they operate on a value. Values don't have number bases. That's
>>> merely a representation issue.
>>
>>The standard mentions "bits" in too many places for me to believe this.
>
> For some reason RJH's original post didn't make it here. However, my
> response would have been " Rubbish", which is rare for a response to
> an RJH post.
That fact alone should give you pause for thought. What makes you think my
statement is rubbish?
mensa...@aol.com
Mark McIntyre wrote:
> On 6 Jan 2006 00:21:20 GMT, in comp.lang.c , Jordan Abel
> <rand...@gmail.com> wrote:
>
> >On 2006-01-05, Richard Heathfield <inv...@invalid.invalid> wrote:
> >> Mark McIntyre said:
> >>
> >>> On Thu, 05 Jan 2006 20:26:11 GMT, in comp.lang.c , Keith Thompson
> >>> <ks...@mib.org> wrote:
> >>>
> >>>>No. Shift operators are defined on the *values* of their operands,
> >>>>not on their representations.
> >>>
> >>> Clarification: I assume you mean that shift operators operate on a
> >>> binary value,
> >>
> >> No, they operate on a value. Values don't have number bases. That's merely a
> >> representation issue.
> >
> >The standard mentions "bits" in too many places for me to believe this.
>
> For some reason RJH's original post didn't make it here. However, my
> response would have been " Rubbish", which is rare for a response to
> an RJH post.
>
> One can I suppose argue that you break the number down into a sum of
> powers of two. Er, guys, thats called a "representation".
But you must pick a representation to create an "implementation",
right?
You could implement integer representations as strings of characters
"0" and "1" and have unlimited precision arithmetic. Am I correct in
assuming the standard would allow this as long as evrything behaves as
it should?
Gordon Burditt
>right?
>
>You could implement integer representations as strings of characters
>"0" and "1" and have unlimited precision arithmetic. Am I correct in
>assuming the standard would allow this as long as evrything behaves as
>it should?
But it *WON'T* behave as it should. int can't be a variable size.
Also, there are practical and economic problems with sizeof(int) = infinity.
You could choose a large but finite size (say, 1 gigabit integers),
and that could be made to work.
Gordon L. Burditt
Joe Wright
> Mark McIntyre said:
>
>
>>On 6 Jan 2006 00:21:20 GMT, in comp.lang.c , Jordan Abel
>><rand...@gmail.com> wrote:
>>
>>
>>>On 2006-01-05, Richard Heathfield <inv...@invalid.invalid> wrote:
>>>
>>>>Mark McIntyre said:
>>>>
>>>>
>>>>>Clarification: I assume you mean that shift operators operate on a
>>>>>binary value,
>>>>
>>>>No, they operate on a value. Values don't have number bases. That's
>>>>merely a representation issue.
>>>
>>>The standard mentions "bits" in too many places for me to believe this.
>>
>>For some reason RJH's original post didn't make it here. However, my
>>response would have been " Rubbish", which is rare for a response to
>>an RJH post.
>
>
> That fact alone should give you pause for thought. What makes you think my
> statement is rubbish?
>
Because 'stored' values do have number bases. You seem to be playing
games with language. Values in C stored in 'int x' have binary
representation in memory. Whether 42, 052 or 0x2A the int in memory
looks something like 0..00101010 in binary. The value of 'x >> 1' will
look like 0..00010101 which seems to be a binary operation to me.
What am I missing?
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Richard Heathfield
> Because 'stored' values do have number bases.
They do?
> You seem to be playing games with language.
Not trying to, sir. Although C /is/ a language, sir. But the concept of
"number" is independent of and therefore does not rely on the concept of
"base".
> Values in C stored in 'int x' have binary
> representation in memory.
Representation, yes. I don't dispute that. So what? That's merely a
representation issue.
> Whether 42, 052 or 0x2A the int in memory
> looks something like 0..00101010 in binary.
And in bits, it looks like a really scary Feynman diagram, I expect. So?
It's just how it looks, not what it /is/.
> The value of 'x >> 1' will
> look like 0..00010101 which seems to be a binary operation to me.
>
> What am I missing?
The fact that we're not talking about representation here.
Mark McIntyre
Heathfield <inv...@invalid.invalid> wrote:
>Mark McIntyre said:
>
>>
>> For some reason RJH's original post didn't make it here. However, my
>> response would have been " Rubbish", which is rare for a response to
>> an RJH post.
>
>That fact alone should give you pause for thought. What makes you think my
>statement is rubbish?
Because it was intrinsically meaningless.
Mark McIntyre
Heathfield <inv...@invalid.invalid> wrote:
>Joe Wright said:
>
>> Because 'stored' values do have number bases.
>
>They do?
Yes. Obtuseness aside. Go ahead, though, design a baseless storage
mechanism and build a computer with it.... :-)
>It's just how it looks, not what it /is/.
Oh, philosophy now? Hmm, and we're not playing games?
>> What am I missing?
>
>The fact that we're not talking about representation here.
I'm afraid you are.
Richard Heathfield
> On Sat, 7 Jan 2006 00:21:16 +0000 (UTC), in comp.lang.c , Richard
> Heathfield <inv...@invalid.invalid> wrote:
>
>>Mark McIntyre said:
>>
>>>
>>> For some reason RJH's original post didn't make it here. However, my
>>> response would have been " Rubbish", which is rare for a response to
>>> an RJH post.
>>
>>That fact alone should give you pause for thought. What makes you think my
>>statement is rubbish?
>
> Because it was intrinsically meaningless.
Well, Mark, I must disagree, and I think you'll find any mathematician worth
his salt disagreeing with you too. Values are indeed independent of number
base, whether you see meaning in that statement or not.
Richard Heathfield
> On Sat, 7 Jan 2006 15:44:55 +0000 (UTC), in comp.lang.c , Richard
> Heathfield <inv...@invalid.invalid> wrote:
>
>>Joe Wright said:
>>
>>> Because 'stored' values do have number bases.
>>
>>They do?
>
> Yes. Obtuseness aside. Go ahead, though, design a baseless storage
> mechanism and build a computer with it.... :-)
Oh, that's been done. Many times. Look up "analog computer".
>>It's just how it looks, not what it /is/.
>
> Oh, philosophy now?
You can call it that if you want. But I call it mathematics.
> Hmm, and we're not playing games?
Well, I'm not, but it seems you are.
>
>>> What am I missing?
>>
>>The fact that we're not talking about representation here.
>
> I'm afraid you are.
No, we really really are not.
Gordon Burditt
Representations have bases. Values do not.
>You seem to be playing
>games with language. Values in C stored in 'int x' have binary
>representation in memory. Whether 42, 052 or 0x2A the int in memory
>looks something like 0..00101010 in binary. The value of 'x >> 1' will
>look like 0..00010101 which seems to be a binary operation to me.
>
>What am I missing?
If I add 5 in base two to 3 in base five, what base is the result
in? Why? If your answer is "any base you want it to be in", this
really suggests that the base is separate from the value.
Oh, yes, what base is the *BASE* in?
Gordon L. Burditt
sleb...@gmail.com
> On 2006-01-06, Eric Sosman <eso...@acm-dot-org.invalid> wrote:
> > Thank you, Jordan, for drawing my attention to my
> > inattention. Tracing back the thread, though, I find
> > this remark from Mark McIntyre:
> >
> > > No, they operate on a value. Values don't have number bases.
> > > That's merely a representation issue.
>
> No. The statement i disbelieved was "Values don't have number bases".
> The base of an integer value is 2.
Actually, that's not correct. The base of the BINARY REPRESENTATION of
an integer is 2. The base of the decimal representation of an integer
is 10. The base of the hexadecimal representation of an integer is 16.
etc..
Values don't have number bases. That's only their representation.
Chuck F.
It's time to start talking about 1 to 1 correspondence with the set
of cardinals. :-)
Eric Sosman
> [...]
> It's time to start talking about 1 to 1 correspondence with the set of
> cardinals. :-)
Seems appropriate for a discussion that's become
increasingly about religion.
--
Eric Sosman
eso...@acm-dot-org.invalid
Jordan Abel
> Mark McIntyre said:
>
>> On Sat, 7 Jan 2006 00:21:16 +0000 (UTC), in comp.lang.c , Richard
>> Heathfield <inv...@invalid.invalid> wrote:
>>
>>>Mark McIntyre said:
>>>
>>>>
>>>> For some reason RJH's original post didn't make it here. However, my
>>>> response would have been " Rubbish", which is rare for a response to
>>>> an RJH post.
>>>
>>>That fact alone should give you pause for thought. What makes you think my
>>>statement is rubbish?
>>
>> Because it was intrinsically meaningless.
>
> Well, Mark, I must disagree, and I think you'll find any mathematician
> worth his salt disagreeing with you too. Values are indeed independent
> of number base, whether you see meaning in that statement or not.
What could a mathematician possibly have to say about the nature of the
values of C data types?
Jordan Abel
Clearly you can only add numbers in the same base - so the result is in
whichever base you converted one or the other (or both) to.
Since an int is made up of "value bits", "padding bits", and a "sign
bit", clearly it has a binary value. There is no provision for a "sign
decimal digit" or a "padding hex digit".
Coos Haak
> Since an int is made up of "value bits", "padding bits", and a "sign
> bit", clearly it has a binary value. There is no provision for a "sign
> decimal digit" or a "padding hex digit".
Even Leibniz would have understood the word "bit" as meaning "a part of"
It has nothing to do here with binary.
My native dialect knows the same meaning.
--
Coos
't is gewoon een bitje zot
Keith Thompson
Leibniz wasn't a computer scientist.
Yes the English word "bit" means, among other things, "a small piece
or quantity of some material thing", but the word used in the C
standard (which has the same spelling and pronunciation, but is a
different word) is a contraction of "binary digit".
The C standard defines a "bit" as a "unit of data storage in the
execution environment large enough to hold an object that may have one
of two values".
--
Keith Thompson (The_Other_Keith) ks...@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.
Keith Thompson
> Coos Haak <chf...@hccnet.nl> writes:
>> Op 8 Jan 2006 19:02:18 GMT schreef Jordan Abel:
>>
>>> Since an int is made up of "value bits", "padding bits", and a "sign
>>> bit", clearly it has a binary value. There is no provision for a "sign
>>> decimal digit" or a "padding hex digit".
>>
>> Even Leibniz would have understood the word "bit" as meaning "a part of"
>> It has nothing to do here with binary.
>>
>> My native dialect knows the same meaning.
>
> Leibniz wasn't a computer scientist.
I probably should have said that Leibniz wasn't a *modern* computer
scientist. (He invented, but didn't publish, a form of symbolic logic
about 180 years before George Boole). The term "bit" meaning "binary
digit" only goes back to 1948.
ozbear
>On 2006-01-08, Gordon Burditt <gordon...@burditt.org> wrote:
>>>Because 'stored' values do have number bases.
>>
>> Representations have bases. Values do not.
>>
>>>You seem to be playing
>>>games with language. Values in C stored in 'int x' have binary
>>>representation in memory. Whether 42, 052 or 0x2A the int in memory
>>>looks something like 0..00101010 in binary. The value of 'x >> 1' will
>>>look like 0..00010101 which seems to be a binary operation to me.
>>>
>>>What am I missing?
>>
>> If I add 5 in base two to 3 in base five, what base is the result
>> in? Why? If your answer is "any base you want it to be in", this
>> really suggests that the base is separate from the value.
>
>Clearly you can only add numbers in the same base - so the result is in
>whichever base you converted one or the other (or both) to.
>
I can add 1, base 36, to 77, base 8 quite easily.
Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Joe Wright
> On 8 Jan 2006 19:02:18 GMT, Jordan Abel <rand...@gmail.com> wrote:
>
>
>>On 2006-01-08, Gordon Burditt <gordon...@burditt.org> wrote:
>>
>>>>Because 'stored' values do have number bases.
>>>
>>>Representations have bases. Values do not.
>>>
>>>
>>>>You seem to be playing
>>>>games with language. Values in C stored in 'int x' have binary
>>>>representation in memory. Whether 42, 052 or 0x2A the int in memory
>>>>looks something like 0..00101010 in binary. The value of 'x >> 1' will
>>>>look like 0..00010101 which seems to be a binary operation to me.
>>>>
>>>>What am I missing?
>>>
>>>If I add 5 in base two to 3 in base five, what base is the result
>>>in? Why? If your answer is "any base you want it to be in", this
>>>really suggests that the base is separate from the value.
>>
>>Clearly you can only add numbers in the same base - so the result is in
>>whichever base you converted one or the other (or both) to.
>>
>
>
> I can add 1, base 36, to 77, base 8 quite easily.
>
> Oz
You should check with Richard Heathfield for permission before you do
that. 77 base 8 may not be a value, but a representation.
Mark McIntyre
Heathfield <inv...@invalid.invalid> wrote:
>Well, Mark, I must disagree, and I think you'll find any mathematician worth
>his salt disagreeing with you too. Values are indeed independent of number
>base, whether you see meaning in that statement or not.
Oh sure, but I need hardly remind you we're not in
comp.lang.mathematica or alt.maths. Computer programmes operate on
physically stored data.
Mark McIntyre
Heathfield <inv...@invalid.invalid> wrote:
>Mark McIntyre said:
>
>> Oh, philosophy now?
>
>You can call it that if you want. But I call it mathematics.
And since when was C programming synonymous with mathematics?
>>>The fact that we're not talking about representation here.
>>
>> I'm afraid you are.
>
>No, we really really are not.
And I'm still sorry, but you *are*.
Enough said, its pointless arguing.
Keith Thompson
> On Sun, 8 Jan 2006 06:12:02 +0000 (UTC), in comp.lang.c , Richard
> Heathfield <inv...@invalid.invalid> wrote:
>>Mark McIntyre said:
>>> Oh, philosophy now?
>>You can call it that if you want. But I call it mathematics.
> And since when was C programming synonymous with mathematics?
>>>>The fact that we're not talking about representation here.
>>> I'm afraid you are.
>>No, we really really are not.
> And I'm still sorry, but you *are*.
> Enough said, its pointless arguing.
Ok, I'll chime in and describe how I tend think of it. I'm not sure
whether the standard agrees with me, but I think it's at least a
consistent model of what happens in the abstract machine.
An object has a representation. Objects are made of bits; the
representation is a logical mapping from the value to a sequence of
bits.
A value is an abstract entity that logically doesn't have a
representation. It's probably going to be stored somehow (in a
register, as transient signals on wires, or whatever), but since there
isn't necessarily an object in which the value is stored, it's
meaningless (from the point of view of the abstract machine) to talk
about the representation of a value. A representation is created only
when a value is stored in an object.
For example, given
int x = 10;
int y = 20;
int z = x + y;
the object x will have contain the binary representation ....1010, and
y will contain the binary representation ....10100, but the
representation ...11100 doesn't exist *in the abstract machine* during
the evaluation of x + y; a representation exists only when the value
is stored in an object.
I think the wording of C99 6.2.6 "Representations of types" tends to
support this model, or at least is consistent with it. For example,
it talks about "[v]alues stored in non-bit-field objects"; it doesn't
talk about values not stored in objects.
As far as the standard is concerned, objects have to be composed of
bits, but values not stored in objects, though they may have
representations of some sort in hardware, have no meaningful
representations as far as the standard is concerned. The standard's
requirement for a binary representation for unsigned integer *objects*
doesn't preclude a trinary or decimal representation for unsigned
integer *values* (e.g., intermediate expression results that exist
only in the CPU and are never stored to memory).
I'd be interested in seeing something in the standard that's
inconsistent with this model.
Chuck F.
> Gordon Burditt <gordon...@burditt.org> wrote:
>
... snip ...
>>
>> If I add 5 in base two to 3 in base five, what base is the
>> result in? Why? If your answer is "any base you want it to
>> be in", this really suggests that the base is separate from
>> the value.
>
> Clearly you can only add numbers in the same base - so the
> result is in whichever base you converted one or the other (or
> both) to.
No, the add operation is independent of base, in that the value of
the result is base independent. The base is only a convenience
used in representing values and mechanizing operations such as add.
For example, if you represent five as a five inch stick, and three
as a three inch stick, you can perform the add operation by laying
the two sticks in line together. No base is involved.
Jordan Abel
> Jordan Abel wrote:
>> Gordon Burditt <gordon...@burditt.org> wrote:
>>
> ... snip ...
>>>
>>> If I add 5 in base two to 3 in base five, what base is the
>>> result in? Why? If your answer is "any base you want it to
>>> be in", this really suggests that the base is separate from
>>> the value.
>>
>> Clearly you can only add numbers in the same base - so the
>> result is in whichever base you converted one or the other (or
>> both) to.
>
> No, the add operation is independent of base, in that the value of
> the result is base independent. The base is only a convenience
> used in representing values and mechanizing operations such as add.
>
> For example, if you represent five as a five inch stick, and three
> as a three inch stick, you can perform the add operation by laying
> the two sticks in line together. No base is involved.
Arguably that is in a form of unary, with the digit 1 being an inch
length of stick.
11111
+ 111
=11111111
Jordan Abel
OK, I went too far with this one. Just took a step back and realized how
ridiculous this argument has become. I think we should just agree to
disagree, and forget this whole thing [until the next time it comes up]
sleb...@gmail.com
> Richard Heathfield wrote:
> > Mark McIntyre said:
> >
> >
> >>On 6 Jan 2006 00:21:20 GMT, in comp.lang.c , Jordan Abel
> >><rand...@gmail.com> wrote:
> >>
> >>
> >>>On 2006-01-05, Richard Heathfield <inv...@invalid.invalid> wrote:
> >>>
> >>>>Mark McIntyre said:
> >>>>
> >>>>
> >>>>>Clarification: I assume you mean that shift operators operate on a
> >>>>>binary value,
> >>>>
> >>>>No, they operate on a value. Values don't have number bases. That's
> >>>>merely a representation issue.
> >>>
> >>>The standard mentions "bits" in too many places for me to believe this.
> >>
> >>For some reason RJH's original post didn't make it here. However, my
> >>response would have been " Rubbish", which is rare for a response to
> >>an RJH post.
> >
> >
> > That fact alone should give you pause for thought. What makes you think my
> > statement is rubbish?
> >
Hmm, I posted a reply on this issue but it seems it disappeared. Google
bug?
> Because 'stored' values do have number bases.
'Values' don't have number bases. Representations of the value do.
> You seem to be playing games with language.
No, you seem to be playing games with language confusing the value of a
representation to the representation itself.
> Values in C stored in 'int x' have binary representation in memory.
Store in where? In a CPU register, then yes it most probably is binary.
In the graphics frame buffer it is a bunch of pixels related to the
font which when read by a human represents the value. In a file on disk
then it is probably an ASCII string representing the value.
> Whether 42, 052 or 0x2A the int in memory looks something like 0..00101010
> in binary.
Yes. And it looks something like 42 in decimal and 52 in octal and 2A
in hexadecimal. You used the word 'looks'. That should tell you that
you are only talking about representation, not the value itselt.
If you want to see how that value it looks like in the real world,
under the microscope, instead of binary then it will probably look like
this:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
of course you can't tell what the value is because all D flip-flop
cells look the same under the microscope. But if you were to attach
tiny LEDs to the outputs you'll see something like:
off, off, off .. on, off, on, off, on, off
But then again, that's merely a representation issue of the actual
voltages:
0V, 0V .. 5V, 0V, 5V, 0V, 5V, 0V
which, again, is merely a representation of the number 42
> The value of 'x >> 1' will look like 0..00010101 which seems to be a binary
> operation to me.
Well, we are talking about C here. And C doesn't define it as a binary
operation. C defines it as an arithmetic operation equivalent to
modulo2(x/2).
> What am I missing?
Someone confused the word 'value' with 'representation' earlier in the
thread and is now arguing with Richard about it.
Go back to what you learned in high school. A number 'base' defines a
'number system' used to represent a 'number'. Numbers (hence values) by
themselves don't have bases. But we need a way to write down
(represent) numbers in order to talk about them. Hence we need a number
system to describe numbers. A 'base' simply defines how much larger a
digit to the 'left' is compared to the current digit in that number.
Altering the base of a number system does not alter the 'value' of that
number itself. It merely alters the number system: how the number is
represented (otherwise I will find myself with fewer fingers if I
suddenly decide to count them in hex and more fingers if I decide to
count them in octal).
sleb...@gmail.com
> Richard Heathfield wrote:
> > Mark McIntyre said:
> >
> >
> >>On 6 Jan 2006 00:21:20 GMT, in comp.lang.c , Jordan Abel
> >><rand...@gmail.com> wrote:
> >>
> >>
> >>>On 2006-01-05, Richard Heathfield <inv...@invalid.invalid> wrote:
> >>>
> >>>>Mark McIntyre said:
> >>>>
> >>>>
> >>>>>Clarification: I assume you mean that shift operators operate on a
> >>>>>binary value,
> >>>>
> >>>>No, they operate on a value. Values don't have number bases. That's
> >>>>merely a representation issue.
> >>>
> >>>The standard mentions "bits" in too many places for me to believe this.
> >>
> >>For some reason RJH's original post didn't make it here. However, my
> >>response would have been " Rubbish", which is rare for a response to
> >>an RJH post.
> >
> >
> > That fact alone should give you pause for thought. What makes you think my
> > statement is rubbish?
> >
Hmm, I posted a reply on this issue but it seems it disappeared. Google
bug?
> Because 'stored' values do have number bases.
'Values' don't have number bases. Representations of the value do.
> You seem to be playing games with language.
No, you seem to be playing games with language confusing the value of a
representation to the representation itself.
> Values in C stored in 'int x' have binary representation in memory.
Store in where? In a CPU register, then yes it most probably is binary.
In the graphics frame buffer it is a bunch of pixels related to the
font which when read by a human represents the value. In a file on disk
then it is probably an ASCII string representing the value.
> Whether 42, 052 or 0x2A the int in memory looks something like 0..00101010
> in binary.
Yes. And it looks something like 42 in decimal and 52 in octal and 2A
in hexadecimal. You used the word 'looks'. That should tell you that
you are only talking about representation, not the value itselt.
If you want to see how that value it looks like in the real world,
under the microscope, instead of binary then it will probably look like
this:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
of course you can't tell what the value is because all D flip-flop
cells look the same under the microscope. But if you were to attach
tiny LEDs to the outputs you'll see something like:
off, off, off .. on, off, on, off, on, off
But then again, that's merely a representation issue of the actual
voltages:
0V, 0V .. 5V, 0V, 5V, 0V, 5V, 0V
which, again, is merely a representation of the number 42
> The value of 'x >> 1' will look like 0..00010101 which seems to be a binary
> operation to me.
Well, we are talking about C here. And C doesn't define it as a binary
sleb...@gmail.com
> Richard Heathfield wrote:
> > Mark McIntyre said:
> >
> >
> >>On 6 Jan 2006 00:21:20 GMT, in comp.lang.c , Jordan Abel
> >><rand...@gmail.com> wrote:
> >>
> >>
> >>>On 2006-01-05, Richard Heathfield <inv...@invalid.invalid> wrote:
> >>>
> >>>>Mark McIntyre said:
> >>>>
> >>>>
> >>>>>Clarification: I assume you mean that shift operators operate on a
> >>>>>binary value,
> >>>>
> >>>>No, they operate on a value. Values don't have number bases. That's
> >>>>merely a representation issue.
> >>>
> >>>The standard mentions "bits" in too many places for me to believe this.
> >>
> >>For some reason RJH's original post didn't make it here. However, my
> >>response would have been " Rubbish", which is rare for a response to
> >>an RJH post.
> >
> >
> > That fact alone should give you pause for thought. What makes you think my
> > statement is rubbish?
> >
Hmm, I posted a reply on this issue but it seems it disappeared. Google
bug?
> Because 'stored' values do have number bases.
'Values' don't have number bases. Representations of the value do.
> You seem to be playing games with language.
No, you seem to be playing games with language confusing the value of a
representation to the representation itself.
> Values in C stored in 'int x' have binary representation in memory.
Store in where? In a CPU register, then yes it most probably is binary.
In the graphics frame buffer it is a bunch of pixels related to the
font which when read by a human represents the value. In a file on disk
then it is probably an ASCII string representing the value.
> Whether 42, 052 or 0x2A the int in memory looks something like 0..00101010
> in binary.
Yes. And it looks something like 42 in decimal and 52 in octal and 2A
in hexadecimal. You used the word 'looks'. That should tell you that
you are only talking about representation, not the value itselt.
If you want to see how that value it looks like in the real world,
under the microscope, instead of binary then it will probably look like
this:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
of course you can't tell what the value is because all D flip-flop
cells look the same under the microscope. But if you were to attach
tiny LEDs to the outputs you'll see something like:
off, off, off .. on, off, on, off, on, off
But then again, that's merely a representation issue of the actual
voltages:
0V, 0V .. 5V, 0V, 5V, 0V, 5V, 0V
which, again, is merely a representation of the number 42
> The value of 'x >> 1' will look like 0..00010101 which seems to be a binary
> operation to me.
Well, we are talking about C here. And C doesn't define it as a binary
sleb...@gmail.com
sleb...@gmail.com
sleb...@gmail.com
sleb...@gmail.com
sleb...@gmail.com
sleb...@gmail.com
sleb...@gmail.com
Chuck F.
>
... 10 identical copies within 10 minutes ...
This is happening all over, from people who apparently have at
least some clues. I think usenet has been googled once more. I
don't know if it is their interface, encouraging people to send and
resend by failing to react, or what.
Eric Sosman
>
> Clearly you can only add numbers in the same base - so the result is in
> whichever base you converted one or the other (or both) to.
10 + 010 + 0x10 = XXXIV
--
Eric Sosman
eso...@acm-dot-org.invalid
Flash Gordon
> sleb...@yahoo.com wrote:
>>
> ... 10 identical copies within 10 minutes ...
>
> This is happening all over, from people who apparently have at least
> some clues. I think usenet has been googled once more. I don't know if
> it is their interface, encouraging people to send and resend by failing
> to react, or what.
Someone in another group reported getting an error on trying to send, so
reposted. Both copies came through. I can see why this would cause
people to make multiple posts.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nelu
> Chuck F. wrote:
>> sleb...@yahoo.com wrote:
>>>
>> ... 10 identical copies within 10 minutes ...
>>
> reposted. Both copies came through. I can see why this would cause
> people to make multiple posts.
about a week ago and it came in yesterday.
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Michael Wojcik
In article <11rubhh...@corp.supernews.com>, gordon...@burditt.org (Gordon Burditt) writes:
> [mensa...@aol.com wrote:]
> >
> >You could implement integer representations as strings of characters
> >"0" and "1" and have unlimited precision arithmetic. Am I correct in
> >assuming the standard would allow this as long as evrything behaves as
> >it should?
>
> But it *WON'T* behave as it should. int can't be a variable size.
> Also, there are practical and economic problems with sizeof(int) = infinity.
>
> You could choose a large but finite size (say, 1 gigabit integers),
> and that could be made to work.
Though not with the representation mensanator suggested, as the
standard requires a pure binary representation (C99 6.2.6.2).
--
Michael Wojcik michael...@microfocus.com
Viewers are bugs for famous brands.
-- unknown subtitler, Jackie Chan's _Thunderbolt_
Mark McIntyre
<cbfal...@yahoo.com> wrote:
>
>No, the add operation is independent of base,
For some definitions of "add". I'm not a mathematician, but I know of
at least three definitions of "add" which don't follow that rule, and
one of them is in every day usage by millions of children.
>in that the value of
>the result is base independent.
The *value* of the result is base-independent, but its representation
isn't. For instance, using a common definition of add, 11+11=11=6+1,
provided the bases of each number are appropriately chosen
>The base is only a convenience
>used in representing values and mechanizing operations such as add.
Note that this contradicts your above assertion. :-)
>For example, if you represent five as a five inch stick, and three
>as a three inch stick, you can perform the add operation by laying
>the two sticks in line together. No base is involved.
You're working in base "inch".
Its actually kinda hard to provide any non-thought number experiments
that fail to use some base.
Walter Roberson
Mark McIntyre <markmc...@spamcop.net> wrote:
>The *value* of the result is base-independent, but its representation
>isn't. For instance, using a common definition of add, 11+11=11=6+1,
>provided the bases of each number are appropriately chosen
Hmmm? Which bases would that be?
11+11 is going to be an even number
no matter what base is involved (since it is "two times" whatever "11"
represents in that base).
11 could be either even or odd, depending on whether the base was odd
or even. [*]
6+1 is, though, going to be odd no matter which base > 6 is chosen. [*]
So, 11+11 in one base could potentially be a different base's 11,
but 11+11 in one base cannot be a different base's 6+1. [*]
[*] provided, that is, that:
'+' is integral addition,
'1' represents unity,
'6' represents successor(successor(successor(successor(successor(unity)))))
'=' represents an assertion of equality of integral value
If you've remapped '6' as the glyph of, say, successor(successor(unity))
then we will remap words such as "value" and "representation" and "base"
and -define- you to be wrong ;-)
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Mark McIntyre
robe...@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
>In article <nrn5s1dmpuqqga0fj...@4ax.com>,
>Mark McIntyre <markmc...@spamcop.net> wrote:
>>The *value* of the result is base-independent, but its representation
>>isn't. For instance, using a common definition of add, 11+11=11=6+1,
>>provided the bases of each number are appropriately chosen
>
>Hmmm? Which bases would that be?
two, three, six and ten.
>11+11 is going to be an even number
Ya reckon?
Note that the post was made in response to remarks concerning how
unimportant bases were to teh "add" operation and which had an
example.
Richard Heathfield
> On Sun, 8 Jan 2006 06:10:18 +0000 (UTC), in comp.lang.c , Richard
> Heathfield <inv...@invalid.invalid> wrote:
>
>>Well, Mark, I must disagree, and I think you'll find any mathematician
>>worth his salt disagreeing with you too. Values are indeed independent of
>>number base, whether you see meaning in that statement or not.
>
> Oh sure, but I need hardly remind you we're not in
> comp.lang.mathematica or alt.maths. Computer programmes operate on
> physically stored data.
That's irrelevant, but I'm done arguing. I don't see how I can make myself
any clearer than I already have. If you're not persuaded, c'est la vie.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Dave Thompson
<context (over?)aggressively snipped>
> More precisely (and more correctly :-) ), "endianness" becomes
> an issue whenever someone or something takes a value apart,
> so that there is a "before" and an "after", or a "left" and a
> "right", or some other way of sequencing parts of the value.
>
> For instance, imagine you are moving from one place of living to
> another (e.g., moving apartments). Your car has room for 1/3 of
> your bed, but not the whole thing. You take a saw to the bed and
> cut it into thirds. You then transport each third to your new
> location and reassemble it.
>
I have long objected to (soi-disant) 'normal' people who accuse
programmers (such as myself) of being strange or weird.
I may have to reconsider. :-)
- David.Thompson1 at worldnet.att.net