C programming

[neha_chhatre]

#include <math.h>
#include <stdio.h>

float log(float num);
double log(double num);
long double log(long double num);

int main()
{
long double val = 1.0;
printf("%lg %lg\n", val, log(val));

do {
printf("%d %d\n", val, log(val));
val++;
} while (val<11.0);

return 0;
}
plz debug the program

[Malcolm McLean]

<ne**********@yahoo.co.inwrote in message #include <math.h>

#include <stdio.h>

float log(float num);
double log(double num);
long double log(long double num);

int main()
{
long double val = 1.0;
printf("%lg %lg\n", val, log(val));

do {
printf("%d %d\n", val, log(val));

Take two doubles, reinterpret the bits as two integers, and print the
results. Almost always you will get garbage. The exception is value 0.

>
val++;

Misuse of increment operator. Not a bug, but poor style. There is a
difference between incrementing something and adding a value that just
happens to be one. Here you just happen to have chosen a step size of one,
for whatever reason. Make that val += 1.0;

>
} while (val<11.0);

return 0;
}
plz debug the program

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

ne**********@yahoo.co.in wrote:

#include <math.h>
#include <stdio.h>

float log(float num);
double log(double num);
long double log(long double num);

int main()
{
long double val = 1.0;
printf("%lg %lg\n", val, log(val));

do {
printf("%d %d\n", val, log(val));
val++;
} while (val<11.0);

return 0;
}
plz debug the program

What's "plz"?

What do you expect the program to do and what does it do wrong?

--
Ian Collins.

[Martin Ambuhl]

ne**********@yahoo.co.in wrote:

#include <math.h>
#include <stdio.h>

float log(float num);
double log(double num);
long double log(long double num);

int main()
{
long double val = 1.0;
printf("%lg %lg\n", val, log(val));

do {
printf("%d %d\n", val, log(val));
val++;
} while (val<11.0);

return 0;
}
plz debug the program

As far as I know, plz has left this newsgroup for alt.illiterate.
It is also unlikely that you are in the right newsgroup, since the
multiple conflicting prototypes for log() are not legal in C. On the
off chance that you really meant to post in comp.lang.c, and that your
"C programming" subject line is not a blunder, and that you are willing
to take help for someone other than plz, whoever that is, here's a start:

#include <math.h>
#include <stdio.h>

int main(void)
{
int val = 1;
for (val = 1; val < 11; val++)
printf("%d %g\n", val, log(val));
return 0;
}

[santosh]

ne**********@yahoo.co.in wrote:

#include <math.h>
#include <stdio.h>

float log(float num);
double log(double num);
long double log(long double num);

<snip>

Note also that 'log' is already defined by Standard C in math.h. So your
prototypes above are wrong, (first and third ones), or redundant, (the
second one.)

Use the Standard functions logl and logf for long double and float
respectively.

[Ian Collins]

santosh wrote:

ne**********@yahoo.co.in wrote:

> #include <math.h>
#include <stdio.h>

float log(float num);
double log(double num);
long double log(long double num);

<snip>

Note also that 'log' is already defined by Standard C in math.h. So your
prototypes above are wrong, (first and third ones), or redundant, (the
second one.)

You forgot to mention that they are also illegal!

--
Ian Collins.

[Army1987]

On Sat, 06 Oct 2007 23:59:07 -0700, neha_chhatre wrote:

#include <math.h>
#include <stdio.h>

float log(float num);

Ought to be logf, and it's already declared in math.h.

double log(double num);

It's already declared in math.h.

long double log(long double num);

Ought to be logl, and it's already declared in math.h

>
int main()
{
long double val = 1.0;
printf("%lg %lg\n", val, log(val));

Either val should be made a double, or the printf should be
printf("%Lg &Lg\n", val, logl(val));

>
do {
printf("%d %d\n", val, log(val));

See above. In case you decide that val is a double, replace those
%d with %lg or %g. (%d is for int; %g and %lg is for double
(printf can't tell them from float since float get converted to
double before being passed to printf); %Lg is for long double.)

val++;
} while (val<11.0);

Ever heard about for?

>
return 0;
}

--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Army1987]

On Sun, 07 Oct 2007 08:07:25 +0100, Malcolm McLean wrote:

>
<ne**********@yahoo.co.inwrote in message #include <math.h>

> #include <stdio.h>

float log(float num);
double log(double num);
long double log(long double num);

