size and range of int in c
cfaqs c
8), which requires just 1 byte.
Whereas the size of an integer is 4 bytes.... using sizeof(int).
Why then are 3 extra bytes?
Gordon Burditt
>8), which requires just 1 byte.
That is not the correct range of an int in a C implementation.
You might be thinking of unsigned char.
The range of int is, at a minimum, -32767 to 32767, which requires
2 bytes. Some implementations decide to use 4 bytes for an int,
with a correspondingly larger range.
>Whereas the size of an integer is 4 bytes.... using sizeof(int).
sizeof(int) == 4 is not guaranteed, but it may be true in your
implementation.
>Why then are 3 extra bytes?
These bytes are not "extra".
Seebs
> The range of int is (2 to the power of 8 - 1) to (2 to the power of
> 8), which requires just 1 byte.
No it isn't. The range of int is no less than (-32767,32767)...
> Whereas the size of an integer is 4 bytes.... using sizeof(int).
Not necessariily.
> Why then are 3 extra bytes?
There aren't.
If your machine has 4-byte ints, the chances are pretty good that the
range of int on your system is a bit over +/- 2 billion (2^31).
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
cfaqs c
> On 2009-11-16, cfaqs c <faqs...@gmail.com> wrote:
>
> > The range of int is (2 to the power of 8 - 1) to (2 to the power of
> > 8), which requires just 1 byte.
>
> No it isn't. The range of int is no less than (-32767,32767)...
>
> > Whereas the size of an integer is 4 bytes.... using sizeof(int).
>
> Not necessariily.
>
> > Why then are 3 extra bytes?
>
> There aren't.
>
> If your machine has 4-byte ints, the chances are pretty good that the
> range of int on your system is a bit over +/- 2 billion (2^31).
>
> -s
> --
If the size is 4 bytes, how is a small number, say 6, stored in the
machine. 6 in binary is 110. So all the prefix bits in the 4 bytes of
storage is padded with zero is it?
Also, how is a negative number stored? I mean i want to know it's
binary representation
Seebs
> machine. 6 in binary is 110. So all the prefix bits in the 4 bytes of
> storage is padded with zero is it?
It's not padding, it's part of the representation of the number. But yes,
it's all 4 bytes. You can't change the size on the fly. (There are
languages in which you can, but that's sort of different.)
> Also, how is a negative number stored? I mean i want to know it's
> binary representation
It depends on your system. Different systems do it differently. The
most common systems are called "1s complement", "2s complement", and
"sign/magnitude.
The risk you face here is that you seem to be trying much too hard to
"figure out what really happens" -- if you do that really early on, it's
easy to get stuck on expecting every computer you ever encounter to be just
like the one you learned on, and since that's not likely to be the case,
it can screw you over badly.
Start out by being aware that these answers may change sometimes, and it'll
be less likely to bite you badly later.
-s
--
pete
> On 2009-11-16, cfaqs c <faq...@gmail.com> wrote:
>
>>If the size is 4 bytes, how is a small number, say 6, stored in the
>>machine. 6 in binary is 110. So all the prefix bits in the 4 bytes of
>>storage is padded with zero is it?
>
>
> It's not padding, it's part of the representation of the number. But yes,
> it's all 4 bytes. You can't change the size on the fly. (There are
> languages in which you can, but that's sort of different.)
>
>
>>Also, how is a negative number stored? I mean i want to know it's
>>binary representation
>
>
> It depends on your system. Different systems do it differently. The
> most common systems are called "1s complement", "2s complement", and
> "sign/magnitude.
In C99,
those are the only three negative integer representations allowed,
rather than being the "most common".
--
pete
spinoza1111
> On 2009-11-16, cfaqs c <faqs...@gmail.com> wrote:
>
> > The range of int is (2 to the power of 8 - 1) to (2 to the power of
> > 8), which requires just 1 byte.
>
> No it isn't. The range of int is no less than (-32767,32767)...
Yes, which is just as bad as old Visual Basic. In VB 3.0 you had to
code around "integers" restricted to this range and strings whose
length was similarly restricted.
So C is a usable language for safe programming how?
>
> > Whereas the size of an integer is 4 bytes.... using sizeof(int).
>
> Not necessariily.
That constitutes a flaw in C. "C integer" does not, in fact, have a
definite meaning, whereas "integer" has a definition in a modern and
safe language such as C Sharp.
>
> > Why then are 3 extra bytes?
>
> There aren't.
>
> If your machine has 4-byte ints, the chances are pretty good that the
> range of int on your system is a bit over +/- 2 billion (2^31).
If he is using twos complement like a normal person the range can be
known: it is -2^31..2^31-1. This isn't in the Standard. It should be.
>
> -s
> --
spinoza1111
> On 2009-11-16, cfaqs c <faqs...@gmail.com> wrote:
>
> > If the size is 4 bytes, how is a small number, say 6, stored in the
> > machine. 6 in binary is 110. So all the prefix bits in the 4 bytes of
> > storage is padded with zero is it?
>
> It's not padding, it's part of the representation of the number. But yes,
> it's all 4 bytes. You can't change the size on the fly. (There are
> languages in which you can, but that's sort of different.)
>
> > Also, how is a negative number stored? I mean i want to know it's
> > binary representation
>
> It depends on your system. Different systems do it differently. The
> most common systems are called "1s complement", "2s complement", and
> "sign/magnitude.
>
> The risk you face here is that you seem to be trying much too hard to
> "figure out what really happens" -- if you do that really early on, it's
He needs to know constructively (as in Mathematical intuitionism) what
really happens and may be trusted like a normal person to generalize
his experience UNLESS he is socialised to do things by rote &
shibboleth.
> easy to get stuck on expecting every computer you ever encounter to be just
> like the one you learned on, and since that's not likely to be the case,
Actually, programmers who aren't socialized by corporate fear can
intuit that the computer, like a geometrical diagram, has essential
and accidental features, for the same reason intelligent students in
geometry class don't worry about the thickness of the lines they have
drawn using straightedge and compass in geometrical construction.
The problem, of course, is two fold.
First of all, students no longer are taught geometry axiomatically
since their teachers generally are more trained in paperwork and fear
than in axiomatic reasoning. Instead, they are taught to compete for
rewards through rote & shibboleth.
They never get to the point to which they can be led by a competent
teacher at which they see that a sloppy diagram with thick lines is
functionally equivalent to a precise diagram. Quite the opposite, for
teachers who are themselves ignorant of geometry take points off for
sloppiness, neatness being a shibboleth or password just as here,
yapping about main() is a shibboleth.
I knew starting in January 1970, four months prior to the invasion of
Cambodia, that the IBM 1401 was radically different from the IBM 7094.
Stop patronizing the OP.
> it can screw you over badly.
>
> Start out by being aware that these answers may change sometimes, and it'll
> be less likely to bite you badly later.
If you presume to instruct him at all, you yourself need to know some
modal logic, in particular how to distunguish necessity from accident.
You didn't bother to take compsci. I might forgive you for posing as
an authority if you took modal logic, but don't bet on it.
>
> -s
> --
Richard Tobin
cfaqs c <faq...@gmail.com> wrote:
>The range of int is (2 to the power of 8 - 1) to (2 to the power of
>8), which requires just 1 byte.
That would require just one bit :-)
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Aatu Koskensilta
> On Nov 16, 3:40�pm, Seebs <usenet-nos...@seebs.net> wrote:
>
>> The risk you face here is that you seem to be trying much too hard to
>> "figure out what really happens" -- if you do that really early on,
>> it's
>
> He needs to know constructively (as in Mathematical intuitionism) what
> really happens and may be trusted like a normal person to generalize
> his experience UNLESS he is socialised to do things by rote &
> shibboleth.
This allusion to intuitionism is somewhat obscure. Perhaps you can
elaborate on what you have in mind?
--
Aatu Koskensilta (aatu.kos...@uta.fi)
"Wovon man nicht sprechen kann, dar�ber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
spinoza1111
> spinoza1111 <spinoza1...@yahoo.com> writes:
> > On Nov 16, 3:40 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> >> The risk you face here is that you seem to be trying much too hard to
> >> "figure out what really happens" -- if you do that really early on,
> >> it's
>
> > He needs to know constructively (as in Mathematical intuitionism) what
> > really happens and may be trusted like a normal person to generalize
> > his experience UNLESS he is socialised to do things by rote &
> > shibboleth.
>
> This allusion to intuitionism is somewhat obscure. Perhaps you can
> elaborate on what you have in mind?
Intuitionism is the insistence that we do math without the excluded
middle and proceed by constructing proofs from what we know. It
refuses to posit entities which we know "must" exist by way of
excluded middle but which we can't construct.
[Some variants of intuitionism go to unwarranted extremes: I read an
article in the Journal of Symbolic Logic in 1972 which seemed to claim
that "big" numbers such as 100 factorial don't exist in the same way
small numbers exist: my response was to write an assembler program for
the old IBM 1401 to calculate the precise value of 100 factorial. It
was actually easy to do so without simulating extra precision because
the 1401 had a "variable length word".]
Applied to programming, intuitionism would insist that a program must
be constructed bug-free before we can say we know that one exists. And
whether the "program" is constructed using a programming language, or
using mathematical symbols as a written intuitionist proof, it is
going to have essences (meaning) and accidents (notation or an actual
automaton which is either a real computer or an abstract, but fully
described, automaton such as a Turing machine).
What Seebach claims implies that in formal automata, the professor
CANNOT draw a Turing machine on the board and explain that this shows
what computers do, since the professor's constructive proof (proof by
construction) is "only" a picture, and it might confuse the students,
who MIGHT think that on the job they will have to program Turing
machines.
Which is nonsense, and grievously insulting to professors, their
students, and education.
>
> --
> Aatu Koskensilta (aatu.koskensi...@uta.fi)
>
> "Wovon man nicht sprechen kann, darüber muss man schweigen"
spinoza1111
>
> - Show quoted text -
It is however true that Dijkstra, who I consider an intuitionist at
heart, didn't like reasoning with images and claimed (EWD375) to have
discovered a generalization of the Pythagorean theorem to oblique
triangles using symbolic reasoning exclusively. Nonetheless, he was an
intuitionist in the moral sense of refusing to acknowledge that a bug-
free program could exist without some sort of correctness
proof...often one from which he could derive the code of the program.
Eric Sosman
> The range of int is (2 to the power of 8 - 1) to (2 to the power of
> 8), which requires just 1 byte.
The range you mention has just two values (or possibly
128), so one bit (seven bits) is enough.
However (as others have pointed out), the range of `int'
is wider than you suppose. For example, an `int' can store
negative values, which your range{,s} exclude{s,}.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Nick
> On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2009-11-16, cfaqs c <faqs...@gmail.com> wrote:
>>
>> > The range of int is (2 to the power of 8 - 1) to (2 to the power of
>> > 8), which requires just 1 byte.
>>
>> No it isn't. The range of int is no less than (-32767,32767)...
>
> Yes, which is just as bad as old Visual Basic. In VB 3.0 you had to
> code around "integers" restricted to this range and strings whose
> length was similarly restricted.
>
> So C is a usable language for safe programming how?
In the light of that last sentence I think it's time, for the fourth
time of asking, to ask "is English your native language".
Before you return to preaching about the meaning of "clarity" to the
rest of us, I wonder if you could explain the paragraph above.
You seem to be suggesting that any machine with finite length integers
is "bad", Is that it?
--
Online waterways route planner: http://canalplan.org.uk
development version: http://canalplan.eu
John Kelly
<3-no...@temporary-address.org.uk> wrote:
>spinoza1111 <spino...@yahoo.com> writes:
>> So C is a usable language for safe programming how?
>In the light of that last sentence I think it's time, for the fourth
>time of asking, to ask "is English your native language".
I don't know the answer to that question. But it's apparent that his
vocabulary and command of the language are greater than a majority of
native English speakers.
What would you conclude if you knew his native language?
--
Webmail for Dialup Users
http://www.isp2dial.com/freeaccounts.html
Seebs
> This allusion to intuitionism is somewhat obscure. Perhaps you can
> elaborate on what you have in mind?
It seems unlikely. He is not much good at elaborating or explaining.
Spinny's just mad that people who learn about the abstract machine rather
than a real machine seem to be better able to keep code running, and thus
stay employed. The idea that it might be possible to learn from this
experience seems foreign.
-s
--
Seebs
> I don't know the answer to that question. But it's apparent that his
> vocabulary and command of the language are greater than a majority of
> native English speakers.
Strictly speaking, probably true, but the mistakes he makes are absolutely
fascinating.
-s
--
Richard Bos
> spinoza1111 <spino...@yahoo.com> writes:
>
> > On Nov 16, 3:40�pm, Seebs <usenet-nos...@seebs.net> wrote:
> >
> >> The risk you face here is that you seem to be trying much too hard to
> >> "figure out what really happens" -- if you do that really early on,
> >> it's
> >
> > He needs to know constructively (as in Mathematical intuitionism) what
> > really happens and may be trusted like a normal person to generalize
> > his experience UNLESS he is socialised to do things by rote &
> > shibboleth.
>
> This allusion to intuitionism is somewhat obscure. Perhaps you can
> elaborate on what you have in mind?
*Bzzt* Assumption of presence of object without evidence thereof.
Richard
Dik T. Winter
...
> > If your machine has 4-byte ints, the chances are pretty good that the
> > range of int on your system is a bit over +/- 2 billion (2^31).
>
> If he is using twos complement like a normal person the range can be
> known: it is -2^31..2^31-1. This isn't in the Standard. It should be.
So they should have instantly obsoleted the Gould computers? Are you
proposing a situation where a single provider of computers mandates how
everything is done?
Darn, a standards mandated monopoly...
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
spinoza1111
> On 2009-11-16, Aatu Koskensilta <aatu.koskensi...@uta.fi> wrote:
>
> > This allusion to intuitionism is somewhat obscure. Perhaps you can
> > elaborate on what you have in mind?
>
> It seems unlikely. He is not much good at elaborating or explaining.
>
> Spinny's just mad that people who learn about the abstract machine rather
> than a real machine seem to be better able to keep code running, and thus
> stay employed. The idea that it might be possible to learn from this
> experience seems foreign.
Don't confuse me with the anxious fearful you that rages behind the
mask. My point was that there's no such thing as the "abstract
machine" that one doesn't see through a glass darkly. The compsci
student, which you weren't, is equally apt to be deluded by the Turing
Machine as the DeVry student by the IBM PC, since both models have
essential and accidental features. You've adopted anti-PCism as a
fashion statement but don't have the proper background to start viral
attacks on people such as Schildt.
>
> -s
> --
spinoza1111
> In article <2457af6b-c870-4d70-99a8-7e7f4fad4...@x5g2000prf.googlegroups.com>spinoza1111<spinoza1...@yahoo.com> writes:
> ...
> > > If your machine has 4-byte ints, the chances are pretty good that the
> > > range of int on your system is a bit over +/- 2 billion (2^31).
> >
> > If he is using twos complement like a normal person the range can be
> > known: it is -2^31..2^31-1. This isn't in the Standard. It should be.
>
> So they should have instantly obsoleted the Gould computers? Are you
> proposing a situation where a single provider of computers mandates how
> everything is done?
Yes. A tremendous amount of time has been wasted in useless
"competition" that would have been better spent meeting real human
needs such as clean water and education.
Dik T. Winter
...
> He needs to know constructively (as in Mathematical intuitionism) what
> really happens and may be trusted like a normal person to generalize
> his experience UNLESS he is socialised to do things by rote &
> shibboleth.
Interesting that you again bring in something you know nothing about. In
this case intuitionism. Try once to read the works by Brouwer and
acknowledge that you are spouting nonsense. Intuitionism is about a way
to *prove* something, not about generalisations. Most mathematical
generalisations are not valid in intuitionism because there is no
constructive proof.
> Actually, programmers who aren't socialized by corporate fear can
> intuit that the computer, like a geometrical diagram, has essential
> and accidental features, for the same reason intelligent students in
> geometry class don't worry about the thickness of the lines they have
> drawn using straightedge and compass in geometrical construction.
That is indeed the way trisection proofs are worked out. Sheesh, can you
not get anything right?
spinoza1111
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
> >> On 2009-11-16, cfaqs c <faqs...@gmail.com> wrote:
>
> >> > The range of int is (2 to the power of 8 - 1) to (2 to the power of
> >> > 8), which requires just 1 byte.
>
> >> No it isn't. The range of int is no less than (-32767,32767)...
>
> > Yes, which is just as bad as old Visual Basic. In VB 3.0 you had to
> > code around "integers" restricted to this range and strings whose
> > length was similarly restricted.
>
> > So C is a usable language for safe programming how?
>
> In the light of that last sentence I think it's time, for the fourth
> time of asking, to ask "is English your native language".
I'll thank you to stop asking this question. It is stupid, and MOST
offensive to the many non-native ESL students who are more intelligent
and better at English than you.
>
> Before you return to preaching about the meaning of "clarity" to the
> rest of us, I wonder if you could explain the paragraph above.
>
> You seem to be suggesting that any machine with finite length integers
> is "bad", Is that it?
No. But it does require the programmer to be at least aware of
numerical analysis in a way that an architecture with virtual memory
and variable-length integers would not. As it happens, -2^64..2^64-1
is more than enough, but as it happens, intelligent programmers (of
whose number very few are left) use a misnamed "Hungarian" (which was
not invented by Charles Szymonyi) to make numerical precision an
internal property and not an accident of a variable, since it's
important to know the limits up front.
Dik T. Winter
...
> > So they should have instantly obsoleted the Gould computers? =A0Are you
> > proposing a situation where a single provider of computers mandates how
> > everything is done?
>
> Yes. A tremendous amount of time has been wasted in useless
> "competition" that would have been better spent meeting real human
> needs such as clean water and education.
Right. So what company should tell us how clean water and education is
provided? We now know that according to you Intel and Microsoft should
mandate how everything is done.
John Kelly
wrote:
> Intel and Microsoft should mandate how everything is done.
They don't?
Richard Heathfield
spinoza1111 wrote:
> On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
<snip>
>> If your machine has 4-byte ints, the chances are pretty good that
>> the range of int on your system is a bit over +/- 2 billion (2^31).
>
> If he is using twos complement like a normal person the range can be
> known: it is -2^31..2^31-1.
Cray T90s have 48-bit integers. On that platform, if you're using
two's complement like what you call a normal person, the range might
well be -281474976710656 to 281474976710655 (and even if you're not,
it can still be -281474976710655 to 281474976710655).
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Richard
> In <2457af6b-c870-4d70...@x5g2000prf.googlegroups.com>,
> spinoza1111 wrote:
>
>> On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> <snip>
>
>>> If your machine has 4-byte ints, the chances are pretty good that
>>> the range of int on your system is a bit over +/- 2 billion (2^31).
>>
>> If he is using twos complement like a normal person the range can be
>> known: it is -2^31..2^31-1.
>
> Cray T90s have 48-bit integers. On that platform, if you're using
> two's complement like what you call a normal person, the range might
> well be -281474976710656 to 281474976710655 (and even if you're not,
> it can still be -281474976710655 to 281474976710655).
>
> <snip>
That's very nice. But the previous poster clearly said 4 byte ints in the
context of 8 bit bytes. The clue was the 2^31 bit ...
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Nick
> On Nov 17, 4:49 am, Nick <3-nos...@temporary-address.org.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> > On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> >> On 2009-11-16, cfaqs c <faqs...@gmail.com> wrote:
>>
>> >> > The range of int is (2 to the power of 8 - 1) to (2 to the power of
>> >> > 8), which requires just 1 byte.
>>
>> >> No it isn't. The range of int is no less than (-32767,32767)...
>>
>> > Yes, which is just as bad as old Visual Basic. In VB 3.0 you had to
>> > code around "integers" restricted to this range and strings whose
>> > length was similarly restricted.
>>
>> > So C is a usable language for safe programming how?
>>
>> In the light of that last sentence I think it's time, for the fourth
>> time of asking, to ask "is English your native language".
>
> I'll thank you to stop asking this question. It is stupid, and MOST
> offensive to the many non-native ESL students who are more intelligent
> and better at English than you.
When they appear and tell me it's offensive I'll change my ways. I'm
asking you a question. My written English is frequently slipshod, I
agree. But I recognise it, apologise and move on - not bury it in
obfuscation.
Claiming things are offensive to others is a common way to avoid the
debate. Oh, and you're using it - now there's something.
All I'm doing is desperately hunting for an explanation for you using
the language in a way unlike anyone I have ever met or read.
>> Before you return to preaching about the meaning of "clarity" to the
>> rest of us, I wonder if you could explain the paragraph above.
But you didn't. Surprise!
>> You seem to be suggesting that any machine with finite length integers
>> is "bad", Is that it?
>
> No. But it does require the programmer to be at least aware of
> numerical analysis in a way that an architecture with virtual memory
> and variable-length integers would not. As it happens, -2^64..2^64-1
> is more than enough,
YAWGAICM5P
> but as it happens, intelligent programmers (of
> whose number very few are left)
and they are dead.
>use a misnamed "Hungarian" (which was
> not invented by Charles Szymonyi) to make numerical precision an
> internal property and not an accident of a variable, since it's
> important to know the limits up front.
So using a variable name convention affects the numerical precision of
the compiler does it? Or if not, when the compiler changes you must
change your variable names? You surely can't mean that. So let's
return to my question. As you are not writing comprehensible English,
what's the reason?
>> --
>> Online waterways route planner:http://canalplan.org.uk
>> development version:http://canalplan.eu
I've also asked you to snip sigs innumerable times (well, not strictly
innumerable, but enough for my internal precision to overflow. As you
don't answer questions, and can't follow simple conventions, I'm afraid
it's "plonk" time. I don't have the patience - or time - of some of the
regulars I'm afraid.
Richard Heathfield
<snip>
> So using a variable name convention affects the numerical precision
> of the compiler does it? Or if not, when the compiler changes you
> must change your variable names? You surely can't mean that. So
> let's return to my question. As you are not writing comprehensible
> English, what's the reason?
I can answer that, using what passes for his reasoning:
1) all clear statements are true
2) therefore all unclear statements are false
3) everything he says is unclear
4) therefore everything he says is false
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Irony is only mildly dangerous on this occasion
Ian Collins
> On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2009-11-16, cfaqs c <faqs...@gmail.com> wrote:
>>
>>> The range of int is (2 to the power of 8 - 1) to (2 to the power of
>>> 8), which requires just 1 byte.
>> No it isn't. The range of int is no less than (-32767,32767)...
>
> Yes, which is just as bad as old Visual Basic. In VB 3.0 you had to
> code around "integers" restricted to this range and strings whose
> length was similarly restricted.
It isn't a restriction, it is a minimum.
> So C is a usable language for safe programming how?
>>> Whereas the size of an integer is 4 bytes.... using sizeof(int).
>> Not necessariily.
>
> That constitutes a flaw in C. "C integer" does not, in fact, have a
> definite meaning, whereas "integer" has a definition in a modern and
> safe language such as C Sharp.
The joys of a single platform language.
--
Ian Collins
Keith Thompson
> In <2457af6b-c870-4d70...@x5g2000prf.googlegroups.com>,
> spinoza1111 wrote:
>> On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> <snip>
>
>>> If your machine has 4-byte ints, the chances are pretty good that
>>> the range of int on your system is a bit over +/- 2 billion (2^31).
>>
>> If he is using twos complement like a normal person the range can be
>> known: it is -2^31..2^31-1.
>
> Cray T90s have 48-bit integers. On that platform, if you're using
> two's complement like what you call a normal person, the range might
> well be -281474976710656 to 281474976710655 (and even if you're not,
> it can still be -281474976710655 to 281474976710655).
I happen to know that on the Cray T90 I used, sizeof(int)==8 and
CHAR_BIT==8; in fact, short, int, long, and long long were all 64
bits.
There may well have been padding bits, though; I didn't think to check
that before the system was decommissioned.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
<snip>
>> Cray T90s have 48-bit integers. On that platform, if you're using
>> two's complement like what you call a normal person, the range
>> might well be -281474976710656 to 281474976710655 (and even if
>> you're not, it can still be -281474976710655 to 281474976710655).
>
> I happen to know that on the Cray T90 I used, sizeof(int)==8 and
> CHAR_BIT==8; in fact, short, int, long, and long long were all 64
> bits.
Darn. I should have made a note of my source. Anyway, I just found a
better source (cray.com!), which confirms your correction. Thank you.
> There may well have been padding bits, though; I didn't think to
> check that before the system was decommissioned.
The point remains clear - that 2^31 - 1 is not as fixed a limit as the
OP seems to think.
Dik T. Winter
> Richard Heathfield <r...@see.sig.invalid> writes:
...
> > Cray T90s have 48-bit integers. On that platform, if you're using
> > two's complement like what you call a normal person, the range might
> > well be -281474976710656 to 281474976710655 (and even if you're not,
> > it can still be -281474976710655 to 281474976710655).
>
> I happen to know that on the Cray T90 I used, sizeof(int)==8 and
> CHAR_BIT==8; in fact, short, int, long, and long long were all 64
> bits.
>
> There may well have been padding bits, though; I didn't think to check
> that before the system was decommissioned.
Not really padding bits, but when you got out of the range of 48 bits
some operations would not work as expected (multiplication).
Keith Thompson
> In article <lnpr7h1...@nuthaus.mib.org> Keith Thompson
> <ks...@mib.org> writes:
> > Richard Heathfield <r...@see.sig.invalid> writes:
> ...
> > > Cray T90s have 48-bit integers. On that platform, if you're using
> > > two's complement like what you call a normal person, the range might
> > > well be -281474976710656 to 281474976710655 (and even if you're not,
> > > it can still be -281474976710655 to 281474976710655).
> >
> > I happen to know that on the Cray T90 I used, sizeof(int)==8 and
> > CHAR_BIT==8; in fact, short, int, long, and long long were all 64
> > bits.
> >
> > There may well have been padding bits, though; I didn't think to check
> > that before the system was decommissioned.
>
> Not really padding bits, but when you got out of the range of 48 bits
> some operations would not work as expected (multiplication).
I think those would really be padding bits, then. If INT_MIN and
INT_MAX are, say, -2**47 and +2**47-1, and int occupies 64 bits,
then there are 16 padding bits. Certain values of those padding
bits can create trap representations. (A trap representation
needn't cause a "trap"; the fact that the behavior is undefined
covers multiplication not working as expected.)
I vaguely recall that, on some Cray systems, int and long were the
same size, but long used more of the bits (at the cost of slower code
for some operations).
Dik T. Winter
...
> I vaguely recall that, on some Cray systems, int and long were the
> same size, but long used more of the bits (at the cost of slower code
> for some operations).
int used 48 bits and long used all 64 but especially the multiplication was
slow (and probably also division).
Richard Tobin
>In article
>So they should have instantly obsoleted the Gould computers?
An unfortunate example. The non-existence of Gould computers would
have saved us years of wasted porting effort and user frustration.
Not because of the C standard though.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Charlton Wilbur
RH> I can answer that, using what passes for his reasoning:
RH> 1) all clear statements are true 2) therefore all unclear
RH> statements are false 3) everything he says is unclear 4)
RH> therefore everything he says is false
Well, that's *quite* clear, then, isn't it?
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Richard Heathfield
>>>>>> "RH" == Richard Heathfield <r...@see.sig.invalid> writes:
>
> RH> I can answer that, using what passes for his reasoning:
>
> RH> 1) all clear statements are true 2) therefore all unclear
> RH> statements are false 3) everything he says is unclear 4)
> RH> therefore everything he says is false
>
> Well, that's *quite* clear, then, isn't it?
...and therefore, apparently, it must be true.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
spinoza1111
> In article <9665287a-e7b4-422f-b3eb-b3ccc16cf...@o9g2000prg.googlegroups.com>spinoza1111<spinoza1...@yahoo.com> writes:
> ...
> > He needs to know constructively (as in Mathematical intuitionism) what
> > really happens and may be trusted like a normal person to generalize
> > his experience UNLESS he is socialised to do things by rote &
> > shibboleth.
>
> Interesting that you again bring in something you know nothing about. In
> this case intuitionism. Try once to read the works by Brouwer and
Well, I first encountered it in Evert W Beth and Stefan Korner. Your
foolish attack here is probably Nordic-nationalistic in the irritating
way of the Nordic male who like Heidegger prefers the bruder
schweigen, and like Adorno's attacker on a tram in 1920, hates young
whippersnappers who use High German, he being Lower than whale
scheissen himself.
Some sort of creepy lower middle class Dutch nationalism seems to be
afoot, since you seem offended that Brouwer's ideas are actually
understood in a different language.
From THE OXFORD HANDBOOK OF PHILOSOPHY OF MATHEMATICS AND LOGIC
(Shapiro, OUP 2005):
"...traditional *intuitionists*, such as L. E. J. Brouwer and Arend
Heyting held that mathematics has a subject matter [as opposed to
formalists]: mathematical objects, such as numbers, do exist. However,
Brouwer and Heyting insisted that these objects are mind-dependent.
Natural numbers and real numbers are mental constructions or are the
result of mental constructions. In mathematics, to exist is to be
constructed. Thus, Brouwer and Heyting are anti-realists in ontology,
denying the *objective* existence of mathematical objects. Some of
their writing seems to imply that each person constructs his own
mathematical realm. Communication between mathematicians consists in
exchanging notes about their own constructive activities. This would
make mathematics subjective. It is more common, however, for these
intuitionists, especially Brouwer, to hold that mathematics concerns
the *forms* of mental construction as such. This follows a Kantian
theme, reviving the thesis that mathematics is synthetic apriori."
"This perspective has consequences concerning the proper practice of
mathematics. Most notably, the intuitionist demurs from the law of the
excluded middle-(Av~A)-and other inferences based on it. According to
Brouwer and Heyting, these methodological principles are symptomatic
of faith in the transcendental existence of mathematical objects or
the transcendental truth of mathematical statements. For the
intuitionist, every mathematical assertion must correspond to a
construction."
This is an excellent definition of intuitionism, and there's a clear,
if to my knowledge undrawn, relationship between this and Dijkstra's
mode of thinking. In intuitionism, the only "reality" is mathematical
communication. In Dijkstra's view of programming, a program considered
as a text is a communication of an intent.
The rejection of the excluded middle is echoed in Dijkstra's belief
that testing can NEVER prove bug absence.
The deepest connection is with Kant (have you read Kant, dear Dik?)
Kant believed that noumenal reality (reality in itself) is unknowable
but can be approached as a limit through phenomena. Mathematics is a
form of intution in Kant in which "the medium is the message":
Euclid's theorems are at one and the same time forced upon us by the
way we see the world, and an ultimate reality: likewise, what makes
intuitionism different from formalism is that while the latter makes
mathematical realities into mere constructed games, intuitionism like
Kant says the the forms of perception HAVE NO ALTERNATIVE FORMS and
thus they are the ultimate reality. Other beings might "see" a world
with a different mathematical structure but this is less than an
unknowable noumenon, it's an only possible noumenon.
In Kant, we not only see space,
I SEE SPACE AND IT LOOKS LIKE NOTHING AND I WANT IT AROUND ME - Jenny
Holzer
we see objects arranged in it that never violate the laws of geometry
as we know it. Alternative beings perhaps dwelling amongst us but in a
different dimension (think Twilight Zone, dear Dik) might see
something other than "space", and/or the objects in their z-space
might arrange themselves according to a z-geometry, but we can only
speak of this, we cannot "visualize" it.
Which means that what the intuitionist discovers in proof by
construction are not assertions about the tools used, they are
"synthetic apriori" (informative but proved logically) assertions
about the way the world is, because in intuitionism, the world cannot
be considered apart from the way we apprehend it.
Which is probably why elegance mattered to Dijkstra: a program is just
one way of apprehending a truth in applied mathematics but it's also
part of that truth.
> acknowledge that you are spouting nonsense. Intuitionism is about a way
> to *prove* something, not about generalisations. Most mathematical
"Intuitionism is about a way to *prove* something" is incredibly poor
writing even if transliterated from Dutch:
* Why is it "about a way" and not "a way"?
* And are you seriously claiming that intuitionists wanted to prove
"something", at least one thing, or are you using the English idiom
that means a person with an inferiority complex, such as some Dutch
guy making a fool of himself, is out to "prove something"? Actually,
their programme was to prove "everything true" without using the
excluded middle.
> generalisations are not valid in intuitionism because there is no
> constructive proof.
>
> > Actually, programmers who aren't socialized by corporate fear can
> > intuit that the computer, like a geometrical diagram, has essential
> > and accidental features, for the same reason intelligent students in
> > geometry class don't worry about the thickness of the lines they have
> > drawn using straightedge and compass in geometrical construction.
>
> That is indeed the way trisection proofs are worked out. Sheesh, can you
> not get anything right?
I don't know, but it sounds to me that you were not educated in
mathematics at all. Geometrical constructions use an unmarked
straightedge and a compass (a circle drawing tool, not a direction
finder): http://mathworld.wolfram.com/GeometricConstruction.html.
If you insist on interrupting these conversations with news about
outdated computers that you happened to have worked on and complete
disinformation posted in order to participate in campaigns of personal
destruction...you're going to look the fool.
spinoza1111
> spinoza1111wrote:
Damn right. Calvin "Forth" Moore successfully forced all his clients
to let him use Forth, a precursor of Java and .Net, and retarget
Forth. This is said to be evil and proprietary, but it all depends
on...who is to be master, that's all.
>
> --
> Ian Collins
spinoza1111
> In article <lnlji5172p....@nuthaus.mib.org> Keith Thompson <ks...@mib.org> writes:
>
> ...
> > I vaguely recall that, on some Cray systems, int and long were the
> > same size, but long used more of the bits (at the cost of slower code
> > for some operations).
>
> int used 48 bits and long used all 64 but especially the multiplication was
> slow (and probably also division).
Wow, it's Computer Museum Day! Let's all mosey on down to the old
Silicon Graphics HQ building and look at old soopercomputers! Cool
bench for the lads on that one!
Seriously, the errors of the past should not force us to spout utter
nonsense.
spinoza1111
> >>>>> "RH" == Richard Heathfield <r...@see.sig.invalid> writes:
>
> RH> I can answer that, using what passes for his reasoning:
>
> RH> 1) all clear statements are true 2) therefore all unclear
> RH> statements are false 3) everything he says is unclear 4)
> RH> therefore everything he says is false
>
> Well, that's *quite* clear, then, isn't it?
Equivocation on two different senses of clear, old boy.
I'm "unclear" as in "unclear to you", boo most assuredly hoo
But this is 'cause you don' geddit
Whereas Peter Seebach like a perfect dear said Herbie was clear
And not to him but to all the world:
This is the meaning of "he's a clear writer".
Little Petey Seebach didn't say,
Herbie is clear to me but not to thee,
Petey used "clear" in an absolute sense,
Clear in Hotspur's sense, which takes the survey of all the world
Before being hurled
As was Percy the hot into the jaws of all-devouring death.
But if Herbie was clear in the absolute sense
He helped us all to understanding,
And what is understanding? It is knowledge, not a sandwidge,
And knowledge is (it's a relief) justified true belief.
What little Petey wanted to say was unsayable so he shouldn't have
tried
He wanted to say that a teacher was teaching clearly:
He sat in the class, rolled his eyes, scratched his penis and sighed,
Filled with resentment and nameless hostility
That here was someone expressing things differently.
>
> Charlton
>
> --
> Charlton Wilbur
> cwil...@chromatico.net
spinoza1111
> In <lnpr7h1sfv....@nuthaus.mib.org>, Keith Thompson wrote:
>
> > Richard Heathfield <r...@see.sig.invalid> writes:
>
> <snip>
>
> >> Cray T90s have 48-bit integers. On that platform, if you're using
> >> two's complement like what you call a normal person, the range
> >> might well be -281474976710656 to 281474976710655 (and even if
> >> you're not, it can still be -281474976710655 to 281474976710655).
>
> > I happen to know that on the Cray T90 I used, sizeof(int)==8 and
> > CHAR_BIT==8; in fact, short, int, long, and long long were all 64
> > bits.
>
> Darn. I should have made a note of my source. Anyway, I just found a
> better source (cray.com!), which confirms your correction. Thank you.
>
> > There may well have been padding bits, though; I didn't think to
> > check that before the system was decommissioned.
>
> The point remains clear - that 2^31 - 1 is not as fixed a limit as the
> OP seems to think.
No-one said it is, in all cases, the limit. For one thing, I said that
the TWO bounds are -2^31 and 2^31, and I said that knowing that this
is true for many platforms is something important, that should not be
concealed by some fat geek just because said Fat Bastard once had a
summer job programming a Cray.
spinoza1111
> Richard Heathfield <r...@see.sig.invalid> writes:
> >spinoza1111wrote:
>
> >> On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> > <snip>
>
> >>> If your machine has 4-byte ints, the chances are pretty good that
> >>> the range of int on your system is a bit over +/- 2 billion (2^31).
>
> >> If he is using twos complement like a normal person the range can be
> >> known: it is -2^31..2^31-1.
>
> > Cray T90s have 48-bit integers. On that platform, if you're using
> > two's complement like what you call a normal person, the range might
> > well be -281474976710656 to 281474976710655 (and even if you're not,
> > it can still be -281474976710655 to 281474976710655).
>
> > <snip>
>
> That's very nice. But the previous poster clearly said 4 byte ints in the
> context of 8 bit bytes. The clue was the 2^31 bit ...
Aren't these guys a hoot? One says "four adjacent 8 bit bytes can be
used to represent -2^31..2^31-1 in twos complement" and they reply:
"Duh, I had a summer job in 1968 programming an Electrobrite E-9821
Hybrid Digital Analogue computer with ferrite core memory and it had a
word length of 18 bits, so you're wrong!"
"Duh, yeah boss, you did, and you soitainly was a great coder. Wasn't
the delay line on that machine great for storing beer?"
"D'oh, are you out of your mind? That's not a C rule! This is supposed
to be a C class! Mom!"
HERE'S A DOLLAR FOR YOU: KINDLY GET A CLUE
An Ode to CLC, by Edward G. Nilges 18 Nov 2009. Moral rights have been
asserted by the author, so shove it.
I hate to be the first to tell you,
But this is your ass, and that is your elbow.
I thought you might like to know
That all other things being equal
And all other things, the same,
Ceteris paribus, so Christ save us,
If you take careful aim,
You might be able to pull your head out of your ass and also dislodge
your elbow
From where you tried so fruitlessly
To make it go.
You know,
It's not as if it's hard, nor is it "rocket science", and we don't
need Werner von Braun, that German guy who designed all those V-2
rockets that the Reich fired with deadly effect at London at the end
of World War II, to sort you out or set you straight,
And it's not even something you ate,
It's just basic reading comprehension coupled with the milk of human
kindness, collegiality, solidarity, decency and respect,
That's all we expect.
So the next time you have a mind
My valuable time to waste
Don't be quite so in haste
To tell me to read books I have read
Or not say things I've said.
As a wise lady once was heard to have averred,
Don't pee on my leg and tell me its raining
And don't shit in my sushi and tell me it's training.
>
> --
> "Avoid hyperbole at all costs, its the most destructive argument on
> the planet" - Mark McIntyre in comp.lang.c- Hide quoted text -
>
> - Show quoted text -
Walter Banks
spinoza1111 wrote:
> > The joys of a single platform language.
>
> Damn right. Calvin "Forth" Moore successfully forced all his clients
> to let him use Forth, a precursor of Java and .Net, and retarget
> Forth.
That is a stretch.
w..
Coos Haak
(as this geek is in my kill file, I'm writing indirectly, sorry
Walter)
The inventor Forth is called Charles or Chuck, not Calvin.
Forth is definitely no precursor of Java nor .Net.
This shows this spinach[*] guy's ignorance of programming languages,
again, as usual!
[*] There is a link in Dutch with Spinoza and spinach.
spinoza1111 never ate spinach, so his name is an insult to our great
philosopher.
--
Coos
spinoza1111
> Op Wed, 18 Nov 2009 14:13:17 -0500 schreef Walter Banks:
>
> >spinoza1111wrote:
>
> >>> The joys of a single platform language.
>
> >> Damn right. Calvin "Forth" Moore successfully forced all his clients
> >> to let him use Forth, a precursor of Java and .Net, and retarget
> >> Forth.
>
> > That is a stretch.
>
> > w..
>
> (as this geek is in my kill file, I'm writing indirectly, sorry
> Walter)
> The inventor Forth is called Charles or Chuck, not Calvin.
Correction accepted, of mere typo. The small-minded and the creep may
take note.
> Forth is definitely no precursor of Java nor .Net.
But lack of imagination is no argument. To a mere technician there is
no commonality, but in fact there is. In Forth, Java and Forth there
is indeed a commonality. It's trading off a childish interest in speed
for an adult interest in correctness, safety and the public interest
as opposed to fraud and greed.
> This shows this spinach[*] guy's ignorance of programming languages,
> again, as usual!
>
> [*] There is a link in Dutch with Spinoza and spinach.spinoza1111never ate spinach, so his name is an insult to our great
> philosopher.
> --
> Coos
Dik T. Winter
entry:
In article <08f86690-a777-4dc0...@v15g2000prn.googlegroups.com> spinoza1111 <spino...@yahoo.com> writes:
...
> The rejection of the excluded middle is echoed in Dijkstra's belief
> that testing can NEVER prove bug absence.
Wrong. The belief that testing can NEVER prove bug absence comes from the
mathematical belief that testing can not prove a theorem over an infinite
set of objects. If has absolutely nothing to do with the rejection of the
excluded middle.
Phil Carmody
>> >
>> >> The risk you face here is that you seem to be trying much too hard to
>> >> "figure out what really happens" -- if you do that really early on,
>> >> it's
>> >
>> > He needs to know constructively (as in Mathematical intuitionism) what
>> > really happens and may be trusted like a normal person to generalize
>> > his experience UNLESS he is socialised to do things by rote &
>> > shibboleth.
>>
>> elaborate on what you have in mind?
I was just about to slap Aatu for encouraging him...
> *Bzzt* Assumption of presence of object without evidence thereof.
but the cloud had a silver lining. :-)
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
spinoza1111
> I omit the largely off-topic parts, leaving only one slightly on-topic
> entry:
>
> ...
> > The rejection of the excluded middle is echoed in Dijkstra's belief
> > that testing can NEVER prove bug absence.
>
> Wrong. The belief that testing can NEVER prove bug absence comes from the
> mathematical belief that testing can not prove a theorem over an infinite
> set of objects. If has absolutely nothing to do with the rejection of the
> excluded middle.
Poetically, it does, and poetically it matters, because people who do
not realize that they think in metaphors make the worst kind of
mistakes. Furthermore, Dijkstra's assertion DOES have to do with
excluded middle, since a tested program that seems to work either
works or does not work according to the non-intuitionist, but is in a
third state according to the intuitionist.
The non-intuitionist reasons
(w|~w) & ~~w, therefore w
where ~~w means it hasn't failed. Sure, he isn't *really* using EM
correctly but that's the problem with non-intuitionism. The non-
intuitionist believes that truth can be known independent of proof,
and then proved.
Your lack of imagination is no argument.
Furthermore, you make as a result a mathematical error. Insofar as
intuitionism is a collection of axioms, lemmas, and theorems, each one
of them has quite a lot to do with each other.
"Imagination is more important than knowledge" - Einstein
dk
> >The range of int is (2 to the power of 8 - 1) to (2 to the power of
> >8), which requires just 1 byte.
>
> You might be thinking of unsigned char.
>
> The range of int is, at a minimum, -32767 to 32767, which requires
> 2 bytes. Some implementations decide to use 4 bytes for an int,
> with a correspondingly larger range.
>
> >Whereas the size of an integer is 4 bytes.... using sizeof(int).
>
> implementation.
>
> >Why then are 3 extra bytes?
>
> These bytes are not "extra".
Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.
pete
> Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#1]
-- minimum value for an object of type int
INT_MIN -32767
-- maximum value for an object of type int
INT_MAX +32767
--
pete
Noob
> Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.
No.
The range of an int variable is INT_MIN to INT_MAX inclusive.
The values given below shall be replaced by constant expressions
suitable for use in #if preprocessing directives. Their
implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign.
* minimum value for an object of type int
INT_MIN -32767
* maximum value for an object of type int
INT_MAX +32767
Richard Tobin
dk <mcdivy...@gmail.com> wrote:
>> The range of int is, at a minimum, -32767 to 32767
>Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.
A 16-bit int will typically have that range, because virtually all
systems now use twos complement, but the statement was about the
minimum range required by the C standard.
Seebs
> On Nov 16, 12:26 pm, gordonb.e8...@burditt.org (Gordon Burditt) wrote:
>> The range of int is, at a minimum, -32767 to 32767, which requires
>> 2 bytes. Some implementations decide to use 4 bytes for an int,
>> with a correspondingly larger range.
> Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.
Note that he said "at a minimum".
There exist platforms where it's the latter, not the former. And platforms
where it's roughly +/- 2^31, as well as platforms where it's +/- 2^63 or so.
If they're two's complement, the range is -2^(N-1) to 2^(N-1) - 1. If they're
not, it might be symmetrical, with two representations for zero.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Flash Gordon
> On 2009-11-20, dk <mcdivy...@gmail.com> wrote:
>> On Nov 16, 12:26 pm, gordonb.e8...@burditt.org (Gordon Burditt) wrote:
>>> The range of int is, at a minimum, -32767 to 32767, which requires
>>> 2 bytes. Some implementations decide to use 4 bytes for an int,
>>> with a correspondingly larger range.
>
>> Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.
>
> Note that he said "at a minimum".
>
> There exist platforms where it's the latter, not the former. And platforms
> where it's roughly +/- 2^31, as well as platforms where it's +/- 2^63 or so.
>
> If they're two's complement, the range is -2^(N-1) to 2^(N-1) - 1. If they're
> not, it might be symmetrical, with two representations for zero.
If it's two's complement, the standard allows it to be a symetric range
with one trap representation. I'm sure there must have been at least one
implementation where this was true, and I can see why it could be useful
on a DSP (there can be issues caused by an asymmetric range for some
types of signal processing, and hardware limiting arithmetic to the
symmetric range could be very useful). I don't know if there are still
any systems around with two's complement and a symmetric range.
--
Flash Gordon
Keith Thompson
[...]
> If it's two's complement, the standard allows it to be a symetric
> range with one trap representation. I'm sure there must have been at
> least one implementation where this was true, and I can see why it
> could be useful on a DSP (there can be issues caused by an asymmetric
> range for some types of signal processing, and hardware limiting
> arithmetic to the symmetric range could be very useful). I don't know
> if there are still any systems around with two's complement and a
> symmetric range.
Creating such an implementation would be as simple as modifying the
definition of INT_MAX in <limits.h>. Trap representations don't
actually have to trap.
Dik T. Winter
> On Nov 19, 11:37 pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
> > Wrong. The belief that testing can NEVER prove bug absence comes from the
> > mathematical belief that testing can not prove a theorem over an infinite
> > set of objects. If has absolutely nothing to do with the rejection of the
> > excluded middle.
>
> Poetically, it does, and poetically it matters, because people who do
> not realize that they think in metaphors make the worst kind of
> mistakes. Furthermore, Dijkstra's assertion DOES have to do with
> excluded middle, since a tested program that seems to work either
> works or does not work according to the non-intuitionist, but is in a
> third state according to the intuitionist.
I do not think mathematicians, whether they are intuitionists or not, consider
"working programs".
> The non-intuitionist reasons
>
> (w|~w) & ~~w, therefore w
>
> where ~~w means it hasn't failed.
In *mathematics* a non-intuitionist reasons (where P is a proposition):
~~P -> P
for an intuitionist there is no such rule.
But also in mathematics there is a rule that if the set of cases is infinite
that there is *no* way to prove a proposition about it by testing individual
case only, and *that* is similar to the testing of programs.
> The non-
> intuitionist believes that truth can be known independent of proof,
> and then proved.
You are wrong.
> Furthermore, you make as a result a mathematical error. Insofar as
> intuitionism is a collection of axioms, lemmas, and theorems, each one
> of them has quite a lot to do with each other.
Right. So what? In intuitionism ~~P -> P is not an inference rule, but
it is in non-intuitionism.
Richard Heathfield
<snip>
> But also in mathematics there is a rule that if the set of cases is
> infinite that there is *no* way to prove a proposition about it by
> testing individual case only, and *that* is similar to the testing
> of programs.
On the other hand, there may well be a way to /disprove/ it. If the
proposition P is that X is true for all N, then a single instance of
N for which X is false is sufficient to overturn P.
But you wouldn't necessarily want to stand around watching the
computer find that particular N. Unless, of course, your name is
Noam.
<snip>
Nick Keighley
> In article <08f86690-a777-4dc0-8f63-11e22e74a...@v15g2000prn.googlegroups.com> spinoza1111
> <spinoza1...@yahoo.com> writes:
> > The rejection of the excluded middle is echoed in Dijkstra's belief
> > that testing can NEVER prove bug absence.
>
> Wrong. The belief that testing can NEVER prove bug absence comes from the
> mathematical belief that testing can not prove a theorem over an infinite
> set of objects. If has absolutely nothing to do with the rejection of the
> excluded middle.
I know this Dijkstra quote get trotted out a lot, but is it actually
true? Computers don't actually deal in infinite sets. So in principle
I can enumerate all cases. This may be practically impossible for
large or complex programs but it can be done in some cases. Therefore
the "never" above (which isn't in Dijkstra's quote) is not true.
--
In this respect a program is like a poem:
you cannot write a poem without writing it.
-- Edsger W Dijkstra
Richard
Your .sig is quoted wrong.
But you are right. That tired old chestnut is up there with never
optimising until its finished and how debugging is harder than getting
it right the first time (hint : debugging is part of getting it right
the first time ...).
Nick Keighley
> On Nov 17, 4:49 am, Nick <3-nos...@temporary-address.org.uk> wrote:
> > spinoza1111<spinoza1...@yahoo.com> writes:
> > > On Nov 16, 3:22 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > >> [...] The range of int is no less than (-32767,32767)...
>
> > > Yes, which is just as bad as old Visual Basic. In VB 3.0 you had to
> > > code around "integers" restricted to this range and strings whose
> > > length was similarly restricted.
>
> > > So C is a usable language for safe programming how?
you use int if you know the range is "small" and long if it's large
and long long if it's very large.
> > In the light of that last sentence I think it's time, for the fourth
> > time of asking, to ask "is English your native language".
I think it is, but I think he's largely self taught. I make a lot of
pronounciation errors because my reading vocabulary is larger than my
spoken vocabulary (and my deduce-pronounciation-from-spelling
algorithm is broken).
> I'll thank you to stop asking this question. It is stupid, and MOST
> offensive to the many non-native ESL students who are more intelligent
> and better at English than you.
you can often distinguish a native from a non-native writer though.
> > Before you return to preaching about the meaning of "clarity" to the
> > rest of us, I wonder if you could explain the paragraph above.
>
> > You seem to be suggesting that any machine with finite length integers
> > is "bad", Is that it?
>
> No. But it does require the programmer to be at least aware of
> numerical analysis in a way that an architecture with virtual memory
> and variable-length integers would not. As it happens, -2^64..2^64-1
> is more than enough,
for what? It's well short of the number of protons in the universe or
even the number of protons in the earth.
> but as it happens, intelligent programmers (of
> whose number very few are left) use a misnamed "Hungarian" (which was
> not invented by Charles Szymonyi)
thats Charles Simonyi
So, who did invent "hungarian notation"?
> to make numerical precision an
> internal property and not an accident of a variable, since it's
> important to know the limits up front.
what?
Nick Keighley
> In <87tywtvd11....@temporary-address.org.uk>, Nick wrote:
>
> <snip>
>
> > So using a variable name convention affects the numerical precision
> > of the compiler does it? Or if not, when the compiler changes you
> > must change your variable names? You surely can't mean that. So
> > let's return to my question. As you are not writing comprehensible
> > English, what's the reason?
>
> I can answer that, using what passes for his reasoning:
>
> 3) everything he says is unclear
isn't there therefore a paradox?
Nick Keighley
> Yes. A tremendous amount of time has been wasted in useless
> "competition" that would have been better spent meeting real human
> needs such as clean water and education.
perhaps some sort of central bureau could be used to coordinate
everything. Has anyone ever tried this?
Nick Keighley
> On Tue, 17 Nov 2009 03:39:55 GMT, "Dik T. Winter" <Dik.Win...@cwi.nl>
> > Intel and Microsoft should mandate how everything is done.
>
> They don't?
I for one thank Bill for my clean water
Seebs
> I think it is, but I think he's largely self taught. I make a lot of
> pronounciation errors because my reading vocabulary is larger than my
> spoken vocabulary (and my deduce-pronounciation-from-spelling
> algorithm is broken).
As long as we're talking about English, the only way you can be sure an
algorithm for that is broken would be if it DOESN'T produce incorrect
results.
Nobody
>> > The rejection of the excluded middle is echoed in Dijkstra's belief
>> > that testing can NEVER prove bug absence.
>>
>> Wrong. The belief that testing can NEVER prove bug absence comes from the
>> mathematical belief that testing can not prove a theorem over an infinite
>> set of objects. If has absolutely nothing to do with the rejection of the
>> excluded middle.
>
> I know this Dijkstra quote get trotted out a lot, but is it actually
> true? Computers don't actually deal in infinite sets. So in principle
> I can enumerate all cases. This may be practically impossible for
> large or complex programs but it can be done in some cases. Therefore
> the "never" above (which isn't in Dijkstra's quote) is not true.
You would still have to prove that you had enumerated over the entire set
of "inputs".
E.g. for a Unix program, there's no way that you could enumerate over the
entire set of possible combinations for argv[] and environ[] and kernel
state and hardware state and ..., so you would need to demonstrate that
the variables over which you had enumerated represented the entire set of
factors which could affect the program's behaviour.
For a C function e.g. "int foo(int x)", you could enumerate over the range
of "int" (provided that it's no larger than 32 bits; won't work on ILP64),
but you would still need to demonstrate that the function doesn't depend
upon global variables.
OTOH, for a function "int foo(double x)", even if you could prove
that nothing other than the parameter x affected the function's return
value, you still couldn't enumerate over the range of a typical "double".
Richard
> On Tue, 24 Nov 2009 05:14:39 -0800, Nick Keighley wrote:
>
>>> > The rejection of the excluded middle is echoed in Dijkstra's belief
>>> > that testing can NEVER prove bug absence.
>>>
>>> Wrong. The belief that testing can NEVER prove bug absence comes from the
>>> mathematical belief that testing can not prove a theorem over an infinite
>>> set of objects. If has absolutely nothing to do with the rejection of the
>>> excluded middle.
>>
>> I know this Dijkstra quote get trotted out a lot, but is it actually
>> true? Computers don't actually deal in infinite sets. So in principle
>> I can enumerate all cases. This may be practically impossible for
>> large or complex programs but it can be done in some cases. Therefore
>> the "never" above (which isn't in Dijkstra's quote) is not true.
>
> You would still have to prove that you had enumerated over the entire set
> of "inputs".
For certain functions thats trivial.
>
> E.g. for a Unix program, there's no way that you could enumerate over the
> entire set of possible combinations for argv[] and environ[] and kernel
> state and hardware state and ..., so you would need to demonstrate that
> the variables over which you had enumerated represented the entire set of
> factors which could affect the program's behaviour.
Err maybe. But in the real world you can prove that certain functions
are ONLY called with a finite set of inputs. Sure if you take that
function outside of its framework thats a totally different issue.
>
> For a C function e.g. "int foo(int x)", you could enumerate over the range
> of "int" (provided that it's no larger than 32 bits; won't work on ILP64),
> but you would still need to demonstrate that the function doesn't depend
> upon global variables.
Well. That's easy enough. or you comment the legal inputs and assume its
only called with them. if you want you can man trap the entry point to
simply return a safe return code if the inputs are not in range.
>
> OTOH, for a function "int foo(double x)", even if you could prove
> that nothing other than the parameter x affected the function's return
> value, you still couldn't enumerate over the range of a typical
> "double".
But you could test it for a few numbers within a certain limit of float
and declare it works in that range. If you suggest to me there might be
a subtle bug only on 2.339058309583905890 then we might as well give
up....
Kaz Kylheku
> true? Computers don't actually deal in infinite sets. So in principle
In Usenet, it's even the case that non-testing can prove the absence of
functionality. E.g. ``I know nothing about that <editor/os/programming
language> but I know it's broken and it sucks. :)
> I can enumerate all cases.
Dijkstra might say to that: if you are able to test a hypothesis for all
possible combinations of all of its inputs, then you are not really testing any
more, but proving.
If a particular space is small enough to succumb to this approach, then in fact
that approach falls into the domain of formal verification.
By analogy, enumerating all values of the boolean variables in a simple logical
argument, to build an exhaustive truth table, is one of the formal ways of
proving or disproving that it's valid; it's different from software
testing.
> This may be practically impossible for
> large or complex programs but it can be done in some cases. Therefore
But it's practically impossible for even small programs! The combinatorial
explosion in the input space grows rather fast.
If there are four independent inputs that are 32 bits wide, you have 128 bits.
Also, you really have to be sure that you are exhaustively testing the space.
Certain bugs can increase the space. If the program invokes undefined
behaviors, how do you know they don't explode the space?
For instance, accessing some uninitialized memory of 32 bits might not appear
as an obvious input to your program, but it could potentially blow up your
state space by a factor of 2^32.
And then of course are programs with real-time behavior, where no test
case is 100% repeatable, even if you build a detailed simulation of
the system (which will be necessarily a discrete simulation).
Richard Heathfield
<d787160b-2ffd-453d...@f20g2000vbl.googlegroups.com>,
Nick Keighley wrote:
Yes, of course there is. Did I not mention that I was using /his/
reasoning?
Nick Keighley
That was probably Dijkstra's point. You need to prove something about
the program. There a programs where I could easily demonstrate that
argv[] and environ[] if I also assume my platform is working then I
can exhaustivly test small programs.
If you regard testing as an automatic way of proving certain
properties about a program then the Dijkstras have less reason for
dismissing it. Look at the TDD people.
> > For a C function e.g. "int foo(int x)", you could enumerate over the range
> > of "int" (provided that it's no larger than 32 bits; won't work on ILP64),
it will work it'll just take a long time...
:-)
> > but you would still need to demonstrate that the function doesn't depend
> > upon global variables.
>
> Well. That's easy enough. or you comment the legal inputs and assume its
> only called with them. if you want you can man trap the entry point to
> simply return a safe return code if the inputs are not in range.
or use assert(), another handy automatic verification tool.
> > OTOH, for a function "int foo(double x)", even if you could prove
> > that nothing other than the parameter x affected the function's return
> > value, you still couldn't enumerate over the range of a typical
> > "double".
>
> But you could test it for a few numbers within a certain limit of float
> and declare it works in that range. If you suggest to me there might be
> a subtle bug only on 2.339058309583905890 then we might as well give
> up....
you haven't used Intel hardware have you?
http://en.wikipedia.org/wiki/Pentium_FDIV_bug
I'd be *much* warier about enumerating all possibilities once floating
point was added into the mix. I'd be less certain about my proofs too.
Nick Keighley
> In
>
>
>
>
>
> Nick Keighley wrote:
> > On 17 Nov, 08:11, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> In <87tywtvd11....@temporary-address.org.uk>, Nick wrote:
>
> >> <snip>
>
> >> > So using a variable name convention affects the numerical
> >> > precision of the compiler does it? Or if not, when the compiler
> >> > changes you must change your variable names? You surely can't
> >> > mean that. So let's return to my question. As you are not
> >> > writing comprehensible English, what's the reason?
>
> >> I can answer that, using what passes for his reasoning:
>
> >> 1) all clear statements are true
> >> 2) therefore all unclear statements are false
> >> 3) everything he says is unclear
> >> 4) therefore everything he says is false
>
> > isn't there therefore a paradox?
>
> Yes, of course there is. Did I not mention that I was using /his/
> reasoning?
but but that would mean he either had an inconsistent set of
postulates or his inference rules were faulty!
Dik T. Winter
...
> But you could test it for a few numbers within a certain limit of float
> and declare it works in that range. If you suggest to me there might be
> a subtle bug only on 2.339058309583905890 then we might as well give
> up....
Well, you know, actually such things *do* happen. You will probably know
about Intels floating poit bug which was just such kind of bug. I know
of a bug in Cray hardware multiplication where for some pairs of non-zero
input numbers the half-precision product would be zero. Partial testing
does not prove it works also with the non-tested inputs.
Richard
> In article <hei0f0$tkv$1...@news.eternal-september.org> Richard <rgr...@gmail.com> writes:
> ...
> > But you could test it for a few numbers within a certain limit of float
> > and declare it works in that range. If you suggest to me there might be
> > a subtle bug only on 2.339058309583905890 then we might as well give
> > up....
>
> Well, you know, actually such things *do* happen. You will probably
> know
Yes. And lightning strikes twice. Meanwhile in the real world we test
certain fringe conditions, guards to prevent them being extended and
some reasonable middle of the road ones.
If there are HW issues then you can give up straight away.
Eric Sosman
> In article <hei0f0$tkv$1...@news.eternal-september.org> Richard <rgr...@gmail.com> writes:
> ...
> > But you could test it for a few numbers within a certain limit of float
> > and declare it works in that range. If you suggest to me there might be
> > a subtle bug only on 2.339058309583905890 then we might as well give
> > up....
>
> Well, you know, actually such things *do* happen. You will probably know
> about Intels floating poit bug which was just such kind of bug. I know
> of a bug in Cray hardware multiplication where for some pairs of non-zero
> input numbers the half-precision product would be zero. Partial testing
> does not prove it works also with the non-tested inputs.
Many years ago I ran across just such a problem with the
software floating-point simulator on a machine: I found a
pair of numbers whose as-computed product was three times
what it should have been. Change any bit in the sign or
fraction part of either number (the bug was exponent-blind),
and the product came out correctly.
(Disclaimer: I didn't spot the bug all by myself. A very
sharp-eyed quality assurance person first noticed that the
rate of descent of one of my simulated aircraft went 4, 8, 36,
16, 20, 72, 28, ... feet per second. He reported the original
bug against my code; I tracked it back to the F-P simulator.)
So as Dik says: Actually, such things *do* happen.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Richard
Yes things do happen.
But the point is you can prove your function works for a certain range
of discrete inputs.
Nick
> On Tue, 24 Nov 2009 05:14:39 -0800, Nick Keighley wrote:
>
>>> > The rejection of the excluded middle is echoed in Dijkstra's belief
>>> > that testing can NEVER prove bug absence.
>>>
>>> Wrong. The belief that testing can NEVER prove bug absence comes from the
>>> mathematical belief that testing can not prove a theorem over an infinite
>>> set of objects. If has absolutely nothing to do with the rejection of the
>>> excluded middle.
>>
>> I know this Dijkstra quote get trotted out a lot, but is it actually
>> true? Computers don't actually deal in infinite sets. So in principle
>> I can enumerate all cases. This may be practically impossible for
>> large or complex programs but it can be done in some cases. Therefore
>> the "never" above (which isn't in Dijkstra's quote) is not true.
>
> You would still have to prove that you had enumerated over the entire set
> of "inputs".
>
> E.g. for a Unix program, there's no way that you could enumerate over the
> entire set of possible combinations for argv[] and environ[] and kernel
> state and hardware state and ..., so you would need to demonstrate that
> the variables over which you had enumerated represented the entire set of
> factors which could affect the program's behaviour.
>
> For a C function e.g. "int foo(int x)", you could enumerate over the range
> of "int" (provided that it's no larger than 32 bits; won't work on ILP64),
> but you would still need to demonstrate that the function doesn't depend
> upon global variables.
Or contained any static variables.
--
Online waterways route planner: http://canalplan.org.uk
development version: http://canalplan.eu
Keith Thompson
> Nobody <nob...@nowhere.com> writes:
[...]
>> For a C function e.g. "int foo(int x)", you could enumerate over the range
>> of "int" (provided that it's no larger than 32 bits; won't work on ILP64),
>> but you would still need to demonstrate that the function doesn't depend
>> upon global variables.
>
> Or contained any static variables.
Or depend on any static variables declared outside the function but in
the same translation unit. Or depend on any static variables declared
in other functions or in other translation units that it might access
indirectly. Or depend on any other state that might persist from one
call to another, such as external files, random numbers, or the phase
of the moon.
Nick
> Nick <3-no...@temporary-address.org.uk> writes:
>> Nobody <nob...@nowhere.com> writes:
> [...]
>>> For a C function e.g. "int foo(int x)", you could enumerate over the range
>>> of "int" (provided that it's no larger than 32 bits; won't work on ILP64),
>>> but you would still need to demonstrate that the function doesn't depend
>>> upon global variables.
>>
>> Or contained any static variables.
>
> Or depend on any static variables declared outside the function but in
> the same translation unit.
I tend to think of those as "global" variables - they are global to all
functions in the translation unit. They're not properly global, of
course.
>Or depend on any static variables declared
> in other functions or in other translation units that it might access
> indirectly. Or depend on any other state that might persist from one
> call to another, such as external files, random numbers, or the phase
> of the moon.
Or any sort of undefined behaviour (depending on hidden state) that is
only triggered by a particular combination of inputs.
Consider a function that opens, then closes /twice/ a file if passed a
value of 912.
On the machine I was using a few years ago (and it might be true on this
one), this would crash iff called with 912 twice. Call it with one 912
in among any other inputs and you'd be fine.
Totally undefined of course - but that's most certainly a bug.
I'm sure you can do something equally horrible with the might mix of
mallocs and frees on many implementations (indeed, I strongly suspect my
painful experience with fopen was due to malloc/free calls in the
background).
Nick Keighley
> "Dik T. Winter" <Dik.Win...@cwi.nl> writes:
> > > But you could test it for a few numbers within a certain limit of float
> > > and declare it works in that range. If you suggest to me there might be
> > > a subtle bug only on 2.339058309583905890 then we might as well give
> > > up....
>
> > Well, you know, actually such things *do* happen. You will probably
> > know
>
> Yes. And lightning strikes twice. Meanwhile in the real world we test
> certain fringe conditions, guards to prevent them being extended and
> some reasonable middle of the road ones.
yes, but that puts Dijkstra's quote firmly back in place. Such testing
cannot prove the absence of bugs.
> If there are HW issues then you can give up straight away.
but it's such /fun/ debugging software on broken hardware!
--
After a couple of projects that I've done in scheme, after many years
of
C (and assembler), I've come to the conclusion that even *starting* a
program in C is an exercise in premature optimization.
(Andrew Reilly comp.lang.scheme)
Dik T. Winter
Yeah. Only you do not know without extensive study of the program what the
fringe conditions are. Both the BSD versions of Adventure and Zork had a
bug due to an incorrect bit in a table entry, and in Adventure it could be
fatal.
> If there are HW issues then you can give up straight away.
Yes, you have to work around it. The bug in the Cray instruction I found
with a program that tested large numbers for primality and consistently told
all Mersenne numbers were prime where the program concluded later that it
was saying that due to a bug in the program. Now when I first encountered
that message how am I supposed to believe all thousands previous announcements
of the program?
stan
Actually that proves the function gives the outputs you got for the
inputs you gave in the state you tested. You can't draw any rational
conclusions about other inputs. You might have a warm and fuzzy
feeling, but that's still speculative thinking; not a proof. Proof is
a really strong word with a well defined meaning. Testing can't
eliminate the possibility you have undefined behavior that gives
changing outputs under changing states either. It's possible one or
more of the values you provided as input will fail later. Sooner or
later everyone chases an intermittent bug.
Richard Bos
> In article <hejj6b$ula$1...@news.eternal-september.org> Richard <rgr...@gmail.com> writes:
> > Yes. And lightning strikes twice. Meanwhile in the real world we test
> > certain fringe conditions, guards to prevent them being extended and
> > some reasonable middle of the road ones.
>
> Yeah. Only you do not know without extensive study of the program what the
> fringe conditions are. Both the BSD versions of Adventure and Zork had a
> bug due to an incorrect bit in a table entry, and in Adventure it could be
> fatal.
Did they? Now I'm curious. Particularly if it was the _same_ bug, which
(those programs being from rather different provenance) Shouldn't
Happen. Do tell.
Richard
Dik T. Winter
> "Dik T. Winter" <Dik.W...@cwi.nl> wrote:
> > > Yes. And lightning strikes twice. Meanwhile in the real world we test
> > > certain fringe conditions, guards to prevent them being extended and
> > > some reasonable middle of the road ones.
> >
> > Yeah. Only you do not know without extensive study of the program what the
> > fringe conditions are. Both the BSD versions of Adventure and Zork had a
> > bug due to an incorrect bit in a table entry, and in Adventure it could be
> > fatal.
>
> Did they? Now I'm curious. Particularly if it was the _same_ bug, which
> (those programs being from rather different provenance) Shouldn't
No they were not the same.
> Happen. Do tell.
In BSD Adventure go down the volcano and go in a direction that is not
mentioned in the description.
In BSD Zork try opening some of the things that inherently cannot be
opened.
Richard Tobin
>In BSD Adventure go down the volcano and go in a direction that is not
>mentioned in the description.
>In BSD Zork try opening some of the things that inherently cannot be
>opened.
And BSD Rogue had a bug (the "weird trap bug") due to incorrect setting
of a bit field.
-- Richard
--
Please remember to mention me / in tapes you leave behind.