Any idea why this program is not generating an output ?

[lector]

#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

int main(void)
{
double theta, phi, sinth;
double count;
double incr;
double s;

s = 180/M_PI; /* converting to radians */
incr = 0.5;
theta = 0;

for(theta = incr; theta < 180; theta += incr)
sinth = sin(s *theta);
for(phi = 0; phi < 360 ; phi += incr/ sinth)
count ++;
printf("%f", count);
return 0;
}

[Peter Nilsson]

lector wrote:
[subject: Any idea why this program is not generating an output ?]

#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

int main(void)
{
double theta, phi, sinth;
double count;

lector.c:8: warning: 'count' may be used uninitialized in this
function

double incr;
double s;

s = 180/M_PI; /* converting to radians */

If you _divide_ by s, perhaps.

incr = 0.5;
theta = 0;

for(theta = incr; theta < 180; theta += incr)
sinth = sin(s *theta);

Try adding...

printf("%f\n", sinth);

Run it again, then ask yourself why it doesn't print.

for(phi = 0; phi < 360 ; phi += incr/ sinth)
count ++;
printf("%f", count);
return 0;
}

--
Peter

[William Pursell]

On 8 Apr, 06:53, lector <[e-mail]:

#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

Why redefine M_PI? In my math.h, it is given a value
of 3.14159265358979323846. You lose a lot of precision
by redifining it, and don't gain anything. I'm surprised
you don't get a compiler warning.

[lector]

On Apr 8, 11:02 am, Peter Nilsson <[e-mail]:

lector wrote:

[subject: Any idea why this program is not generating an output ?]

#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

int main(void)
{
double theta, phi, sinth;
double count;

lector.c:8: warning: 'count' may be used uninitialized in this
function

double incr;
double s;

s = 180/M_PI; /* converting to radians */

If you _divide_ by s, perhaps.

incr = 0.5;
theta = 0;

for(theta = incr; theta < 180; theta += incr)
sinth = sin(s *theta);

Try adding...

printf("%f\n", sinth);

Run it again, then ask yourself why it doesn't print.

for(phi = 0; phi < 360 ; phi += incr/ sinth)
count ++;
printf("%f", count);
return 0;
}

*modified*

#include <stdio.h>
#include <math.h>
#define M_PI 3.14159
int main(void)
{
double theta, phi, sinth ;
double count;
double incr;
double s;

s = 180/M_PI;
incr = 0.05;
theta = 0;
count = 0;

for(theta = incr; theta < 180; theta += incr)
{ sinth = sin(theta/s); printf("%f\n",sinth);
for(phi = 0; phi < 360 ; phi += incr/ sinth)
count ++;
}
printf("%f", count);
return 0;
}
Runs perfectly well. Thanks.

[lector]

On Apr 8, 11:09 am, William Pursell <[e-mail]:

On 8 Apr, 06:53, lector <[e-mail]:

#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

Why redefine M_PI? In my math.h, it is given a value
of 3.14159265358979323846. You lose a lot of precision
by redifining it, and don't gain anything. I'm surprised
you don't get a compiler warning.

well M_PI is not defined in my copy of compiler(MiracleC)

[lector]

On thing I'm surprised is that the sinth values are being printed only
till 6 places after decimal. I would like to know why this happens
even though I'm using doubles which offer 10 places after decimal
point.

[Richard Heathfield]

William Pursell said:

On 8 Apr, 06:53, lector <[e-mail]:

>#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

Why redefine M_PI?

Where is he doing that?

In my math.h, it is given a value of 3.14159265358979323846.

Then your implementation doesn't conform to ISO/IEC 9899. Implementations
are *not allowed* to define M_PI in <math.h>

You lose a lot of precision
by redifining it, and don't gain anything. I'm surprised
you don't get a compiler warning.

I'd be astounded if any C compiler[1] *does* give a warning for that.
[1] ...for the usual, extra-picky, definition of "C compiler".

--
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

[Joachim Schmitz]

Richard Heathfield wrote:

William Pursell said:

>On 8 Apr, 06:53, lector <[e-mail]:

>>#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

Why redefine M_PI?

Where is he doing that?

>In my math.h, it is given a value of 3.14159265358979323846.