int main()
{
long double val = 1.0;
printf("%lg %lg\n", val, log(val));

do {
printf("%d %d\n", val, log(val));

Take two doubles, reinterpret the bits as two integers, and print the
results. Almost always you will get garbage. The exception is value 0.

"Cause Undefine Behavior" is more correct. What happens if int is
smaller than double? Or viceversa? What requires all-bits-zero to
be a valid representation for the double 0.0?

>>
val++;

Misuse of increment operator. Not a bug, but poor style. There is a
difference between incrementing something and adding a value that just
happens to be one. Here you just happen to have chosen a step size of one,
for whatever reason. Make that val += 1.0;

Huh?

--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Malcolm McLean]

"Army1987" <ar******@NOSPAM.itwrote in message

>Misuse of increment operator. Not a bug, but poor style. There is a
difference between incrementing something and adding a value that just
happens to be one. Here you just happen to have chosen a step size of
one,
for whatever reason. Make that val += 1.0;

Huh?

In football the current rule is that teams get three points for a win, one
point for a draw, and zero for a loss.
So should code be

switch(result)
{
case WIN: points += 3;
break;
case DRAW: points++;
break;
case LOSS:
break;
}
?

The answer is no. The one point for a draw is totally arbitary. It might be
changed next season to two points for a draw if it is felt that the win
bonus is too high, or they could decide to give no points for a draw and a
negative for a loss, to make position independent of games played.
So it should be

case DRAW: points += 1;
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[santosh]

Malcolm McLean wrote:

>
"Army1987" <ar******@NOSPAM.itwrote in message

>>Misuse of increment operator. Not a bug, but poor style. There is a
difference between incrementing something and adding a value that
just happens to be one. Here you just happen to have chosen a step
size of one,
for whatever reason. Make that val += 1.0;

Huh?

In football the current rule is that teams get three points for a win,
one point for a draw, and zero for a loss.
So should code be

switch(result)
{
case WIN: points += 3;
break;
case DRAW: points++;
break;
case LOSS:
break;
}
?

The answer is no. The one point for a draw is totally arbitary. It
might be changed next season to two points for a draw if it is felt
that the win bonus is too high, or they could decide to give no points
for a draw and a negative for a loss, to make position independent of
games played. So it should be

case DRAW: points += 1;

Really! Instead of editing one character you'll be deleting one
character and adding two more. Is this really an important issue?

[Richard Heathfield]

santosh said:

Malcolm McLean wrote:
So [points++] should be

>>
case DRAW: points += 1;

Really! Instead of editing one character you'll be deleting one
character and adding two more. Is this really an important issue?

Yes, but really you shouldn't have to change the code *at all*. So it ought
to read:

case DRAW: points += points_per_draw;

where points_per_draw is read from file at the beginning of the program.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Philip Potter]

Richard Heathfield wrote:

santosh said:

>Malcolm McLean wrote:
So [points++] should be

>>case DRAW: points += 1;

Really! Instead of editing one character you'll be deleting one
character and adding two more. Is this really an important issue?

Yes, but really you shouldn't have to change the code *at all*. So it ought
to read:

case DRAW: points += points_per_draw;

where points_per_draw is read from file at the beginning of the program.

I can't tell if your serious or not. Please tell me you're not!

Phil

--
Philip Potter pgp <atdoc.ic.ac.uk

[Flash Gordon]

Philip Potter wrote, On 07/10/07 17:28:

Richard Heathfield wrote:

>santosh said:

>>Malcolm McLean wrote:
So [points++] should be
case DRAW: points += 1;
Really! Instead of editing one character you'll be deleting one
character and adding two more. Is this really an important issue?

Yes, but really you shouldn't have to change the code *at all*. So it
ought to read:

case DRAW: points += points_per_draw;

where points_per_draw is read from file at the beginning of the program.

I can't tell if your serious or not. Please tell me you're not!

Well, if you don't want it as a run-time configuration parameter you
could make it
case DRAW: points += POINTS_PER_DRAW;
and use a macro (or enum) to define it.

:-)
--
Flash Gordon

[Richard Heathfield]

Philip Potter said:

Richard Heathfield wrote:

<snip>

>So yes, I'm perfectly serious - if in doubt, read in configuration
information from file, rather than hard-code it into the program.

I'm not so sure about this.

At least you now realise that I had a serious point, which means we can
debate meaningfully. (Without mutual respect, there can be no real debate
- merely, er, points-scoring.)

Yes, football league scoring systems might
change; but it's not a common occurrence (as you say, the last time it
happened was in 1981, and the time before that was... before the modern
computer).

No, 1981 seems to have been the /first/ time it happened. The following
year, Israel changed their points rules to follow England's lead (why they
should want to adopt such a silly system is beyond me, but there ya go).
The next year, it was New Zealand's turn. In 1987,... well, let's just say
that in at least nine of the last twenty-seven years, some country or
other, somewhere in the world, has changed their football league points
system.

Yes, having to replace software is bad and costly, but your
customers will share some of that cost if you sell the upgrade.

If you write it properly to start with, you don't need an upgrade.
Customers are there to be served, not fleeced.

The other side of this is, where do we stop? Perhaps the football league
will introduce a new type of victory, a "tentative victory", where one
team was winning at half time but the score was equalised by the end,
the team that was winning at half time scores two points.

Yes, I understand your point. We can't cater for every possibility. But we
can cater for obviosities (if I may coin such a word). Number of points
for a win, number of teams in each division, team names, number of teams
promoted/demoted at the end of a season - all these things can, and
should, be configurable.

I think worsethanfailure.com explained the phenomenon of "soft-coding"
well here:
http://worsethanfailure.com/Articles/Soft_Coding.aspx

They have a point. Nevertheless, so do I. Fifteen-all, n'est-ce-pas?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Malcolm McLean]

"Philip Potter" <pg*@see.sig.invalidwrote in message

>
I'm not so sure about this. Yes, football league scoring systems might
change; but it's not a common occurrence (as you say, the last time it
happened was in 1981, and the time before that was... before the modern
computer). Yes, having to replace software is bad and costly, but your
customers will share some of that cost if you sell the upgrade.

