P: n/a

Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave  
Share this Question
P: n/a

<dm******@cox.netwrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
Did you mean x==end ?
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave  
P: n/a

On Mar 17, 8:39 pm, "osmium" <r124c4u...@comcast.netwrote:
<dmora...@cox.netwrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
Did you mean x==end ?
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave
That stopped the infinite loop, but now, it's stopping after the input
is entered.
Dave  
P: n/a
 dm******@cox.net wrote:
Hi all, I am a mathematician
Didn't you start out with this exact same phrase in a post some time
ago. As I recall, it start a flame thread.
and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
Unless you've good reasons, you might consider using double for these
objects. It provides greater default precision.
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
The = operator is the assignment operator. You probably meant <= or <
or some other relational or logical relation. Otherwise the test
simply assigns end to x and evaluates x. If x is other than zero, the
loop will continue. So if the user had entered a positive or negative
value for end, the program will enter an infinite loop.
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) + (37/52)*exp(3*x);
Mismatched parenthesis. If you don't cut and paste the exact code that
failed to compile or run, then it's guessing all the way.
You should split up the above statement into multiple steps, with a
temporary or two. By reordering it you can preserve more accuracy and
enhance readability.
printf("%3.3f %3.3f\n",x,y);
}
}
 
P: n/a
 dm******@cox.net wrote:
for(x=start;x=end;x+=step) {
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
Besides the problem with the for loop, the expressions (67/20) and
(37/52) are integer expressions that yield 3 and 0, respectively. To
get floating point values, insert a decimal point: (67./27.). The other
integers in the expression, 260, 130, 2, and 3, are already converted to
type double because of
1) use as a parameter of type double and
2) operation with an expression of type double.
In the case of (3*x), the integer 3 is negated, yielding 3 as an
integer, then converted to double (probably all at compile time) before
multiplying by x.
You can add decimal points to all these constants if you don't want to
bother remembering the rules for when conversion to floating point is done.

Thad  
P: n/a

<dm******@cox.netwrote:
On Mar 17, 8:39 pm, "osmium" <r124c4u...@comcast.netwrote:
><dmora...@cox.netwrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
Did you mean x==end ?
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave
That stopped the infinite loop, but now, it's stopping after the input
is entered.
In general, you should never test any floating point type for equality, such
numbers are represented as approximations to the real underlying number.
Testing for x==end is like trying to balance a dime on the rim. Changing to
x<= end yields a short table of numbers for me.  
P: n/a

On Mar 17, 9:34 pm, "osmium" <r124c4u...@comcast.netwrote:
<dmora...@cox.netwrote:
On Mar 17, 8:39 pm, "osmium" <r124c4u...@comcast.netwrote:
<dmora...@cox.netwrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
Did you mean x==end ?
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave
That stopped the infinite loop, but now, it's stopping after the input
is entered.
In general, you should never test any floating point type for equality, such
numbers are represented as approximations to the real underlying number.
Testing for x==end is like trying to balance a dime on the rim. Changing to
x<= end yields a short table of numbers for me.
Would it be better to use a do loop? I thought that I remember hearing
something that you should use a for loop only if you are using
integers to count.
Dave  
P: n/a

On 17 Mar 2007 18:45:31 0700, "dm******@cox.net" <dm******@cox.net>
wrote:
>On Mar 17, 8:39 pm, "osmium" <r124c4u...@comcast.netwrote:
><dmora...@cox.netwrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
Did you mean x==end ?
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave
That stopped the infinite loop, but now, it's stopping after the input is entered.
The conditional expression is evaluated before the first iteration.
Since x is not equal to end, the expression evaluates to zero and
looping is terminated even before the first iteration.
Remove del for email  
P: n/a
 dm******@cox.net said:
<snip>
Would it be better to use a do loop? I thought that I remember hearing
something that you should use a for loop only if you are using
integers to count.
No, there is no such rule or guideline, or at least not amongst those
who know the language well!
If anything, your for(counter = start; counter < end; counter += step)
example is actually a rather good example of when a forloop is
appropriate  but of course a while or a do would get the job done just
as well.

