Any idea why this program is not generating an output ?

L

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

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

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

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

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

Joachim Schmitz

Richard said:
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
 
J

Joachim Schmitz

Richard said:
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
 
D

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

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
 
D

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
 
H

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

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

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

Keith Thompson

CBFalconer said:
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?
 
K

Keith Thompson

CBFalconer said:
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].
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top