The other side of this is, where do we stop? Perhaps the football league
will introduce a new type of victory, a "tentative victory", where one
team was winning at half time but the score was equalised by the end, the
team that was winning at half time scores two points. Do we code to allow
for that occurence? If we do, eventually what was the "configuration file"
becomes the application logic itself!

I think worsethanfailure.com explained the phenomenon of "soft-coding"
well here:
http://worsethanfailure.com/Articles/Soft_Coding.aspx

Good article.
However there is nothing wrong with a hierarchy of programming layers.
That's exactly what BASICdraw does. The graphical display is done in C, the
manipulation in Basic. Typically in adventure type games there is also a
scripting language built in to handle the complex game logic, with all the
graphics done in C / C++.
The point is that "configure everything" is a classic bad option. It is
something that you always get demands to do - "make this program flexible",
that is to say, "make it do virtually anything I want, on my say so, and
easily". It would be easier just to hand them the complier.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

<snip>

The point is that "configure everything" is a classic bad option.

But nobody in this discussion has advocated it. It's a strawman argument.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Army1987]

On Sun, 07 Oct 2007 15:45:54 +0100, Malcolm McLean wrote:

>
"Army1987" <ar******@NOSPAM.itwrote in message

>>Misuse of increment operator. Not a bug, but poor style. There is a
difference between incrementing something and adding a value that just
happens to be one. Here you just happen to have chosen a step size of
one,
for whatever reason. Make that val += 1.0;

Huh?

In football the current rule is that teams get three points for a win, one
point for a draw, and zero for a loss.
So should code be

switch(result)
{
case WIN: points += 3;
break;
case DRAW: points++;
break;
case LOSS:
break;
}
?

The answer is no. The one point for a draw is totally arbitary. It might be
changed next season to two points for a draw if it is felt that the win
bonus is too high, or they could decide to give no points for a draw and a
negative for a loss, to make position independent of games played.
So it should be

case DRAW: points += 1;

Yes. And not affecting the score on loss is arbitrary, too, so it
should be
case LOSS:
points += 0;
break;
right?
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Army1987]

On Sun, 07 Oct 2007 17:09:38 +0000, Richard Heathfield wrote:

There are situations in which adding 1 is the natural thing to do. For
example, a loop: for(i = 0; i < len; i++)...

[ When it's just an arbitrary choice, use += ]

<ot>
Not entirely relevant, but I've noticed that on gcc -O3
result += (putc(ch, stream) != EOF);
generates more code than either
putc(ch, stream) != EOF && result++;
or
if (putc(ch, stream) != EOF) result++;
which generate identical code.
</ot>
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Philip Potter]

Richard Heathfield wrote:

Philip Potter said:

>Richard Heathfield wrote:

<snip>

>>So yes, I'm perfectly serious - if in doubt, read in configuration
information from file, rather than hard-code it into the program.

I'm not so sure about this.

At least you now realise that I had a serious point, which means we can
debate meaningfully. (Without mutual respect, there can be no real debate
- merely, er, points-scoring.)

If I have given the impression that I do not respect your opinion, then
I'm sorry.

[snip well-written and carefully considered reply]

As so often happens, we agree much more than we disagree. I think you're
probably right that in a commercial product, points for a win and points
for a draw should be configurable. I thought it was a clear-cut case for
hardcoding, but you've shown that it's not.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Malcolm McLean]

"Army1987" <ar******@NOSPAM.itwrote in message

>case DRAW: points += 1;

Yes. And not affecting the score on loss is arbitrary, too, so it
should be
case LOSS:
points += 0;
break;
right?

You've got a point there. However in English language terms, would you say
"on a loss we are adding nothing to your points score", or "on a loss, we
are not adding anything to your points score?". I'd say the latter, though
it is debateable.

What is not really open to dispute is "on a draw we are adding one to your
score". It wouldn't be "on a draw we are incrementing your score" or "on a
draw your score goes to the next level".

points += 0; can be defended.

Ultimately the purpose is to communicate the logic as clearly as possible to
the maintaining programmer. But there can't be cut and dried answers,
because people don't talk like that.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Army1987]

On Sun, 07 Oct 2007 22:00:01 +0100, Malcolm McLean wrote:

>
"Army1987" <ar******@NOSPAM.itwrote in message

>>case DRAW: points += 1;

Yes. And not affecting the score on loss is arbitrary, too, so it
should be
case LOSS:
points += 0;
break;
right?

You've got a point there. However in English language terms, would you say
"on a loss we are adding nothing to your points score", or "on a loss, we
are not adding anything to your points score?". I'd say the latter, though
it is debateable.

What on hell does that matter for?

What is not really open to dispute is "on a draw we are adding one to your
score". It wouldn't be "on a draw we are incrementing your score" or "on a
draw your score goes to the next level".

points += 0; can be defended.

Turn your sarcasm detector on.
Maybe points += POINTS_ON_LOSS would do that, but points += 0
would make me very perplexed.

Ultimately the purpose is to communicate the logic as clearly as possible to
the maintaining programmer. But there can't be cut and dried answers,
because people don't talk like that.

points += 1; is not any clearer than points++;, indeed a C
programmer won't even see the difference. If that is your
concern, use points += POINTS_ON_DRAW;.