Richard Heathfield
"Usenet is a strange place"  dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain,  www.  
P: n/a

<dm******@cox.netwrote in message
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
>Did you mean x==end ?
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave
That stopped the infinite loop, but now, it's stopping after the input
is entered.
In general, you should never test any floating point type for equality, such numbers are represented as approximations to the real underlying number. Testing for x==end is like trying to balance a dime on the rim. Changing to x<= end yields a short table of numbers for me.
Would it be better to use a do loop? I thought that I remember hearing
something that you should use a for loop only if you are using
integers to count.
There are certain difficulties in using floats as the counter within a for
loop.
One is that, if the numbers are not integers, the test x != end may fail
because of numerical precision. This can be fixed with x <= end + epsilon.
Another problem is that programmers are so used to seeing for loops used to
index arrays that it can be confusing to see one used for another purpose.
The final problem in mathematics is that the funnylooking E notation used
for sums, conventionally, takes integral indices.
However if a for() loop most naturally expresses the logic of your
calculation, then use one.

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

On Mar 17, 8:45 pm, "dmora...@cox.net" <dmora...@cox.netwrote:
On Mar 17, 8:39 pm, "osmium" <r124c4u...@comcast.netwrote:
<dmora...@cox.netwrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
Code:
#include <stdio.h>
#include <math.h>
int main()
{
float start = 0;
float end = 0;
float step = 0;
float x = 0;
float y = 0;
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
for(x=start;x=end;x+=step) {
Did you mean x==end ?
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
printf("%3.3f %3.3f\n",x,y);
}
}
Thanks,
Dave
That stopped the infinite loop, but now, it's stopping after the input
is entered.
I think you're expecting the second part of the for loop to be an end
condition, i.e. You want to stop when x is equal to end. But the
second part is a boolean condition, i.e. the loop will continue until
that condition is false. You probably want x < end instead of x ==
end, so the loop will stop when x >= end.  
P: n/a

"Malcolm McLean" <re*******@btinternet.comwrites:
in mathematics ... the funnylooking E notation used for sums
<OT>
By "funnylooking E" would you mean "Sigma", perchance?
</OT>
mlp  
P: n/a

On Mar 18, 1:32 pm, "dmora...@cox.net" <dmora...@cox.netwrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived.
int main()
{
printf("Enter the starting value\n");
scanf("%f", &start);
printf("Enter the ending value\n");
scanf("%f", &end);
printf("Enter the step\n");
scanf("%f", &step);
What happens if the person types "x", or just presses Enter?
for(x=start;x=end;x+=step) {
'=' is the assignment operator. The equality test is '=='.
Also, as others have pointed out, testing for equality with
floating point types is unreliable.
y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) +
(37/52)*exp(3*x);
int divided by int gives int, in C, so 67/20 gives 3 and 37/52 gives
0.
You can fix it by writing 67./20 and 37./52
printf("%3.3f %3.3f\n",x,y);
}
Consider using 'double' instead of 'float'. You will also have
to change your scanf modifiers to '%lf' (or preferably use
fgets and strtod instead of scanf!).  
P: n/a

"Thad Smith" <Th*******@acm.orgwrote in message
news:45***********************@auth.newsreader.oct anews.com...
dm******@cox.net wrote:
>for(x=start;x=end;x+=step) { y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) + (37/52)*exp(3*x); printf("%3.3f %3.3f\n",x,y); }
Besides the problem with the for loop, the expressions (67/20) and (37/52)
are integer expressions that yield 3 and 0, respectively. To get floating
point values, insert a decimal point: (67./27.). The other integers in
the expression, 260, 130, 2, and 3, are already converted to type double
because of
1) use as a parameter of type double and
2) operation with an expression of type double.
In the case of (3*x), the integer 3 is negated, yielding 3 as an
integer, then converted to double (probably all at compile time) before
multiplying by x.
Since (pow(260,.5)/130), (67/20) and (37/52) are all constants, if you
precompute them and insert them as actual values, you can save yourself some
processing time.
NM  
P: n/a

