Infinite loop

K

Keith Thompson

Richard Heathfield said:
Keith Thompson said:
Richard Heathfield said:
Malcolm McLean said: [...]
The final problem in mathematics is that the funny-looking 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
"funny-looking E", also known as Sigma).

<shrug> I 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/Sum> looks reasonably accurate). In
the limit, you have a definite integral, represented by an integral
sign; that's integral calculs.
 
R

Richard Tobin

Richard Heathfield said:
<shrug> I 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
 
M

Malcolm McLean

Richard Heathfield said:
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
"funny-looking E", also known as Sigma).

<shrug> I 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.
 
T

Tobias Rischer

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
typo-bug for C-programmers, 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).
 
N

Norm Mann

Thad Smith said:
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 pre-computed 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
 
C

Chris Johnson

make that

for (x = start; x <= end; x += step)

First, what you meant was x==end (two equals, the most notorious
typo-bug for C-programmers, 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).
 
O

Old Wolf

Malcolm McLean said:

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?) re-write 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
fixed-point calculation.
 
D

Dave Vandervies

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?) re-write 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
re-written 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.)

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
fixed-point 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.
 
U

user923005

/*
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 non-negative 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 non-negative 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

*/
 
U

user923005

On Mar 19, 6:23 pm, (e-mail address removed) (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?
 
U

user923005

/*
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.000000000000000000
99.500000000000000000
54619253024254410000000000000000000000000000.000000000000000000
100.000000000000000000
90051924250840551000000000000000000000000000.000000000000000000

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

user923005

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.000000000000000000
99.500000000000000000
54619253024254410000000000000000000000000000.000000000000000000
100.000000000000000000
90051924250840551000000000000000000000000000.000000000000000000

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

Dave Vandervies

On Mar 19, 6:23 pm, (e-mail address removed) (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.
 
A

Army1987

you_idiot_one:
printf("Enter the non-negative starting value\n");
converted = scanf("%lf", &start);
if (converted != 1 || start < 0.0) goto you_idiot_one;

Apart that if, I input some non-numerical 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 structured-programming 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 non-negative starting value\n");
/* You don't even need printf here, */
/* puts("Enter the non-negative starting value"); would do the job */
converted = scanf("%lf", &start);
} while (converted != 1 || start < 0.0)
 

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

Forum statistics

Threads
473,777
Messages
2,569,604
Members
45,218
Latest member
JolieDenha

Latest Threads

Top