So either do
#define POINTS_ON_WIN 3
#define POINTS_ON_DRAW 1
#define POINTS_ON_LOSS 0
enum outcome { LOSS, DRAW, WIN };
....
switch (result) {
case LOSS:
points += POINTS_ON_LOSS;
break;
case DRAW:
points += POINTS_ON_DRAW;
break;
case WIN:
points += POINTS_ON_WIN;
break;
}

even if I would do

enum outcome { LOSS, DRAW, WIN };
int scores[3] = { 0, 1, 3 };
....
points += scores[result];
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Serve Lau]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:_t******************************@bt.com...

>Yes, having to replace software is bad and costly, but your
customers will share some of that cost if you sell the upgrade.

If you write it properly to start with, you don't need an upgrade.
Customers are there to be served, not fleeced.

Storing the points in a file means users can hack it, you have to implement
error handling when the file or the score is not there and handle it
properly and when the value does actually change some programmer will have
to find where the points come from anyway. I dont see the point in going
through so much trouble, if the value changes the programmer can just as
well find out that here's the value taken and change it.

[Richard Heathfield]

Army1987 said:

On Sun, 07 Oct 2007 17:09:38 +0000, Richard Heathfield wrote:

>There are situations in which adding 1 is the natural thing to do. For
example, a loop: for(i = 0; i < len; i++)...

[ When it's just an arbitrary choice, use += ]

<ot>
Not entirely relevant, but I've noticed that on gcc -O3
result += (putc(ch, stream) != EOF);
generates more code than either
putc(ch, stream) != EOF && result++;
or
if (putc(ch, stream) != EOF) result++;
which generate identical code.
</ot>

Yes. I won't talk about the technical difference here, but the
philosophical difference is that (expr1 != expr2) is guaranteed to
evaluate either to 0 or to 1, so if(expr1 != expr2) obj++; is a perfectly
reasonable thing to do. You're counting successes, basically. When you're
counting, ++ is a perfectly sensible construct to use.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Malcolm McLean]

"Army1987" <ar******@NOSPAM.itwrote in message

>You've got a point there. However in English language terms, would you
say
"on a loss we are adding nothing to your points score", or "on a loss, we
are not adding anything to your points score?". I'd say the latter,
though
it is debateable.

What on hell does that matter for?

People think in English. Assuming a relatively non-mathematical algorithm,
such as a football league table, people will normally have an English
language version of what the program does in their minds. They then read the
code and mentally translate code to English.
So they say "a loss: what do we do?". Then either "on that we do nothing" or
"on that they get no points". If think the first is more natural, write
"LOSS: break;", if you think the second "LOSS: points += 0;". To be fair you
also need a comment becaue it is a no-op, and a person looking at it from
the programming angle may wonder what is going on. Probably it would be
better to use #defines.

>
points += 1; is not any clearer than points++;, indeed a C
programmer won't even see the difference. If that is your
concern, use points += POINTS_ON_DRAW;.

So either do
#define POINTS_ON_WIN 3
#define POINTS_ON_DRAW 1
#define POINTS_ON_LOSS 0
enum outcome { LOSS, DRAW, WIN };
...
switch (result) {
case LOSS:
points += POINTS_ON_LOSS;
break;
case DRAW:
points += POINTS_ON_DRAW;
break;
case WIN:
points += POINTS_ON_WIN;
break;
}

even if I would do

enum outcome { LOSS, DRAW, WIN };
int scores[3] = { 0, 1, 3 };
...
points += scores[result];

There's another point here. Is your symbol really necessary? #defines can
easily create undesireable dependencies between code modules. That's another
debate, of course - whether our imaginary football program would have such
problems isn't answerable.

However the OP was writing scratchcode where he seems to want to see how the
logarithm of a number varied with magnitude. So a #define STEP would have
been overkill.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Philip Potter said:

<snip>

If I have given the impression that I do not respect your opinion,

You have not generally given that impression - it was just in this one
thread.

then I'm sorry.

Ah, stuff it - it led to a useful discussion, did it not? So no harm done.

[snip well-written and carefully considered reply]

As so often happens, we agree much more than we disagree. I think you're
probably right that in a commercial product, points for a win and points
for a draw should be configurable. I thought it was a clear-cut case for
hardcoding, but you've shown that it's not.

The next time you think "Richard cannot possibly be serious", remember this
thread. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Serve Lau said:

<snip>

Storing the points in a file means users can hack it, you have to
implement error handling when the file or the score is not there and
handle it properly and when the value does actually change some
programmer will have to find where the points come from anyway.

Yes, that's right. It's called "programming".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Mark McIntyre]

On Sun, 07 Oct 2007 19:50:14 +0100, in comp.lang.c , Philip Potter
<pg*@see.sig.invalidwrote:

>Yes, having to replace software is bad and costly, but your
customers will share some of that cost if you sell the upgrade.

Hmm - so you're saying we should cut corners now, safe in the
knowledge that our customers will have to foot the bill for fixing it
later.... sounds familiar, I must say...

>The other side of this is, where do we stop?

Absolutely. This is a key element in good design - knowing when to
stop.

>I think worsethanfailure.com explained the phenomenon of "soft-coding"
well here:
http://worsethanfailure.com/Articles/Soft_Coding.aspx