Norm Mann wrote:
"Thad Smith" <Th*******@acm.orgwrote in message
news:45***********************@auth.newsreader.oct anews.com...
>>dm******@cox.net wrote:
>>>for(x=start;x=end;x+=step) { y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) + (37/52)*exp(3*x); printf("%3.3f %3.3f\n",x,y); }
Besides the problem with the for loop, the expressions (67/20) and (37/52) are integer expressions that yield 3 and 0, respectively. To get floating point values, insert a decimal point: (67./27.). The other integers in the expression, 260, 130, 2, and 3, are already converted to type double because of 1) use as a parameter of type double and 2) operation with an expression of type double.
Since (pow(260,.5)/130), (67/20) and (37/52) are all constants, if you
precompute them and insert them as actual values, you can save yourself some
processing time.
True, but I prefer having the program compute them to show the
derivation. If speed is an issue, you can compute the constants once in
the code and assign to variables.

Thad  
P: n/a

Malcolm McLean said:
<snip>
>
Another problem is that programmers are so used to seeing for loops
used to index arrays that it can be confusing to see one used for
another purpose.
I can't imagine any reason why such programmers should be mollycoddled.
Let them expand their horizons a little. Would we stop people from
measuring volts on a multimeter just because some people have never
used it to measure anything but amps?
The final problem in mathematics is that the funnylooking E notation
used for sums, conventionally, takes integral indices.
I've never seen /that/ written down anywhere. But okay  using only
integral indices, how would you, for example, sum the area under the
curve of y = x*x, between x = 0 and x = 1?
However if a for() loop most naturally expresses the logic of your
calculation, then use one.
Er, quite so.

Richard Heathfield
"Usenet is a strange place"  dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain,  www.  
P: n/a

In article <Cb*********************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Malcolm McLean said:
>The final problem in mathematics is that the funnylooking E notation used for sums, conventionally, takes integral indices.
I've never seen /that/ written down anywhere. But okay  using only integral indices, how would you, for example, sum the area under the curve of y = x*x, between x = 0 and x = 1?
Using an integral, not a sigma.
It's worth noting, though, that the sigma notation doesn't require that
indices are integers, only that they're discrete. I saw a lot of this
at the beginning of the math course I'm currently taking:

\
/ sgn(pi) * A_(1,pi(1)) * ... * A_(n,pi(n))

pi in S_n
Where pi is a permutation, S_n is the symmetric group of order n, and
the only integers in sight are the subscripts to the 'A's.
See also:

for(curr=head;curr;curr=curr>next)
{
/*For bonus brain explosion points, allow do_stuff to muck about
with the list you're walking through.
*/
do_stuff();
}

dave

Dave Vandervies dj******@csclub.uwaterloo.ca
You misspelled "typedef".
I had better go to sleep before I misspell "C".
pete and Brendan Sechter in comp.lang.c  
P: n/a

Richard Heathfield <rj*@see.sig.invalidwrites:
Malcolm McLean said:
[...]
>The final problem in mathematics is that the funnylooking E notation used for sums, conventionally, takes integral indices.
I've never seen /that/ written down anywhere. But okay  using only
integral indices, how would you, for example, sum the area under the
curve of y = x*x, between x = 0 and x = 1?
[...]
That would be an integral, not a summation (which uses the
"funnylooking E", also known as Sigma).

Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
 Antony Jay and Jonathan Lynn, "Yes Minister"  
P: n/a

Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Malcolm McLean said:
[...]
>>The final problem in mathematics is that the funnylooking E notation used for sums, conventionally, takes integral indices.
I've never seen /that/ written down anywhere. But okay  using only integral indices, how would you, for example, sum the area under the curve of y = x*x, between x = 0 and x = 1?
[...]
That would be an integral, not a summation (which uses the
"funnylooking E", also known as Sigma).
<shrugI certainly don't claim to be a mathematician but, if I remember
my schooldays correctly, you can approximate the area under a curve by
summing the areas of a series of narrow strips. I can understand that
you might have some special meaning for "summation" which doesn't
include this particular technique, but nobody mentioned "summation"
until you did, I think. Just "notation used for sums". Why would such
summing as I have described not constitute a sum?

