By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,718 Members | 1,840 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,718 IT Pros & Developers. It's quick & easy.

floating point problem

P: n/a
hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

regards,

eric

Jul 20 '06 #1
Share this Question
Share on Google+
33 Replies


P: n/a
di**********@yahoo.com wrote:
hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..
Welcome to the joyous, imprecise world of floating point. Consult the
group's FAQ and all will be explained.

--
Ian Collins.
Jul 20 '06 #2

P: n/a
MQ

di**********@yahoo.com wrote:
hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..
I don't get the same results. It does say "hi" for the first one, but
is "hello" for the second and third cases. Is this what you meant?

Jul 20 '06 #3

P: n/a
>hi....i have encountered strange problem regarding floating point
>comparison...the problem is...
There is no exact representation for most non-integer values in
binary floating point. The closest possible value may be above or
below the exact mathematical value.

0.7 as double:
Before: 0.699999999999999844568776552478084340691566467285 156250000000
Value: 0.699999999999999955591079014993738383054733276367 187500000000
After: 0.700000000000000066613381477509392425417900085449 218750000000

0.7 as float:
Before: 0.699999928474426269531250000000000000000000000000 000000000000
Value: 0.699999988079071044921875000000000000000000000000 000000000000
After: 0.700000047683715820312500000000000000000000000000 000000000000

0.8 as double:
Before: 0.799999999999999933386618522490607574582099914550 781250000000
Value: 0.800000000000000044408920985006261616945266723632 812500000000
After: 0.800000000000000155431223447521915659308433532714 843750000000

0.8 as float:
Before: 0.799999952316284179687500000000000000000000000000 000000000000
Value: 0.800000011920928955078125000000000000000000000000 000000000000
After: 0.800000071525573730468750000000000000000000000000 000000000000
>
main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..
Gordon L. Burditt
Jul 20 '06 #4

P: n/a
di**********@yahoo.com wrote:
hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is
hi....the program is run on a linux system....if anybody explains
this problem it will be very helpful...thanx in advance...bye..

http://c-faq.com/fp/strangefp.html


Brian
Jul 20 '06 #5

P: n/a
MQ
And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...

Jul 20 '06 #6

P: n/a
di**********@yahoo.com writes:
hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've asked
something very close to question 14.1.

(Incidentally, the ellipsis, "...", doesn't mean what you think it
means.)

--
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.
Jul 20 '06 #7

P: n/a
MQ said:
And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...
No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are 2^32
possible bit combinations. That's 4294967296 different numbers.

FLT_MAX is 1E37. That's 10000000000000000000000000000000000000.
So for every single bit combination, there are 2328306436538696289062500000
*integers* that need to be represented by it, let alone infinitely many
real numbers.

You can't fit infinitely many infinitely long bit sequences into a finite
number of bits without a little lossitude.

--
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)
Jul 20 '06 #8

P: n/a

Keith Thompson wrote:

The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've asked
something very close to question 14.1.

Not even remotely correct. Question 14.1 has to do with printf
floating point output, which is explicitly rounded by the
floating-point output routine to the nearest DECIMAL digit.

The original poster's question has to do with floating-point
comparisons. A whole differnt ball of wax. Or tar.

The correct answer is more involved: The constant "0.7" when first
seen by the compiler is evaluated to the precision of a double. When
you store this constant into your variable, the compiler silently
truncates it to the width of a float.

Then when you compare the variable to another "0.7", the compiler sees
things diffeerently-- it sees a double (the constant) being compared to
a float (the variable). In order to not lose any precison, the
compiler then (silently) converts the float variable to a double and
does a DOUBLE comparison. Here's the code geneated by Watcom C for
the relevant section of code:

mov dword ptr -0x8[ebp],0x3f333333 // store 3f333333
into the float variable
fld dword ptr -0x8[ebp] // push the dword (4-byte)
variable onto the fp stack
fcomp qword ptr L$3 // compare top of stack with
qword (8 byte) constant
Segment: CONST DWORD USE32 00000011 bytes
L$3:
66 66 66 66 66 66 E6 3F // 0.7 as a DOUBLE
(64-bit) constant
... as you can see, the float contant 0.7 is 0xf333333, while as a
double, it goes on for another 4 bytes. When compared, they're not
equal.