Its an interesting read, but either written tongue-in-cheek or written
by someone with very little experience of enterprise-level software
development and who apparently never heard of databases.
--
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

[Flash Gordon]

Malcolm McLean wrote, On 07/10/07 22:47:

>
"Army1987" <ar******@NOSPAM.itwrote in message

>>You've got a point there. However in English language terms, would
you say
"on a loss we are adding nothing to your points score", or "on a
loss, we
are not adding anything to your points score?". I'd say the latter,
though
it is debateable.

What on hell does that matter for?

People think in English.

Jacob, care to comment on this? ;-)

I don't think about programs in English, I've no idea about other people.

Assuming a relatively non-mathematical
algorithm, such as a football league table, people will normally have an
English language version of what the program does in their minds.

I don't.

They
then read the code and mentally translate code to English.

I definitely don't do that.

So they say "a loss: what do we do?". Then either "on that we do
nothing" or "on that they get no points". If think the first is more
natural, write "LOSS: break;", if you think the second "LOSS: points +=
0;". To be fair you also need a comment becaue it is a no-op, and a
person looking at it from the programming angle may wonder what is going
on. Probably it would be better to use #defines.

>>
points += 1; is not any clearer than points++;, indeed a C
programmer won't even see the difference. If that is your
concern, use points += POINTS_ON_DRAW;.

So either do
#define POINTS_ON_WIN 3
#define POINTS_ON_DRAW 1
#define POINTS_ON_LOSS 0
enum outcome { LOSS, DRAW, WIN };
...
switch (result) {
case LOSS:
points += POINTS_ON_LOSS;
break;
case DRAW:
points += POINTS_ON_DRAW;
break;
case WIN:
points += POINTS_ON_WIN;
break;
}

even if I would do

enum outcome { LOSS, DRAW, WIN };
int scores[3] = { 0, 1, 3 };
...
points += scores[result];

There's another point here. Is your symbol really necessary? #defines

And there was you suggesting using #define would be a good idea only a
few lines ago!

can easily create undesireable dependencies between code modules.

I've only had them create *desirable* dependencies. I seriously cannot
see how you manage to get undesirable dependencies unless you miss-use
the symbols that have been defined.

That's
another debate, of course - whether our imaginary football program would
have such problems isn't answerable.

Unless you deliberately wrote your program to create such a problem I
can't see why it would.

However the OP was writing scratchcode where he seems to want to see how
the logarithm of a number varied with magnitude. So a #define STEP would
have been overkill.

Unless you want it to include the step size in its output, an not
unreasonable thing to do.
--
Flash Gordon

[Philip Potter]

Mark McIntyre wrote:

On Sun, 07 Oct 2007 19:50:14 +0100, in comp.lang.c , Philip Potter
<pg*@see.sig.invalidwrote:

>Yes, having to replace software is bad and costly, but your
customers will share some of that cost if you sell the upgrade.

Hmm - so you're saying we should cut corners now, safe in the
knowledge that our customers will have to foot the bill for fixing it
later.... sounds familiar, I must say...

It depends on whether you think this is cutting a corner or not. If your
goal is only the British market, say, then you know that the points
system is unlikely to change. As Richard pointed out, if you're
targetting many different leagues worldwide, then more adaptable
software is better because change is more likely.

>The other side of this is, where do we stop?

Absolutely. This is a key element in good design - knowing when to
stop.

Yes. Do we take account of chess leagues, where a win is 1 point and a
draw is half a point? It's not at all complex to build-in
future-proofing against fractional points, using fixed-point arithmetic,
but if the remit of the project is only British football leagues, then
it's more work than is required.

I accept now, having heard RH's arguments, that soft-coding points for
win, draw and loss is probably the Right Thing. But as with so many
things, it really depends on the project requirements.

>I think worsethanfailure.com explained the phenomenon of "soft-coding"
well here:
http://worsethanfailure.com/Articles/Soft_Coding.aspx

Its an interesting read, but either written tongue-in-cheek or written
by someone with very little experience of enterprise-level software
development and who apparently never heard of databases.

Well I can tell you that it is not tongue-in-cheek, and the author does
have experience of enterprise-level development and has heard of databases.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Army1987]

On Sun, 07 Oct 2007 22:47:19 +0100, Malcolm McLean wrote:

>
"Army1987" <ar******@NOSPAM.itwrote in message
People think in English.

Wow. Really?
Maybe it'd be more correct to state "People think in whatever
language they're speaking/writing in, unless they're not familiar
enough with it, in which case they think in their native language."
YMMV.

Assuming a relatively non-mathematical algorithm,
such as a football league table, people will normally have an English
language version of what the program does in their minds. They then read the
code and mentally translate code to English.

(Try explaining constructs such as while(*s++ = *t++) in English...)

So they say "a loss: what do we do?". Then either "on that we do
nothing" or "on that they get no points". If think the first is more
natural, write "LOSS: break;", if you think the second "LOSS: points +=
0;".

I have another idea. If the zero is something which doesn't make sense to
ever change, there is no point to add `points += 0;`, whereas otherwise
there is no point to add that octal (sic!) constant directly in that place
in the preprocessing source file, when a macro would do it. In either
case, a literal `points += 0` doesn't make sense. (IMO - YMMV)

To be fair you
also need a comment becaue it is a no-op, and a person looking at it from
the programming angle may wonder what is going on. Probably it would be
better to use #defines.