Then your implementation doesn't conform to ISO/IEC 9899.
Implementations are *not allowed* to define M_PI in <math.h>

Chapter and verse?

Hmm, I see in 'my' implementation it is #define'd inside #ifdef
_XOPEN_SOURCE ... #endif, so it most probably is POSIX

Bye, Jojo

[Richard Heathfield]

Joachim Schmitz said:

Richard Heathfield wrote:

>William Pursell said:

>>On 8 Apr, 06:53, lector <[e-mail]:
#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

Why redefine M_PI?

Where is he doing that?

>>In my math.h, it is given a value of 3.14159265358979323846.

Then your implementation doesn't conform to ISO/IEC 9899.
Implementations are *not allowed* to define M_PI in <math.h>

Chapter and verse?

We start off by observing that M_PI doesn't appear anywhere in the
Standard. Therefore, if implementations provide it at all, it is as an
extension.

We next observe that the following program is strictly conforming:

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

#ifndef M_PI
#define M_PI 2.71828
#endif

int main(void)
{
printf("%f\n", pow(M_PI, M_PI));
return 0;
}

Finally, we read 1.7 Compliance, which states:

"A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program."

Hmm, I see in 'my' implementation it is #define'd inside #ifdef
_XOPEN_SOURCE ... #endif, so it most probably is POSIX

That's as may or may not be - but it certainly isn't C (in the sense of
being part of the language definition).

--
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

[Joachim Schmitz]

Richard Heathfield wrote:

Joachim Schmitz said:

>Richard Heathfield wrote:

>>William Pursell said:

On 8 Apr, 06:53, lector <[e-mail]:
#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

Why redefine M_PI?

Where is he doing that?

In my math.h, it is given a value of 3.14159265358979323846.

Then your implementation doesn't conform to ISO/IEC 9899.
Implementations are *not allowed* to define M_PI in <math.h>

Chapter and verse?

We start off by observing that M_PI doesn't appear anywhere in the
Standard. Therefore, if implementations provide it at all, it is as an
extension.

So it is not forbidden as you stated.

We next observe that the following program is strictly conforming:

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

#ifndef M_PI
#define M_PI 2.71828
#endif

BTW: the OP didn't have that #ifndef guard

int main(void)
{
printf("%f\n", pow(M_PI, M_PI));

%f may result in implementation defined behavoir for inf and NaN, as far as
I can see pow() can return NaN or inf, so such a program can be conforming,
but not strictly conforming

return 0;
}

Finally, we read 1.7 Compliance, which states:

"A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program."

See above.

>Hmm, I see in 'my' implementation it is #define'd inside #ifdef
_XOPEN_SOURCE ... #endif, so it most probably is POSIX

That's as may or may not be - but it certainly isn't C (in the sense
of being part of the language definition).

Bye, Jojo

[Richard Heathfield]

Joachim Schmitz said:

Richard Heathfield wrote:

>Joachim Schmitz said:

>>Richard Heathfield wrote:
William Pursell said:

On 8 Apr, 06:53, lector <[e-mail]:
>#include <stdio.h>
>#include <math.h>
>#define M_PI 3.14159
>
Why redefine M_PI?

Where is he doing that?

In my math.h, it is given a value of 3.14159265358979323846.

Then your implementation doesn't conform to ISO/IEC 9899.
Implementations are *not allowed* to define M_PI in <math.h>
Chapter and verse?

We start off by observing that M_PI doesn't appear anywhere in the
Standard. Therefore, if implementations provide it at all, it is as an
extension.

So it is not forbidden as you stated.

Yes, it is. Read my reply again.

>We next observe that the following program is strictly conforming:

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

#ifndef M_PI
#define M_PI 2.71828
#endif

BTW: the OP didn't have that #ifndef guard

The Standard forbids extensions to break *ANY* strictly conforming program.