Now if you'd used the statement: if( 0.7f < a ) the compiler
would see TWO floats and do a FLOAT comparison, which is much more
likely to show equality. This is the relevant code:
0050 D9 05 14 00 00 00 fld dword ptr L$8
0056 D8 5D F8 fcomp dword ptr -0x8[ebp]

Notice it's pushing a dword and comparing it with a dword, so there's a
much better chance of equality reigning.

<soap>
But IN GENERAL, you should NEVER expect two floating-point quantities
to be ever equal or non-equal. The chances are vanishingly small.
Some more rational languages, such as APL, take this into account and
you can set the amount of "fuzz" you want to allow for equality tests.
In the other languages, you need to write some function to do
approximate equality tests, something like this if you decide being
within one part per million is close enough:

boolean AreWithinOnePPM( double a, b ) { double delta;
delta = fabs( a - b );
return fabs( a ) / 1.0E-6 < delta ;
}
</SOAP>

Jul 20 '06 #9

P: n/a
A few more points:

I got the comparison direction backwards AND goofed on the constant's
type, it doesnt change the result, but for clarity it should be:

boolean AreWithinOnePPM( double a, b ) { double delta;
delta = fabs( a - b );
return delta < fabs( a ) / 1.0D-6 ;
}
Jul 20 '06 #10

P: n/a
Ian Collins wrote:
di**********@yahoo.com wrote:
>>hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

Welcome to the joyous, imprecise world of floating point.
Well, sort of, but that's not really the problem here.
The real issue in this program is that `float' and `double'
have different precisions (on most systems).
Consult the
group's FAQ and all will be explained.
A link would be helpful: One place to find the FAQ is

http://c-faq.com/

--
Eric Sosman
es*****@acm-dot-org.invalid
Jul 20 '06 #11

P: n/a

Richard Heathfield wrote:
MQ said:
And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...

No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are 2^32
possible bit combinations. That's 4294967296 different numbers.
Um, no. Floating-point numbers are almost always "normalized", which
on some architectures means means you never have leading binary zeroes;
on other Fp formats, an extra leading "1" bit is assumed, but never
seen, so you have an extra bit, but then you *do* have leading and
significant zeroes. Also in many formats there are reserved exponent
values, for instance an exponent of all zeroes or all 1's often implies
an exact zero, no matter what the mantissa says. Other places there
are reserved exponents and mantissas for flagging indefinite, inexact,
unset, or infiite values.

FLT_MAX is 1E37. That's 10000000000000000000000000000000000000.
Very few machines have decimal floating-point numbers, and those that
do are unlikely to have a binary (2^127 or whatnot) exponent limit. .
The exact FLT_MAX is likely to be different on a binary machine.

You can't fit infinitely many infinitely long bit sequences into a finite
number of bits without a little lossitude.
The poor OP question was a bit more de-facto-- "why do two uses of 0.7
work differently". See other posts for answer.

Jul 20 '06 #12

P: n/a
In article <11**********************@i42g2000cwa.googlegroups .com"Ancient_Hacker" <gr**@comcast.netwrites:
>
Richard Heathfield wrote:
MQ said:
And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...
No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are 2^32
possible bit combinations. That's 4294967296 different numbers.

Um, no.
Let's have 32-bit floats. So there are 4294967296 different bit patterns.
That means that at most so many numbers can be represented.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jul 20 '06 #13

P: n/a
Ancient_Hacker said:
>
Richard Heathfield wrote:
>MQ said:
And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...

No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are
2^32 possible bit combinations. That's 4294967296 different numbers.

Um, no. Floating-point numbers are almost always "normalized", which
on some architectures means means you never have leading binary zeroes;
Um, that is totally and utterly irrelevant to my point, which is that with
32 bits you only have 2^32 bit patterns so you can only represent 2^32
different values, and this is true no matter what those values are. If you
have N bits, you have 2^N possible values. No matter how large N is (within
the constraints of the real world), there will never be enough bits to
represent all possible numbers. Therefore, it is inevitable that some
numbers can only be represented approximately. QED.

<snip>

--
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)
Jul 20 '06 #14

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrites:
Keith Thompson wrote:
>The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've asked
something very close to question 14.1.


Not even remotely correct. Question 14.1 has to do with printf
floating point output, which is explicitly rounded by the
floating-point output routine to the nearest DECIMAL digit.
Yes, it is remotely correct. 8-)}

Question 14.1 is really only peripherally about printf.

Q: When I set a float variable to, say, 3.1, why is printf
printing it as 3.0999999?