That was the point.

>>
points += 1; is not any clearer than points++;, indeed a C
programmer won't even see the difference. If that is your
concern, use points += POINTS_ON_DRAW;.

So either do
#define POINTS_ON_WIN 3
#define POINTS_ON_DRAW 1
#define POINTS_ON_LOSS 0
enum outcome { LOSS, DRAW, WIN };
...

[snip]

>even if I would do

enum outcome { LOSS, DRAW, WIN };
int scores[3] = { 0, 1, 3 };
...
points += scores[result];

There's another point here. Is your symbol really necessary? #defines can
easily create undesireable dependencies between code modules.

Huh? You can have #defines and their expansion in the same file,
putting them in headers isn't mandatory.

That's another
debate, of course - whether our imaginary football program would have such
problems isn't answerable.

However the OP was writing scratchcode where he seems to want to see how the
logarithm of a number varied with magnitude. So a #define STEP would have
been overkill.

And val += 1.0 isn't a great improvement over val++. He was just
progressing through integers, declaring val as a (long) double
to remove useless conversion when passing it lo log (or logl).
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Richard Bos]

Flash Gordon <sp**@flash-gordon.me.ukwrote:

Malcolm McLean wrote, On 07/10/07 22:47:

"Army1987" <ar******@NOSPAM.itwrote in message

>You've got a point there. However in English language terms, would
you say "on a loss we are adding nothing to your points score", or "on a
loss, we are not adding anything to your points score?". I'd say the latter,
though it is debateable.
What on hell does that matter for?

People think in English.

Jacob, care to comment on this? ;-)

I dunno about our local Frenchman (and our local Italian might have an
opinion, as well), but...

I don't think about programs in English, I've no idea about other people.

....I do.

Richard

[santosh]

Richard Bos wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote:

>Malcolm McLean wrote, On 07/10/07 22:47:

>
"Army1987" <ar******@NOSPAM.itwrote in message
You've got a point there. However in English language terms,
would you say "on a loss we are adding nothing to your points
score", or "on a loss, we are not adding anything to your points
score?". I'd say the latter, though it is debateable.
What on hell does that matter for?

People think in English.

Jacob, care to comment on this? ;-)

I dunno about our local Frenchman (and our local Italian might have an
opinion, as well), but...

>I don't think about programs in English, I've no idea about other
people.

...I do.

I do too. Since C only allows English as it's source character set, it's
usually natural to think about the program in English.

[Ben Pfaff]

santosh <sa*********@gmail.comwrites:

Since C only allows English as it's source character set, [...]

C99 corrected this problem, for what it's worth.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell

[Flash Gordon]

Richard Bos wrote, On 08/10/07 11:48:

Flash Gordon <sp**@flash-gordon.me.ukwrote:

>Malcolm McLean wrote, On 07/10/07 22:47:

>>"Army1987" <ar******@NOSPAM.itwrote in message
You've got a point there. However in English language terms, would
you say "on a loss we are adding nothing to your points score", or "on a
loss, we are not adding anything to your points score?". I'd say the latter,
though it is debateable.
What on hell does that matter for?

People think in English.

Jacob, care to comment on this? ;-)

I dunno about our local Frenchman (and our local Italian might have an
opinion, as well), but...

Many years ago I had the German version of a Basic interpreter. Having
all the comments and variable names in the examples in German made it
somewhat "interesting" for me.

>I don't think about programs in English, I've no idea about other people.

...I do.

Just in case anyone hasn't noticed, I am in fact English. I just don't
think about programs in words a lot of the time.
--
Flash Gordon

[Richard Heathfield]

Flash Gordon said:

<snip>

Many years ago I had the German version of a Basic interpreter. Having
all the comments and variable names in the examples in German made it
somewhat "interesting" for me.

GFA Basic, by any chance?

I had the GFA interpreter and the compiler. There were interesting
differences between the two. For example, 0/0 would generate a
divide-by-zero error in the interpreter, but the compiler optimised *all*
instances of n/n (including 0/0) into 1 - a classic example of undefined
behaviour not always doing what you expect!

<snip>

Just in case anyone hasn't noticed, I am in fact English.

And there was me thinking you were a Yale grad and a member of the World
Space Council. :-)

I just don't think about programs in words a lot of the time.

Right. I tend to think about programs in terms of data flows, which can
sometimes be rather tricky to express in words. In fact, some C concepts
can be difficult to express unambiguously in English. For example, I have
occasionally struggled to find an unambiguous way of expressing the idea
of passing a pointer to a function - by which I mean having a pointer
value, and passing that value to a function as one of its arguments (or
maybe I mean having a function pointer value, and passing *that*!).

Written in C, the difference becomes obvious. In English, one must either
qualify or risk being misunderstood.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Mark McIntyre]

On Mon, 08 Oct 2007 08:43:22 +0100, in comp.lang.c , Philip Potter
<pg*@see.sig.invalidwrote:

(this is heading towards comp.programming... my final comment in this
thread below).

(I wrote)

>Absolutely. This is a key element in good design - knowing when to
stop.

Yes. Do we take account of chess leagues, where a win is 1 point and a
draw is half a point?

I suspect two things help you decide this - experience and business
requirements.

