could you fix your code to correspond with the original formula?
There really wasn't an original formula - I just created one. In fact, that probably was the point of the original exercise. I realize that I'm really computing the sum for n-1, but sometimes you discover something interesting when you try something different.
| [reply]
[d/l] |
Sorry I was unclear. By "original formula", I mean the formula that generated the series you gave as an example of what you wanted to generate. I.e.:
(Series 1)
30 29 1
---- + ---- + ... + ----
1 2 30
From that, you said that you wanted to be able to compute the "general case for 'n', where n is the number of items in a series that looks similar to the example above I.e:
(Formula for Series 1)
( (n+1-k) )
Sum ( ------- ) for k = (1..n);
( k )
If you were computing the sum for 'n-1', wouldn't you want the sum:
(Series 2)
29 28 1
---- + ---- + ... + ----
1 2 29
That's not what your code generates, either. That's what I meant by 'fixing' the code -- making it consistent with which-ever series you wanted (top one for 'n' or bottom one for 'n-1'). But the program you implemented doesn't generate either series because it doesn't implement the formula to generate that series but instead, for n=30, generates the series:
(Series 3)
1 2 30
---- + ---- + ... + ----
29 28 0
That series is backwards from your original example, the code always divides by zero at the end the inner "for-loop", and skips the inner for-loop entirely, on the first iteration through the outer for-loop, making the sum, "$s", equal to "0". So the first time through the outer loop, you try to call $s->numerator & $s->denominator, but you've called them when $s=0 and no calculations have been done, thus the exception.
Where you wanting to discover something different? :-)
| [reply]
[d/l]
[select] |
I see what you are saying. My code computes the same sequence as yours but shifted by a term. That is, your sum for n is my sum for n+1. Or maybe it's the other way around. I easily get confused when it comes to boundary conditions, but it's definitely one or the other.
The point is that by coding the loop the way I did, I discovered a loop-hole in the way bigrat works. Specifically, if $a and $b are the iterator variables of for loops, and they both take their values from a range operator (i.e., ..), then $a / $b will not result in a bigrat. If I had coded the sum your way, I wouldn't have gotten tripped on this. That's what I mean by discovering something by thinking differently.
| [reply]
[d/l]
[select] |