A: Most computers use base 2 for floating-point numbers as well as
for integers, and just as for base 10, not all fractions are
representable exactly in base 2. It's well-known that in base
10, a fraction like 1/3 = 0.333333... repeats infinitely. It
turns out that in base 2, one tenth is also an
infinitely-repeating fraction (0.0001100110011...), so exact
decimal fractions such as 3.1 cannot be represented exactly in
binary. Depending on how carefully your compiler's
binary/decimal conversion routines (such as those used by
printf) have been written, you may see discrepancies when
numbers not exactly representable in base 2 are assigned or
read in and then printed (i.e. converted from base 10 to base 2
and back again). [footnote] See also question 14.6.

Both 14.1 and the OP's question are basically about the fact that
floating-point is inexact, and values like 3.1 and 0.7 cannot be
represented exactly.
The original poster's question has to do with floating-point
comparisons. A whole differnt ball of wax. Or tar.

The correct answer is more involved: The constant "0.7" when first
seen by the compiler is evaluated to the precision of a double. When
you store this constant into your variable, the compiler silently
truncates it to the width of a float.
You're right, the OP's situation is also affected by float vs. double
issues. I should have picked up on that. In fact, a better answer
would have been to suggest that the OP should read all of section 14
of the FAQ (though I'm not sure it addresses this specific issue).
Then when you compare the variable to another "0.7", the compiler sees
things diffeerently-- it sees a double (the constant) being compared to
a float (the variable). In order to not lose any precison, the
compiler then (silently) converts the float variable to a double and
does a DOUBLE comparison. Here's the code geneated by Watcom C for
the relevant section of code:
[snip]

IMHO, the issue can be explained more clearly without resorting to
assembly language.

--
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.
Jul 20 '06 #15

P: n/a

Richard Heathfield wrote:
Um, that is totally and utterly irrelevant to my point, which is that with
32 bits you only have 2^32 bit patterns so you can only represent 2^32
different values,
One might suspect most programmers are aware it's impossible to
represent an infinite number of distinct states in a computer.

This poor sod was just wondering why 0.7 didnt seem to equal 0.7, and
probably wanting to learn why and how to avoid this in the future.

So that comment was obvious, inaccurate and generally unhelpful toward
the goal of answering the posers question.

Is the goal of this ng to polish our egos in cyberspace or to maybe
actually help answer the questions posed? :)

Jul 20 '06 #16

P: n/a
Ancient_Hacker said:
>
Richard Heathfield wrote:
>Um, that is totally and utterly irrelevant to my point, which is that
with 32 bits you only have 2^32 bit patterns so you can only represent
2^32 different values,

One might suspect most programmers are aware it's impossible to
represent an infinite number of distinct states in a computer.
One might, but one doesn't need to read the IEEE 754 spec to understand why.
This poor sod was just wondering why 0.7 didnt seem to equal 0.7, and
probably wanting to learn why and how to avoid this in the future.

So that comment was obvious, inaccurate and generally unhelpful toward
the goal of answering the posers question.
If you check up, you'll find that I wasn't answering the OP's question. I
was making a followup comment to a followup answer.
Is the goal of this ng to polish our egos in cyberspace or to maybe
actually help answer the questions posed? :)
The goal of this newsgroup is the discussion of C programming. To answer
questions is *not* in fact the aim.

The questions asked here are rarely terribly interesting, but they often
lead to very interesting spin-off discussions about the less obvious
aspects of C and computer science. That is why some people bother to answer
them. Others like to answer them because they're nice guys who like to help
out. Sometimes the motivation is a mix of the two, and no doubt there are
other reasons why people here answer questions, but it is not the primary
purpose of the group.

--
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)
Jul 20 '06 #17

P: n/a
On Thu, 20 Jul 2006, Richard Heathfield wrote:
The questions asked here are rarely terribly interesting, but they often
lead to very interesting spin-off discussions about the less obvious
aspects of C and computer science. That is why some people bother to answer
them. Others like to answer them because they're nice guys who like to help
out. Sometimes the motivation is a mix of the two, and no doubt there are
other reasons why people here answer questions, but it is not the primary
purpose of the group.
In the above quote, Richard said ``C and computer science''
instead of just ``C''---and then he ended with ``other reasons...
not the primary purpose of the group''. This seems to suggest
that computer science is one of the primary purposes here!

Tak-Shing
Jul 20 '06 #18

P: n/a
di**********@yahoo.com wrote:
hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