>Well I can tell you that it is not tongue-in-cheek, and the author does
have experience of enterprise-level development and has heard of databases.

Then i'm forced to assume he has a monomania..... :-(
--
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

[Flash Gordon]

Richard Heathfield wrote, On 08/10/07 22:03:

Flash Gordon said:

<snip>

>Many years ago I had the German version of a Basic interpreter. Having
all the comments and variable names in the examples in German made it
somewhat "interesting" for me.

GFA Basic, by any chance?

Sounds about right. On the Atari ST.

I had the GFA interpreter and the compiler. There were interesting
differences between the two. For example, 0/0 would generate a
divide-by-zero error in the interpreter, but the compiler optimised *all*
instances of n/n (including 0/0) into 1 - a classic example of undefined
behaviour not always doing what you expect!

Indeed.

Bringing this back on topic. I'm sure you can find at least one C
compiler doing each of the following...
optimising all instances of n/n (including 0/0) to 1
producing a diagnostic on all instances of n/0
producing a run-time exception on all instances of n/0

There are probably other outcomes that occurs as well.

>Just in case anyone hasn't noticed, I am in fact English.

And there was me thinking you were a Yale grad and a member of the World
Space Council. :-)

>I just don't think about programs in words a lot of the time.

Right. I tend to think about programs in terms of data flows, which can
sometimes be rather tricky to express in words.

I often think about the shape of the solution and write code to fit in
to it. If the purpose of the SW is to move data (I have worked on comms
processors of a sort) then I think about where the data has to flow.
Sometimes in all of this I think about objects.

In fact, some C concepts
can be difficult to express unambiguously in English.

Yup.

For example, I have
occasionally struggled to find an unambiguous way of expressing the idea
of passing a pointer to a function - by which I mean having a pointer
value, and passing that value to a function as one of its arguments (or
maybe I mean having a function pointer value, and passing *that*!).

All seem perfectly clear to me :-)

Written in C, the difference becomes obvious. In English, one must either
qualify or risk being misunderstood.

Well, a lot of the people I have had to deal with have done a lot of
assembler in the past, so they are perfectly happy with pointers :-)
--
Flash Gordon

[Serve Lau]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:CP******************************@bt.com...

Serve Lau said:

<snip>

>Storing the points in a file means users can hack it, you have to
implement error handling when the file or the score is not there and
handle it properly and when the value does actually change some
programmer will have to find where the points come from anyway.

Yes, that's right. It's called "programming".

Cranking out code for every little thing that one can come up with is not
programming anymore. There can be easily hundreds if not thousands of
variables in a program that one could possibly make user configurable in
some way. Better work smarter instead of harder so you actually get some
work done. For instance, you could have a module which has all rules like
the points system stored, so one immediately knows where to look for if a
rule changes someday.

[Serve Lau]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:88*********************@bt.com...

Malcolm McLean said:

<snip>

>The point is that "configure everything" is a classic bad option.

But nobody in this discussion has advocated it. It's a strawman argument.

Oh, I sure got the impression that you did because you wanted to configure
something like how many points a football team gets when winning a match. If
you already want to configure this then surely you'll want to configure all
other soccer rules that could maybe change someday
But forget the other post then I talked about, since you dont want to
configure everything

[Richard Heathfield]

Serve Lau said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:88*********************@bt.com...

>Malcolm McLean said:

<snip>

>>The point is that "configure everything" is a classic bad option.

But nobody in this discussion has advocated it. It's a strawman
argument.

Oh, I sure got the impression that you did because you wanted to
configure something like how many points a football team gets when
winning a match.

If you believe that "something" and "everything" mean the same thing,
presumably you also believe that *all* words mean the same thing, in which
case foo foo foo foo foo foo foo foo, foo foo foo "foo foo" foo foo; foo
foo foo foo foo, foo foo foo, foo foo foo foo foo. Foo foo foo, foo foo
foo foo foo, /foo/ foo foo foo, foo foo foo. Foo?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jaysome]

On Tue, 09 Oct 2007 06:09:26 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>Serve Lau said:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:88*********************@bt.com...

>>Malcolm McLean said:

<snip>

The point is that "configure everything" is a classic bad option.

But nobody in this discussion has advocated it. It's a strawman
argument.

Oh, I sure got the impression that you did because you wanted to
configure something like how many points a football team gets when
winning a match.

If you believe that "something" and "everything" mean the same thing,
presumably you also believe that *all* words mean the same thing, in which
case foo foo foo foo foo foo foo foo, foo foo foo "foo foo" foo foo; foo
foo foo foo foo, foo foo foo, foo foo foo foo foo. Foo foo foo, foo foo
foo foo foo, /foo/ foo foo foo, foo foo foo. Foo?

Is Richard losing it?

That last "Foo" should have been a "Bar", IMHO.

Regards
--
jay

[Serve Lau]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:uN******************************@bt.com...

>Oh, I sure got the impression that you did because you wanted to
configure something like how many points a football team gets when
winning a match.

If you believe that "something" and "everything" mean the same thing,
presumably you also believe that *all* words mean the same thing, in which
case foo foo foo foo foo foo foo foo, foo foo foo "foo foo" foo foo; foo
foo foo foo foo, foo foo foo, foo foo foo foo foo. Foo foo foo, foo foo
foo foo foo, /foo/ foo foo foo, foo foo foo. Foo?