Richard Heathfield
"Usenet is a strange place"  dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain,  www.  
P: n/a

Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>Malcolm McLean said:
[...]
>>>The final problem in mathematics is that the funnylooking E notation used for sums, conventionally, takes integral indices.
I've never seen /that/ written down anywhere. But okay  using only integral indices, how would you, for example, sum the area under the curve of y = x*x, between x = 0 and x = 1?
[...]
That would be an integral, not a summation (which uses the "funnylooking E", also known as Sigma).
<shrugI certainly don't claim to be a mathematician but, if I remember
my schooldays correctly, you can approximate the area under a curve by
summing the areas of a series of narrow strips. I can understand that
you might have some special meaning for "summation" which doesn't
include this particular technique, but nobody mentioned "summation"
until you did, I think. Just "notation used for sums". Why would such
summing as I have described not constitute a sum?
This has strayed off topic, but ...
You can *approximate* the area by summing the areas of a series of
narrow strips. To get the actual area, you need to take the limit as
the width of the strips approaches zero, and the number of strips
approaches infinity. With a finite number of strips, you have a
summation, represented by an upper case Sigma
(<http://en.wikipedia.org/wiki/Sumlooks reasonably accurate). In
the limit, you have a definite integral, represented by an integral
sign; that's integral calculs.

Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
 Antony Jay and Jonathan Lynn, "Yes Minister"  
P: n/a

In article <uf******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
><shrugI certainly don't claim to be a mathematician but, if I remember my schooldays correctly, you can approximate the area under a curve by summing the areas of a series of narrow strips. I can understand that you might have some special meaning for "summation" which doesn't include this particular technique, but nobody mentioned "summation" until you did, I think. Just "notation used for sums". Why would such summing as I have described not constitute a sum?
The integral is the limit of the sum as the interval width tends to
zero[1]. It's not itself a sum. This may seem like nitpicking, but
details of this kind can lead to endless confusion  look at the
innumerable articles in sci.math about whether 0.999... = 1 for
example.
[1] For Riemann integrals, there are others whose difference is not
important here.
 Richard

"Consideration shall be given to the need for as many as 32 characters
in some alphabets"  X3.4, 1963.  
P: n/a

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
>>I've never seen /that/ written down anywhere. But okay  using only integral indices, how would you, for example, sum the area under the curve of y = x*x, between x = 0 and x = 1?
[...]
That would be an integral, not a summation (which uses the "funnylooking E", also known as Sigma).
<shrugI certainly don't claim to be a mathematician but, if I remember
my schooldays correctly, you can approximate the area under a curve by
summing the areas of a series of narrow strips. I can understand that
you might have some special meaning for "summation" which doesn't
include this particular technique, but nobody mentioned "summation"
until you did, I think. Just "notation used for sums". Why would such
summing as I have described not constitute a sum?
One possible notation is
 1.0
\
/ i * i
0 i+= 0.01
Another is
 100
\
/ i/100 * i/100
i = 0
either would work, but the second form is seen more often.

Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm  
P: n/a
 dm******@cox.net wrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
....
for(x=start;x=end;x+=step) {
make that
for (x = start; x <= end; x += step)
First, what you meant was x==end (two equals, the most notorious
typobug for Cprogrammers, at least for me).
But because floating point arithmetic on computers is practically never
precise, *never* compare floats or doubles with ==, in your case, you
would certainly miss your end criterion by some small epsilon and march
on through number space.
Also, you should maybe check that (step >= 0 && start < end).  
P: n/a

"Thad Smith" <Th*******@acm.orgwrote in message
news:45***********************@auth.newsreader.oct anews.com...
Norm Mann wrote:
>"Thad Smith" <Th*******@acm.orgwrote in message news:45***********************@auth.newsreader.oc tanews.com...
>>>dm******@cox.net wrote:
for(x=start;x=end;x+=step) { y = (pow(260,.5)/130)*cos(2*x1.463) + (67/20)*exp(x) + (37/52)*exp(3*x); printf("%3.3f %3.3f\n",x,y); }
Besides the problem with the for loop, the expressions (67/20) and (37/52) are integer expressions that yield 3 and 0, respectively. To get floating point values, insert a decimal point: (67./27.). The other integers in the expression, 260, 130, 2, and 3, are already converted to type double because of 1) use as a parameter of type double and 2) operation with an expression of type double.
Since (pow(260,.5)/130), (67/20) and (37/52) are all constants, if you precompute them and insert them as actual values, you can save yourself some processing time.
True, but I prefer having the program compute them to show the derivation.
If speed is an issue, you can compute the constants once in the code and
assign to variables.
I hail from a time when speed was always an issue and these stick out like
sore thumbs. I would probably write out the equation as a comment and put
the precomputed values in anyway. I would also consider having the
constants computed and assigned to variables outside the loop, but that
won't prevent you from inadvertently doing integer operations instead of
floating point operations because you forget to include decimal points.
NM  
P: n/a