regards,

eric
Do this instead..

#include <stdio.h>
int main(void) {
float f = 0.7;
double d = 0.7;
printf("%.16e\n", f);
printf("%.16e\n", d);
return 0;
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jul 20 '06 #19

P: n/a
"Tak-Shing Chan" <t.****@gold.ac.ukwrote in message
news:Pi******************************@scorpio.gold .ac.uk...
On Thu, 20 Jul 2006, Richard Heathfield wrote:
>The questions asked here are rarely terribly interesting, but they often
lead to very interesting spin-off discussions about the less obvious
aspects of C and computer science. That is why some people bother to
answer
them. Others like to answer them because they're nice guys who like to
help
out. Sometimes the motivation is a mix of the two, and no doubt there are
other reasons why people here answer questions, but it is not the primary
purpose of the group.

In the above quote, Richard said ``C and computer science''
instead of just ``C''---and then he ended with ``other reasons...
not the primary purpose of the group''. This seems to suggest
that computer science is one of the primary purposes here!
If it were nothing but C, then the group could be replaced by a pointer to
the ANSI/ISO C standard.

The things that really get posted here are usually mixtures of C and C
related things and things unrelated to C. The amount of tangentiality that
is allowed is probably a bit less than other groups, but that keeps the
group focused.

I recently went off on a tangent about algorithms. Now, we write algorithms
in C (and we might also say that we use C to write algorithms). We can
stray further and further from the core ideas until we are talking about
rainbows and aluminum (which is munimula, when spelled backwards).
Eventually, we must arrive at something which no longer holds any interest
for the vast majority of denizens of c.l.c.

But of course, this post is topical (along with both Richard's post and your
response) because it is a discussion of topicality, which is always
topical -- at least according to long established USENET tradition.
Tak-Shing

Jul 20 '06 #20

P: n/a
On Thu, 20 Jul 2006, Dann Corbit wrote:
"Tak-Shing Chan" <t.****@gold.ac.ukwrote in message
news:Pi******************************@scorpio.gold .ac.uk...
>On Thu, 20 Jul 2006, Richard Heathfield wrote:
>>The questions asked here are rarely terribly interesting, but they often
lead to very interesting spin-off discussions about the less obvious
aspects of C and computer science. That is why some people bother to
answer
them. Others like to answer them because they're nice guys who like to
help
out. Sometimes the motivation is a mix of the two, and no doubt there are
other reasons why people here answer questions, but it is not the primary
purpose of the group.

In the above quote, Richard said ``C and computer science''
instead of just ``C''---and then he ended with ``other reasons...
not the primary purpose of the group''. This seems to suggest
that computer science is one of the primary purposes here!

If it were nothing but C, then the group could be replaced by a pointer to
the ANSI/ISO C standard.

The things that really get posted here are usually mixtures of C and C
related things and things unrelated to C. The amount of tangentiality that
is allowed is probably a bit less than other groups, but that keeps the
group focused.

I recently went off on a tangent about algorithms. Now, we write algorithms
in C (and we might also say that we use C to write algorithms). We can
stray further and further from the core ideas until we are talking about
rainbows and aluminum (which is munimula, when spelled backwards).
Eventually, we must arrive at something which no longer holds any interest
for the vast majority of denizens of c.l.c.

But of course, this post is topical (along with both Richard's post and your
response) because it is a discussion of topicality, which is always
topical -- at least according to long established USENET tradition.
``Primary'' and ``tangentiality'' are antonyms. As far as I
know, computer science is not the primary purpose of this group.

Tak-Shing
Jul 20 '06 #21

P: n/a
"Tak-Shing Chan" <t.****@gold.ac.ukwrote in message
[snip]
``Primary'' and ``tangentiality'' are antonyms. As far as I
know, computer science is not the primary purpose of this group.
No, but a subset of computer science is the primary purpose of the group.
Tak-Shing

Jul 20 '06 #22

P: n/a
di**********@yahoo.com wrote:
hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

regards,

eric
float a = 0.7 has a precision of 24 bits. 0.7 is a double with precision
(here) of 53 bits. As it turns out the double 0.7 is larger than the
float 0.7 by a bit. :-)

The float converted to double:
6.9999998807907104e-01

The double:
6.9999999999999996e-01

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jul 20 '06 #23