I was expecting something childish but this is epic ^^

[Default User]

jaysome wrote:

On Tue, 09 Oct 2007 06:09:26 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

Serve Lau said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:88*********************@bt.com...
Malcolm McLean said:

<snip>

The point is that "configure everything" is a classic bad option.

But nobody in this discussion has advocated it. It's a strawman
argument.

Oh, I sure got the impression that you did because you wanted to
configure something like how many points a football team gets when
winning a match.

If you believe that "something" and "everything" mean the same
thing, presumably you also believe that all words mean the same
thing, in which case foo foo foo foo foo foo foo foo, foo foo foo
"foo foo" foo foo; foo foo foo foo foo, foo foo foo, foo foo foo
foo foo. Foo foo foo, foo foo foo foo foo, foo foo foo foo, foo foo
foo. Foo?

Is Richard losing it?

That last "Foo" should have been a "Bar", IMHO.

Marklar.


Brian

[Malcolm McLean]

"Serve Lau" <as**@n.tkwrote in message news:feei67

>
Cranking out code for every little thing that one can come up with is not
programming anymore. There can be easily hundreds if not thousands of
variables in a program that one could possibly make user configurable in
some way. Better work smarter instead of harder so you actually get some
work done. For instance, you could have a module which has all rules like
the points system stored, so one immediately knows where to look for if a
rule changes someday.

The problem is you always get curve balls. You write a nice, modular "score"
function. Then you display the league. Then the designer comes up to you and
says "can we add the number of points the team can possibly score, from
their remaining games?". It's a perfectly reasonable request that the
computer ought to be able to handle. But it means hacking into you nice
modular "score" function to extract the three points for a win directly.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Mark McIntyre]

On Tue, 9 Oct 2007 18:06:41 +0200, in comp.lang.c , "Serve Lau"
<as**@n.tkwrote:

>"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:uN******************************@bt.com...

>>Oh, I sure got the impression that you did because you wanted to
configure something like how many points a football team gets when
winning a match.

If you believe that "something" and "everything" mean the same thing,
presumably you also believe that *all* words mean the same thing,

I was expecting something childish but this is epic ^^

Perhaps you need to avoid making silly statements in that case?
--
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

[Chris Dollin]

Richard Heathfield wrote:

Serve Lau said:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:88*********************@bt.com...

>>Malcolm McLean said:

<snip>

The point is that "configure everything" is a classic bad option.

But nobody in this discussion has advocated it. It's a strawman
argument.

Oh, I sure got the impression that you did because you wanted to
configure something like how many points a football team gets when
winning a match.

If you believe that "something" and "everything" mean the same thing,
presumably you also believe that *all* words mean the same thing, in which
case foo foo foo foo foo foo foo foo, foo foo foo "foo foo" foo foo; foo
foo foo foo foo, foo foo foo, foo foo foo foo foo. Foo foo foo, foo foo
foo foo foo, /foo/ foo foo foo, foo foo foo. Foo?

Actually, those should be "mun".

--
Chris "remembering Sheckley" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Richard Bos]

santosh <sa*********@gmail.comwrote:

Richard Bos wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote:

Malcolm McLean wrote, On 07/10/07 22:47:

"Army1987" <ar******@NOSPAM.itwrote in message
You've got a point there. However in English language terms,
would you say "on a loss we are adding nothing to your points
score", or "on a loss, we are not adding anything to your points
score?". I'd say the latter, though it is debateable.
What on hell does that matter for?

People think in English.

Jacob, care to comment on this? ;-)

I dunno about our local Frenchman (and our local Italian might have an
opinion, as well), but...

I don't think about programs in English, I've no idea about other
people.

...I do.

I do too. Since C only allows English as it's source character set, it's
usually natural to think about the program in English.

It's not that, in my case. I could easily use all Dutch identifiers, if
I wanted to. But all good programming literature is in English, nearly
all the discussions I have about programming are in English, and nearly
all code I read has comments and identifiers in English, so when I
program, my mind switches to English.

Richard

[¬a\\/b]

In data Wed, 10 Oct 2007 11:57:15 GMT, Richard Bos scrisse:

>santosh <sa*********@gmail.comwrote:

>Richard Bos wrote:

Flash Gordon <sp**@flash-gordon.me.ukwrote:
Malcolm McLean wrote, On 07/10/07 22:47:
"Army1987" <ar******@NOSPAM.itwrote in message
You've got a point there. However in English language terms,
would you say "on a loss we are adding nothing to your points
score", or "on a loss, we are not adding anything to your points
score?". I'd say the latter, though it is debateable.
What on hell does that matter for?

People think in English.

Jacob, care to comment on this? ;-)

I dunno about our local Frenchman (and our local Italian might have an
opinion, as well), but...

I don't think about programs in English, I've no idea about other
people.

...I do.

I do too. Since C only allows English as it's source character set, it's
usually natural to think about the program in English.

It's not that, in my case. I could easily use all Dutch identifiers, if
I wanted to. But all good programming literature is in English, nearly
all the discussions I have about programming are in English, and nearly
all code I read has comments and identifiers in English, so when I
program, my mind switches to English.
Richard

for what that can count, when programming i see what each operation
makes

i don't speak, see