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.

 

[lector]

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]

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.

 

[Joachim Schmitz]

William Pursell said:


Where is he doing that?


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

 

[Joachim Schmitz]

Joachim Schmitz said:


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.

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

 

[Doug Miller]

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

 

[Barry Schwarz]

On Mon, 7 Apr 2008 23:18:03 -0700 (PDT), lector

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]

William Pursell said:

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

 

[Harald van Dijk]

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?

 

[Flash Gordon]

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

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

 

[vippstar]

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



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

 

[Keith Thompson]

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]

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