P: n/a
On 20 Jul 2006 08:33:57 -0700, in comp.lang.c , "Ancient_Hacker"
<gr**@comcast.netwrote:
>
Richard Heathfield wrote:
>Um, that is totally and utterly irrelevant to my point, which is that with
32 bits you only have 2^32 bit patterns so you can only represent 2^32
different values,

One might suspect most programmers are aware it's impossible to
represent an infinite number of distinct states in a computer.
One might, but one would be disappointed. An alarmingly large number
of computer programmers seem to think that computers are exact.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jul 20 '06 #24

P: n/a
Tak-Shing Chan said:
On Thu, 20 Jul 2006, Richard Heathfield wrote:
>The questions asked here are rarely terribly interesting, but they often
lead to very interesting spin-off discussions about the less obvious
aspects of C and computer science. That is why some people bother to
answer them. Others like to answer them because they're nice guys who
like to help out. Sometimes the motivation is a mix of the two, and no
doubt there are other reasons why people here answer questions, but it is
not the primary purpose of the group.

In the above quote, Richard said ``C and computer science''
instead of just ``C''---and then he ended with ``other reasons...
not the primary purpose of the group''. This seems to suggest
that computer science is one of the primary purposes here!
Bear in mind that my view is not normative! I am merely stating my opinion,
which is that C discussions are the primary purpose of the group.

Computer science discussions are not strictly topical, but are a
nice-to-have when they flow naturally from a topical discussion.

--
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)
Jul 20 '06 #25

P: n/a
On Thu, 20 Jul 2006, Dann Corbit wrote:
"Tak-Shing Chan" <t.****@gold.ac.ukwrote in message
[snip]
> ``Primary'' and ``tangentiality'' are antonyms. As far as I
know, computer science is not the primary purpose of this group.

No, but a subset of computer science is the primary purpose of the group.
The original context is ``C and computer science''. It is
quite clear to me that this is not referring to a subset. More
to the point, if the subset in question is ``general issues of
the C programming language, as defined by the ANSI/ISO language
standard'' (Billy Chambless), then the phrase ``C and computer
science'' becomes redundant.

Tak-Shing
Jul 20 '06 #26

P: n/a
On Thu, 20 Jul 2006, Richard Heathfield wrote:
Computer science discussions are not strictly topical, but are a
nice-to-have when they flow naturally from a topical discussion.
In other words original posters aren't allowed to post
off-topic while the question-answerers (regulars) can as long as
it's deemed ``natural''. Interesting view. :-)

Tak-Shing
Jul 20 '06 #27

P: n/a
Tak-Shing Chan said:
On Thu, 20 Jul 2006, Richard Heathfield wrote:
>Computer science discussions are not strictly topical, but are a
nice-to-have when they flow naturally from a topical discussion.

In other words original posters aren't allowed to post
off-topic
That depends on what you mean by "allowed". OPs /do/ post off-topic
material, after all.
while the question-answerers (regulars) can as long as
it's deemed ``natural''.
Nobody is doing any deeming, and anybody /can/ post what they like - it is
not a question of whether they /can/, but whether they /should/.

Kaz once talked about solid, topical articles being like pennies in the
bank, and off-topic articles being dollar withdrawals. That's a pretty good
analogy. And of course the trick is to stay in credit. (Warning: that's
just an analogy, and is not to be taken literally - nobody is doing the
accounting, as far as I am aware.)

--
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)
Jul 20 '06 #28

P: n/a
On Thu, 20 Jul 2006, Richard Heathfield wrote:
Kaz once talked about solid, topical articles being like pennies in the
bank, and off-topic articles being dollar withdrawals. That's a pretty good
analogy. And of course the trick is to stay in credit. (Warning: that's
just an analogy, and is not to be taken literally - nobody is doing the
accounting, as far as I am aware.)
I do not think that this is a good analogy. IMHO the level
of expertise and/or effort required to answer the question should
be taken into account. I have in mind the mini-essays from Chris
Torek which in the real world should worth 20 times more than the
average on-topic posts (in terms of the post-to-pennies ratio).

Tak-Shing
Jul 20 '06 #29

P: n/a
Tak-Shing Chan said:
On Thu, 20 Jul 2006, Richard Heathfield wrote:
>Kaz once talked about solid, topical articles being like pennies in the
bank, and off-topic articles being dollar withdrawals. That's a pretty
good analogy. And of course the trick is to stay in credit. (Warning:
that's just an analogy, and is not to be taken literally - nobody is
doing the accounting, as far as I am aware.)

