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.