>int main(void)
{
printf("%f\n", pow(M_PI, M_PI));

%f may result in implementation defined behavoir for inf and NaN, as far
as I can see pow() can return NaN or inf, so such a program can be
conforming, but not strictly conforming

I disagree, since 2.71828 to the power 2.71828 is well within the range of
a double (it's about 15). Still, if it floats your boat, try this:

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

#ifndef M_PI
#define M_PI "Hello world"
#endif

int main(void)
{
printf("%s (oh yes, let's use math.h: %f)\n", M_PI, fabs(0.0));
return 0;
}

<snip>

--
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

[Doug Miller]

In article <24**********************************@s39g2000prd. googlegroups.com>, lector <ha***************@gmail.comwrote:

>#include <stdio.h>
#include <math.h>
#define M_PI 3.14159

int main(void)
{
double theta, phi, sinth;
double count;
double incr;
double s;

s = 180/M_PI; /* converting to radians */

s = 57.296

incr = 0.5;
theta = 0;

for(theta = incr; theta < 180; theta += incr)

Probably you meant to enclose the next three lines in a { } pair.
Since you didn't, the first for command executes this statement

sinth = sin(s *theta);

three hundred sixty times, and does nothing else. When the next for is
executed, the value of sinth is *always* what it had when it left the previous
loop, i.e. sin ( s * 179.5 ) = sin (57.296 * 179.5) = sin (10284.6 RADIANS) =
NEGATIVE 0.8267.

for(phi = 0; phi < 360 ; phi += incr/ sinth)
count ++;

Since sinth is always less than zero, incr/sinth is likewise always less than
zero; thus, in this loop you're *subtracting* from phi instead of adding to
it, and the loop never terminates.

And since the loop never terminates, this statement

printf("%f", count);

is never executed.

return 0;
}

[Barry Schwarz]

On Mon, 7 Apr 2008 23:18:03 -0700 (PDT), lector
<ha***************@gmail.comwrote:

snip 45 lines of obsolete code

Since you are providing a new version, please trim the old one out of
your post. It is no longer germane to the conversation.

>
*modified*

#include <stdio.h>
#include <math.h>
#define M_PI 3.14159
int main(void)
{
double theta, phi, sinth ;
double count;
double incr;
double s;

s = 180/M_PI;
incr = 0.05;
theta = 0;
count = 0;

for(theta = incr; theta < 180; theta += incr)
{ sinth = sin(theta/s); printf("%f\n",sinth);
for(phi = 0; phi < 360 ; phi += incr/ sinth)
count ++;
}

You original problem was the missing braces. However, it was
compounded by this atrocious style of indenting which led you to
believe that all three statements where in the range of the for loop.
Learning to indent consistently is one of the easiest ways to make
your code more readable. It will pay very handsome dividends when you
write larger programs.

> printf("%f", count);
return 0;
}
Runs perfectly well. Thanks.

Obviously not based on your next post. Look up the modifiers that are
supported by %f,
Remove del for email

[David Thompson]

On Tue, 08 Apr 2008 06:43:55 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

William Pursell said:

<snip: M_PI>

In my math.h, it is given a value of 3.14159265358979323846.

Then your implementation doesn't conform to ISO/IEC 9899. Implementations
are *not allowed* to define M_PI in <math.h>

True. (Or any other standard header, for that matter.)

You lose a lot of precision
by redifining it, and don't gain anything. I'm surprised
you don't get a compiler warning.

I'd be astounded if any C compiler[1] *does* give a warning for that.

[1] ...for the usual, extra-picky, definition of "C compiler".

I'm not sure exactly what 'that' you mean. If it were in fact
re-#define'd, as PP thought (mistakenly), a diagnostic would be
required since it would be nonidentical. 6.10.3p2 (constraint)

- formerly david.thompson1 || achar(64) || worldnet.att.net

[Richard Heathfield]

David Thompson said:

On Tue, 08 Apr 2008 06:43:55 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>William Pursell said:

<snip>

>

You lose a lot of precision
by redifining it, and don't gain anything. I'm surprised
you don't get a compiler warning.

I'd be astounded if any C compiler[1] *does* give a warning for that.

[1] ...for the usual, extra-picky, definition of "C compiler".

I'm not sure exactly what 'that' you mean. If it were in fact
re-#define'd, as PP thought (mistakenly), a diagnostic would be
required since it would be nonidentical. 6.10.3p2 (constraint)

The 'that' I meant was something along these lines:

#include <math.h>

#define M_PI 3.14

My point was that, since implementations are forbidden from #defining M_PI,
they have no grounds for complaint.

--
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

[CBFalconer]

Richard Heathfield wrote:

>

.... snip ...

>
#include <math.h>

#define M_PI 3.14

My point was that, since implementations are forbidden from
#defining M_PI, they have no grounds for complaint.

I can find no reference to 'M_PI' in any C standard I have
available. Please give a specific reference.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 21 Apr 2008 19:23:44 -0400, CBFalconer wrote:

Richard Heathfield wrote:

>>

... snip ...

>>
#include <math.h>

#define M_PI 3.14

My point was that, since implementations are forbidden from #defining
M_PI, they have no grounds for complaint.

I can find no reference to 'M_PI' in any C standard I have available.
Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99 7.1.3p2
requires. What makes you think implementations are allowed to define M_PI
just because it isn't explicitly forbidden by name in the standard?

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>>

... snip ...

>>
#include <math.h>

#define M_PI 3.14

My point was that, since implementations are forbidden from
#defining M_PI, they have no grounds for complaint.

I can find no reference to 'M_PI' in any C standard I have
available.

That is precisely my point. I find it incredible that you don't realise
this.

Please give a specific reference.

Harald has already done so, so I will simply add the reasoning:

1) the name is not reserved for the implementation;
2) a correct program may therefore contain a definition of M_PI;
3) an implementation must correctly translate a correct program;
4) an implementation could not guarantee this if it contained a definition
of M_PI in any standard header, as it could cause a clash with the
program's definition.