On Mar 19, 4:21 pm, Tobias Rischer <tob...@rischer.comwrote:
dmora...@cox.net wrote:
Hi all, I am a mathematician and I'm trying to write a program to try
out a formula that I've derived. However, it seems that I've got an
infinite loop and I don't quite understand why. I was hoping someone
could point me in the right direction.
...
for(x=start;x=end;x+=step) {
make that
for (x = start; x <= end; x += step)
First, what you meant was x==end (two equals, the most notorious
typobug for Cprogrammers, at least for me).
But because floating point arithmetic on computers is practically never
precise, *never* compare floats or doubles with ==, in your case, you
would certainly miss your end criterion by some small epsilon and march
on through number space.
Also, you should maybe check that (step >= 0 && start < end).
There's no reason to suppose he only wants increasing tables. He just
wants to avoid infinite loops. So he only needs to check that (step >
0 && start < end)  (step < 0 && start end)  (start == end).  
P: n/a

On Mar 19, 3:36 pm, Richard Heathfield <r...@see.sig.invalidwrote:
Malcolm McLean said:
The final problem in mathematics is that the funnylooking E notation
used for sums, conventionally, takes integral indices.
I think you'll find that it is the Greek version of the first
letter in the word "Sum". (While we're here, the integral sign
is the Roman version of the same letter, written with a bit of
artistic licence).
I've never seen /that/ written down anywhere.
It's not uncommon to use fractional indices, or summations that
appear to not involve a numeric variable at all (e.g. summing
over some property of each item in a set). Perhaps Mr McLean's
point was that you can usually (always?) rewrite the summation
to have an integral index. Or perhaps he's just talking crap.
But okay  using only integral indices, how would you, for example,
sum the area under the curve of y = x*x, between x = 0 and x = 1?
Not sure what you're asking. You would write this as an integral with
0 and 1 as the bounds. If you mean, how would you write a C program,
then you could use an integral type for the index, as a sort of
fixedpoint calculation.  
P: n/a

In article <11*********************@n76g2000hsh.googlegroups. com>,
Old Wolf <ol*****@inspire.net.nzwrote:
>On Mar 19, 3:36 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>I've never seen /that/ written down anywhere.
It's not uncommon to use fractional indices, or summations that appear to not involve a numeric variable at all (e.g. summing over some property of each item in a set). Perhaps Mr McLean's point was that you can usually (always?) rewrite the summation to have an integral index. Or perhaps he's just talking crap.
Somewhere in between, I would say.
I don't _think_ I've ever seen a sigma used to represent a sum over an
uncountable set, and anything that's indexing a countable set can be
rewritten to use integers as the index just by enumerating the set and
summing over the enumeration. It's not hard to come up with examples
(not necessarily even contrived ones) where it doesn't make sense to
do that rewriting, though, and I don't think "indexible by integers"
is the useful distinguishing property  discrete would be better.
Exercise for the reader: Does a finitely describable uncountable set
of discrete elements exist?
(V guvax gur cbjre frg bs gur frg bs vagrtref dhnyvsvrf.)
>But okay  using only integral indices, how would you, for example, sum the area under the curve of y = x*x, between x = 0 and x = 1?
Not sure what you're asking. You would write this as an integral with 0 and 1 as the bounds. If you mean, how would you write a C program, then you could use an integral type for the index, as a sort of fixedpoint calculation.
If I weren't a pure mathematician[1], I'd be saying "Simpson's Rule" here.
But, in the general case, you would need to integrate over a continuous
interval instead of summing over a discrete set, and you'd use something
other than a sigma to represent that.
dave
[1] By training, at least; by trade I'm a computer geek.

Dave Vandervies dj******@csclub.uwaterloo.ca
The Simpsons is a sick parody of everything else; at least they're being
consistent in their treatment of religion.
Anthony de Boer in the scary devil monastery  
P: n/a

Richard Heathfield wrote:
>
.... snip ...
>
I've never seen /that/ written down anywhere. But okay  using
only integral indices, how would you, for example, sum the area
under the curve of y = x*x, between x = 0 and x = 1?
Offhand, I would normalize x to the range 0..10,000 and use
simpsons rule or the trapezoidal rule. Experiment with diddling
the interval until the results are consistent.

<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
"A man who is right every time is not likely to do very much."
 Francis Crick, codiscover of DNA
"There is nothing more amazing than stupidity in action."
 Thomas Matthews

Posted via a free Usenet account from http://www.teranews.com  
P: n/a

/*
Here's my version of your 1/e program:
*/
#include <stdio.h>
#include <math.h>
int main()
{
double start = 0;
double end = 0;
double step = 0;
double x = 0;
double y = 0;
int converted;
you_idiot_one:
printf("Enter the nonnegative starting value\n");
converted = scanf("%lf", &start);
if (converted != 1  start < 0.0) goto you_idiot_one;
you_idiot_two:
printf("Enter the ending value\n");
converted = scanf("%lf", &end);
if (converted != 1  end < start) goto you_idiot_two;
you_idiot_three:
printf("Enter the step\n");
converted = scanf("%lf", &step);
if (converted != 1  step < 0) goto you_idiot_three;
for (x = start; x <= end; x += step) {
y = (sqrt(260.0) / 130.0) * cos(2.0 * x  1.463) + (67. / 20.)
* exp(x) + (37. / 52.) * exp(3. * x);
printf("%25.18f %25.18f\n", x, y);
}
return 0;
}
/*
C:\tmp>foo
Enter the nonnegative starting value
0
Enter the ending value
10
Enter the step
1
0.000000000000000000 4.074883071075573700
1.000000000000000000 9.248246041158287400
2.000000000000000000 24.653054101250959000
3.000000000000000000 67.264993538320653000
4.000000000000000000 183.023867843540100000
5.000000000000000000 497.105800281756560000
6.000000000000000000 1351.431551737800000000
7.000000000000000000 3673.845061976083800000
8.000000000000000000 9986.160974261707500000
9.000000000000000000 27145.247361213536000000
10.000000000000000000 73788.778437947738000000
*/  
P: n/a

On Mar 19, 6:23 pm, dj3va...@caffeine.csclub.uwaterloo.ca (Dave
Vandervies) wrote:
[snip]
Exercise for the reader: Does a finitely describable uncountable set
of discrete elements exist?
(V guvax gur cbjre frg bs gur frg bs vagrtref dhnyvsvrf.)
Vf gurer n sbezny cebbs gung gur frg bs nyy fhofrgf bs gur vagrtref vf
hapbhagnoyr?  
P: n/a

On Mar 20, 8:32 pm, "user923005" <dcor...@connx.comwrote:
/*
Here's my version of your 1/e program:
*/
I call it a 1/e program be cause the divided difference for one unit
step is A(n)/A(n+1) = 1/e (approximately)
You could also call it an e program, because you can get the same
series (asymptotically) by multiplying the previous term by e.
e.g.
....
9.000000000000000000 27145.247361213536000000
10.000000000000000000 73788.778437947738000000
27145.247361213536 * e =73788.432631012603400265298049315
e.g.
....
99.000000000000000000
33128251569812269000000000000000000000000000.00000 0000000000000
99.500000000000000000
54619253024254410000000000000000000000000000.00000 0000000000000
100.000000000000000000
90051924250840551000000000000000000000000000.00000 0000000000000
33128251569812269000000000000000000000000000 * e =
90051924250840530233087017917411
Seems to answer pretty nearly.
Since there are two calls to exp() in there with different args, I
guess it won't be a good way to calculate e, but I hope it has some
interesting properties that you are looking for.  
P: n/a

On Mar 20, 8:47 pm, "user923005" <dcor...@connx.comwrote:
On Mar 20, 8:32 pm, "user923005" <dcor...@connx.comwrote:
/*
Here's my version of your 1/e program:
*/
I call it a 1/e program be cause the divided difference for one unit
step is A(n)/A(n+1) = 1/e (approximately)
You could also call it an e program, because you can get the same
series (asymptotically) by multiplying the previous term by e.
e.g.
...
9.000000000000000000 27145.247361213536000000
10.000000000000000000 73788.778437947738000000
27145.247361213536 * e =73788.432631012603400265298049315
e.g.
...
99.000000000000000000
33128251569812269000000000000000000000000000.00000 0000000000000
99.500000000000000000
54619253024254410000000000000000000000000000.00000 0000000000000
100.000000000000000000
90051924250840551000000000000000000000000000.00000 0000000000000
33128251569812269000000000000000000000000000 * e =
90051924250840530233087017917411
Seems to answer pretty nearly.
Since there are two calls to exp() in there with different args, I
guess it won't be a good way to calculate e, but I hope it has some
interesting properties that you are looking for.
A bit of thought shows why it converges to e per unit step.
exp(x) is [by far] the fastest growing term.
It could be used as an explanation why O(f(n)) needs (primarily) the
dominant term to explain the nature of the algorithm for big
arguments.  
P: n/a

In article <11**********************@o5g2000hsb.googlegroups. com>,
user923005 <dc*****@connx.comwrote:
>On Mar 19, 6:23 pm, dj3va...@caffeine.csclub.uwaterloo.ca (Dave Vandervies) wrote: [snip]
>Exercise for the reader: Does a finitely describable uncountable set of discrete elements exist? (V guvax gur cbjre frg bs gur frg bs vagrtref dhnyvsvrf.)
Vf gurer n sbezny cebbs gung gur frg bs nyy fhofrgf bs gur vagrtref vf hapbhagnoyr?
Yes.
Vg'f npghnyyl fyvtugyl zber trareny; nal frg bs nal pneqvanyvgl unf n
fznyyre pneqvanyvgl guna vgf cbjre frg.
I can dig the proof out of my algebra notes from a year or two ago
if you're interested; this is getting rather far OT, so it's probably
better to email me if you want it. (Using dj3vande at eskimo.com[1]
will make it rather less likely that I'll delete your email without
noticing it while clearing the spam out from the address I post with.)
dave
[1] Protected from Google, not from spammers.

Dave Vandervies dj******@csclub.uwaterloo.ca
If only... there were people unburdened by the Hippocratic Oath on
ambulances, so they could usefully be fitted with rocket launchers.
Maarten Wiltink in the scary devil monastery  
P: n/a

you_idiot_one:
printf("Enter the nonnegative starting value\n");
converted = scanf("%lf", &start);
if (converted != 1  start < 0.0) goto you_idiot_one;
Apart that if, I input some nonnumerical data, scanf will try to read it as
a double over and over again, have you ever heard about "while"? C ain't
Commodore BASIC...
I am not one of those structuredprogramming worshippers who consider it
immoral to ever write "goto", "break", or "return" anywhere else than as the
last statement of a function, but here I just can't see how goto helps...
do {
printf("Enter the nonnegative starting value\n");
/* You don't even need printf here, */
/* puts("Enter the nonnegative starting value"); would do the job */
converted = scanf("%lf", &start);
} while (converted != 1  start < 0.0)   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 2271
 replies: 33
 date asked: Mar 18 '07