I do not think that this is a good analogy.
That is your prerogative. Feel free to take it up with Kaz next time he
shows up in here.
IMHO the level
of expertise and/or effort required to answer the question should
be taken into account.
Quite so - all solid, topical articles earn pennies[1], but some earn more
pennies than others. In other words, the analogy holds (thus far).
I have in mind the mini-essays from Chris
Torek which in the real world should worth 20 times more than the
average on-topic posts (in terms of the post-to-pennies ratio).
At the very least.
[1] What do you mean, you haven't been getting your cheques? Take it up with
your ISP.

--
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)
Jul 20 '06 #30

P: n/a
In article <oh********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrote:
On 20 Jul 2006 08:33:57 -0700, in comp.lang.c , "Ancient_Hacker"
<gr**@comcast.netwrote:

Richard Heathfield wrote:
Um, that is totally and utterly irrelevant to my point, which is that with
32 bits you only have 2^32 bit patterns so you can only represent 2^32
different values,
One might suspect most programmers are aware it's impossible to
represent an infinite number of distinct states in a computer.

One might, but one would be disappointed. An alarmingly large number
of computer programmers seem to think that computers are exact.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Or as Scotty put it on Star Trek, "The more complicated you make the
plumbing, the easier it is to stop it up." (Or something like that.)

Kernighan's is the, er, more polite of the two... And I wanted Mark to
know SOMEBODY, at least, appreciates his digging it out.

Sorry for the off-topicality...

--
Ron Bruck

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Jul 20 '06 #31

P: n/a
In article <11**********************@h48g2000cwc.googlegroups .com"Ancient_Hacker" <gr**@comcast.netwrites:
Richard Heathfield wrote:
Um, that is totally and utterly irrelevant to my point, which is that with
32 bits you only have 2^32 bit patterns so you can only represent 2^32
different values,

One might suspect most programmers are aware it's impossible to
represent an infinite number of distinct states in a computer.
Ah, but Richard is incorrect here. 2^32 bit patterns can represent *at
most* 2^32 different values. There can be different representations that
represent the same value.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jul 20 '06 #32

P: n/a
Dik T. Winter said:
In article <11**********************@h48g2000cwc.googlegroups .com>
"Ancient_Hacker" <gr**@comcast.netwrites:
Richard Heathfield wrote:
>
Um, that is totally and utterly irrelevant to my point, which is that
with 32 bits you only have 2^32 bit patterns so you can only
represent 2^32 different values,
>
One might suspect most programmers are aware it's impossible to
represent an infinite number of distinct states in a computer.

Ah, but Richard is incorrect here.
I beg to differ...
2^32 bit patterns can represent *at
most* 2^32 different values. There can be different representations that
represent the same value.
....but I'll settle for "insufficiently precise". :-)
--
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)
Jul 21 '06 #33

P: n/a
"Tak-Shing Chan" <t.****@gold.ac.ukwrote in message
news:Pi*******************************@scorpio.gol d.ac.uk...
On Thu, 20 Jul 2006, Richard Heathfield wrote:
>Kaz once talked about solid, topical articles being like pennies in the
bank, and off-topic articles being dollar withdrawals. That's a pretty
good
analogy. And of course the trick is to stay in credit. (Warning: that's
just an analogy, and is not to be taken literally - nobody is doing the
accounting, as far as I am aware.)

I do not think that this is a good analogy. IMHO the level
of expertise and/or effort required to answer the question should
be taken into account. I have in mind the mini-essays from Chris
Torek which in the real world should worth 20 times more than the
average on-topic posts (in terms of the post-to-pennies ratio).
Which is to say that some deposits are a dollar or ten dollars or more.

So there are individual posters (Tanmoy Bhattacharya, Dan Pop, Chris Torek,
Peter Seebach, etc.) who have a huge balance on hand (c.l.c billionaires?).

Other posters are way, way, way overdrawn and have never managed a positive
balance.

Different posters see this forum in different ways. But I think a sensible
goal is to add value to the forum, which fits our analogy nicely. After
reading any chain of messages, I should walk away with some incremental
improvement in my understanding.

(Or at least a refresher of what I already knew).

So we should strive to have threads that impart focused knowledge to the
readers that is clear, unambiguous, and enlightening [not to mention
correct].

IMO-YMMV.
Tak-Shing

Jul 21 '06 #34

This discussion thread is closed

Replies have been disabled for this discussion.