--
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

[Flash Gordon]

Harald van Dijk wrote, On 22/04/08 05:46:

On Mon, 21 Apr 2008 19:23:44 -0400, CBFalconer wrote:

>Richard Heathfield wrote:
... snip ...

>>#include <math.h>

#define M_PI 3.14

My point was that, since implementations are forbidden from #defining
M_PI, they have no grounds for complaint.

I can find no reference to 'M_PI' in any C standard I have available.
Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99 7.1.3p2
requires. What makes you think implementations are allowed to define M_PI
just because it isn't explicitly forbidden by name in the standard?

I'm sure it has been argued that an implementation defining M_PI can
affect the behaviour of a strictly conforming program and therefore
conforming implementations cannot define M_PI. I believe, for example,
the following is strictly conforming:

#define <math.h>
#define <stdio.h>

#ifdef M_PI
#error "The implementation defined M_PI"
#endif

int main(void)
{
puts("M_PI not defined");
return 0;
}
--
Flash Gordon

[vippstar]

On Apr 22, 10:29 am, Flash Gordon <[e-mail]:

Harald van D©¦k wrote, On 22/04/08 05:46:

On Mon, 21 Apr 2008 19:23:44 -0400, CBFalconer wrote:

Richard Heathfield wrote:
... snip ...
#include <math.h>

>#define M_PI 3.14

>My point was that, since implementations are forbidden from #defining
M_PI, they have no grounds for complaint.
I can find no reference to 'M_PI' in any C standard I have available.
Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99 7.1.3p2
requires. What makes you think implementations are allowed to define M_PI
just because it isn't explicitly forbidden by name in the standard?

I'm sure it has been argued that an implementation defining M_PI can
affect the behaviour of a strictly conforming program and therefore
conforming implementations cannot define M_PI. I believe, for example,
the following is strictly conforming:

Defining M_PI can break strictly conforming programs such as:
int main(void) { int M_PI = 0; return M_PI; }
M_PI is a name that belongs in the programmers namespace.
Question 1.29 explains the implementations namespace. <http://www.c-
faq.com/>

[CBFalconer]

Harald van D?k wrote:

CBFalconer wrote:

>Richard Heathfield wrote:

>>>

... snip ...

>>>
#include <math.h>

#define M_PI 3.14

My point was that, since implementations are forbidden from #defining
M_PI, they have no grounds for complaint.

I can find no reference to 'M_PI' in any C standard I have available.
Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99 7.1.3p2
requires. What makes you think implementations are allowed to define M_PI
just because it isn't explicitly forbidden by name in the standard?

But that is the point. M_PI is not reserved for the
implementation, therefore the application is perfectly free to
define it as desired.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Harald van D?k wrote:

>CBFalconer wrote:

>>Richard Heathfield wrote:

... snip ...

#include <math.h>

#define M_PI 3.14

My point was that, since implementations are forbidden from #defining
M_PI, they have no grounds for complaint.

I can find no reference to 'M_PI' in any C standard I have available.
Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99 7.1.3p2
requires. What makes you think implementations are allowed to define M_PI
just because it isn't explicitly forbidden by name in the standard?

But that is the point. M_PI is not reserved for the
implementation, therefore the application is perfectly free to
define it as desired.

Yes, of course. That's everybody else's point too, and I don't
believe anyone has disputed it. Your statement that there's no
reference to M_PI in the C standard is obviously true, but added
nothing to the discussion.

Did you have a point that hasn't already been made? Do you disagree
with anything that's been said so far in any followup quoted here?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>Harald van D?k wrote:

>>CBFalconer wrote:
Richard Heathfield wrote:
>
... snip ...
>
#include <math.h>
>
#define M_PI 3.14
>
My point was that, since implementations are forbidden from
#defining M_PI, they have no grounds for complaint.

I can find no reference to 'M_PI' in any C standard I have
available. Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99
7.1.3p2 requires. What makes you think implementations are
allowed to define M_PI just because it isn't explicitly
forbidden by name in the standard?

But that is the point. M_PI is not reserved for the
implementation, therefore the application is perfectly free
to define it as desired.

Yes, of course. That's everybody else's point too, and I
don't believe anyone has disputed it. Your statement that
there's no reference to M_PI in the C standard is obviously
true, but added nothing to the discussion.

Did you have a point that hasn't already been made? Do you
disagree with anything that's been said so far in any
followup quoted here?

I was disagreeing with the implication (possibly misunderstood)
that the user was forbidden to #define M_PI.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Richard Heathfield]

CBFalconer said:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>Harald van D?k wrote:
CBFalconer wrote:
Richard Heathfield wrote:
>>
... snip ...
>>
>#include <math.h>
>>
>#define M_PI 3.14
>>
>My point was that, since implementations are forbidden from
>#defining M_PI, they have no grounds for complaint.
>
I can find no reference to 'M_PI' in any C standard I have
available. Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99
7.1.3p2 requires. What makes you think implementations are
allowed to define M_PI just because it isn't explicitly
forbidden by name in the standard?

But that is the point. M_PI is not reserved for the
implementation, therefore the application is perfectly free
to define it as desired.

Yes, of course. That's everybody else's point too, and I
don't believe anyone has disputed it. Your statement that
there's no reference to M_PI in the C standard is obviously
true, but added nothing to the discussion.

Did you have a point that hasn't already been made? Do you
disagree with anything that's been said so far in any
followup quoted here?

I was disagreeing with the implication (possibly misunderstood)
that the user was forbidden to #define M_PI.

Who implied that? Cite, please.

--
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

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>Harald van D?k wrote:
CBFalconer wrote:
Richard Heathfield wrote:
>>
... snip ...
>>
>#include <math.h>
>>
>#define M_PI 3.14
>>
>My point was that, since implementations are forbidden from
>#defining M_PI, they have no grounds for complaint.
>
I can find no reference to 'M_PI' in any C standard I have
available. Please give a specific reference.

The footnote attached to C99 4p6 makes explicit what C99
7.1.3p2 requires. What makes you think implementations are
allowed to define M_PI just because it isn't explicitly
forbidden by name in the standard?

But that is the point. M_PI is not reserved for the
implementation, therefore the application is perfectly free
to define it as desired.

Yes, of course. That's everybody else's point too, and I
don't believe anyone has disputed it. Your statement that
there's no reference to M_PI in the C standard is obviously
true, but added nothing to the discussion.

Did you have a point that hasn't already been made? Do you
disagree with anything that's been said so far in any
followup quoted here?

I was disagreeing with the implication (possibly misunderstood)
that the user was forbidden to #define M_PI.

I'm certain that no such implication was intended.

What Richard wrote was:

My point was that, since implementations are forbidden from
#defining M_PI, they [the implementations] have no grounds for
complaint [if the user #defines M_PI, which is of course
permitted].

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"