If a weighted coin is tossed N times, count the times it lands heads as H. 
The probability of landing heads is P(H).

I assume the expected value of H is N*P(H).

But how do I find out what range of H is X% likely to happen?  For example, 
I want to be able to say that in 90% of cases H will be in the range (A,B).

What I've done so far is for 0<=H<=N calculated (N choose H)/P, where P is 
the total permutations of N items in N.  This should give me the probability 
of exactly H heads coming up, yes?  I can keep a cumulative total of these 
probabilites for each H, and then figure out the range of H between (say) 
10% and 90%.  But it seems a bit long-winded, I can't figure out how to 
calculate the range directly.  Also Excel can't figure out the permutations 
when N is bigger than 150 or so, I want it to work for higher values of N.

Any ideas?  Hopefully it's something obvious!

Post a reply to this message

scott wrote:
> If a weighted coin is tossed N times, count the times it lands heads as 
> H. The probability of landing heads is P(H).

I presume by this you explicitly mean that P(H) /= 50%?

> I assume the expected value of H is N*P(H).

Yes. That would be the definition of "probability". (Assuming all the 
trails are independent.)

> But how do I find out what range of H is X% likely to happen?  For 
> example, I want to be able to say that in 90% of cases H will be in the 
> range (A,B).

Now you're talking about probability distributions. If you can decide 
what probability distribution this experiment has, you can [potentially] 
directly compute the result you're after.

Wikipedia informs me that what you're looking for is a "binomial 
distribution". According to this, we have the probability of getting 
exactly K heads as

   (N choose K) * P(H)^K * (1 - P(H))^(N-K)

More usefully for you, the cumulative probability - the probability of K 
heads OR LESS, is given by

   I[1 - P(H)] (N - K, N + K)

where I[x](a, b) represents the regularised incomplete beta function,

http://en.wikipedia.org/wiki/Regularized_incomplete_beta_function

Unless Excel has a built-in function to compute I(), I would suggest it 
would be simpler and easier to directly compute the sum over the 
individual probabilities. (Especially since you want the probability for 
a value between K1 and K2, not between K1 and 0.)

You can also compute the cumulative probability by the integral

   (N - K) (N choose K) integral[0 .. 1-P(H)] t^(N-K-1) (1 - t)^K dt

But I'm guessing Excel can't do that.

Apparently you can also estimate the maximum probability by

   exp( -2 * (N * P(H) - K)^2 / N )

(The true cumulative probability is less than or equal to this. 
Apparently for P(H) = 50% it's quite a good approximation, but I'm not 
sure for other values.)

Post a reply to this message

Invisible wrote:

> More usefully for you, the cumulative probability - the probability of K 
> heads OR LESS, is given by
> 
>   I[1 - P(H)] (N - K, N + K)
> 
> where I[x](a, b) represents the regularised incomplete beta function,
> 
> http://en.wikipedia.org/wiki/Regularized_incomplete_beta_function

http://reference.wolfram.com/mathematica/ref/BetaRegularized.html

So Wolfram Alpha will compute it, for example.

But that doesn't matter:

http://office.microsoft.com/en-us/excel/HP052090051033.aspx

Post a reply to this message

> Wikipedia informs me that what you're looking for is a "binomial 
> distribution".

Thanks - that was the key I needed!

> According to this, we have the probability of getting exactly K heads as
>
>   (N choose K) * P(H)^K * (1 - P(H))^(N-K)

That *is* useful, at least using this formula I get correct results, 
although it's still a bit clumsy.

I will continue with Excel now trying to make it a bit neater.

Post a reply to this message

scott wrote:
>> Wikipedia informs me that what you're looking for is a "binomial 
>> distribution".
> 
> Thanks - that was the key I needed!
> 
>> According to this, we have the probability of getting exactly K heads as
>>
>>   (N choose K) * P(H)^K * (1 - P(H))^(N-K)
> 
> That *is* useful, at least using this formula I get correct results, 
> although it's still a bit clumsy.
> 
> I will continue with Excel now trying to make it a bit neater.

See my other post; Excel has a function to directly compute a binomial 
distribution, apparently. (And cumulatively, if you wish.)

Post a reply to this message

> See my other post; Excel has a function to directly compute a binomial 
> distribution, apparently. (And cumulatively, if you wish.)

I need the inverse function though, I want to tell it the cumulative 
probability (eg 10% and 90%) and it tell me how many successful trials that 
relates to.  There seems to be no BINOMDISTINV function.

Post a reply to this message

scott wrote:
>> See my other post; Excel has a function to directly compute a binomial 
>> distribution, apparently. (And cumulatively, if you wish.)
> 
> I need the inverse function though, I want to tell it the cumulative 
> probability (eg 10% and 90%) and it tell me how many successful trials 
> that relates to.  There seems to be no BINOMDISTINV function.

Wikipedia claims that for large N, the binomial distribution 
approximates the normal distribution. (If you plot the normal 
distribution with expected value N * P(H) and varience N * P(H) * (1 - 
P(H)).)

This approximation works best for large N and for P(H) near to 50%.

I presume it's relatively easy to work out the inverse function for a 
normal distribution...

Post a reply to this message

> Wikipedia claims that for large N, the binomial distribution approximates 
> the normal distribution.

Yes, it seems my parameter values fit in ok for this approximation to be 
pretty accurate.

> I presume it's relatively easy to work out the inverse function for a 
> normal distribution...

Excel has a built in function to do this, so this looks like the way to go.

Post a reply to this message

>> Wikipedia claims that for large N, the binomial distribution 
>> approximates the normal distribution.
> 
> Yes, it seems my parameter values fit in ok for this approximation to be 
> pretty accurate.

Central Limit Theorum FTW! :-D

>> I presume it's relatively easy to work out the inverse function for a 
>> normal distribution...
> 
> Excel has a built in function to do this, so this looks like the way to go.

Cool.

So are you *really* trying to estimate coin flips? Or is there some more 
complex problem you're trying to solve here?

Also... I'm impressed that I managed to find an actual solution to this 
using nothing but Wipikedia and an incomplete understanding of probability.

PS. Apparently Wolfram Alpha can plot all these distributions for you if 
you type in something suggestive like "binomial distribution, n=100, p=0.2".

Post a reply to this message

> So are you *really* trying to estimate coin flips? Or is there some more 
> complex problem you're trying to solve here?

Not really more complex, just a game that is played repeatedly and you have 
a certain % chance of winning (say 57%).  I just want to know if you play 
10,100, 1000 times what is the *likely* number of wins in some kind of worst 
case and best case scenario.  ie it's obviously possible to win every single 
game, but that is *really* unlikely, I want to know how many you'd win with 
90% or 99% confidence.

Post a reply to this message

scott wrote:
>> So are you *really* trying to estimate coin flips? Or is there some 
>> more complex problem you're trying to solve here?
> 
> Not really more complex, just a game that is played repeatedly and you 
> have a certain % chance of winning (say 57%).  I just want to know if 
> you play 10,100, 1000 times what is the *likely* number of wins in some 
> kind of worst case and best case scenario.  ie it's obviously possible 
> to win every single game, but that is *really* unlikely, I want to know 
> how many you'd win with 90% or 99% confidence.

Right. So it's ye olde "2SD = 95% confidence" rule then.

Post a reply to this message

Invisible wrote:
> I presume it's relatively easy to work out the inverse function for a 
> normal distribution...

Actually it's impossible to analytically compute.  Fortunately many 
pieces of software have a built in function to numerically compute it.

Post a reply to this message

>> I presume it's relatively easy to work out the inverse function for a 
>> normal distribution...
> 
> Actually it's impossible to analytically compute.

Define "analytically".

Last time I checked, it's impossible to compute the square root of a 
number "exactly" - and yet it's trivially easy to approximate it to any 
desired accuracy.

Post a reply to this message

Invisible wrote:
>>> I presume it's relatively easy to work out the inverse function for a 
>>> normal distribution...
>>
>> Actually it's impossible to analytically compute.
> 
> Define "analytically".

As a closed-form expression.  As I said, it's still possible to compute 
numerically.

Post a reply to this message

Kevin Wampler wrote:
> Invisible wrote:
>>>> I presume it's relatively easy to work out the inverse function for 
>>>> a normal distribution...
>>>
>>> Actually it's impossible to analytically compute.
>>
>> Define "analytically".
> 
> As a closed-form expression.  As I said, it's still possible to compute 
> numerically.

And Sqrt[2] erf^-1 (2z - 1) doesn't count because...?

Post a reply to this message

Invisible wrote:
> Kevin Wampler wrote:
>> Invisible wrote:
>>>>> I presume it's relatively easy to work out the inverse function for 
>>>>> a normal distribution...
>>>>
>>>> Actually it's impossible to analytically compute.
>>>
>>> Define "analytically".
>>
>> As a closed-form expression.  As I said, it's still possible to 
>> compute numerically.
> 
> And Sqrt[2] erf^-1 (2z - 1) doesn't count because...?

erf isn't an elementary function.  See:

http://en.wikipedia.org/wiki/Closed-form_expression

http://en.wikipedia.org/wiki/Error_function#Taylor_series

Post a reply to this message

>>>>>> I presume it's relatively easy to work out the inverse function 
>>>>>> for a normal distribution...
>>>>>
>>>>> Actually it's impossible to analytically compute.
>>>>
>>>> Define "analytically".
>>>
>>> As a closed-form expression.  As I said, it's still possible to 
>>> compute numerically.
>>
>> And Sqrt[2] erf^-1 (2z - 1) doesn't count because...?
> 
> erf isn't an elementary function.  See:
> 
> http://en.wikipedia.org/wiki/Closed-form_expression
> 
> http://en.wikipedia.org/wiki/Error_function#Taylor_series

Right. So what you're actually saying is that you can't compute the 
confidence interval exactly using a finite number of applications of a 
particular arbitrarily chosen set of functions - the elementary functions.

Post a reply to this message

Invisible wrote:
>>>> As a closed-form expression.
> 
> Right. So what you're actually saying is that you can't compute the 
> confidence interval exactly using a finite number of applications of a 
> particular arbitrarily chosen set of functions - the elementary functions.

That is indeed the definition.

This obviously doesn't matter for scott's case since he just wants a 
numeric answer and Excel seems to have erf built in, I just wanted to 
point out that far from being "relatively easy" to work out, the 
cumulative distribution function of a Gaussian is generally the first 
function people encounter which is impossible to actually compute in 
closed form (normally this will come up in first or second year calculus 
at some point).  I'll agree that at first glance it certainly *looks* 
like it would be simple to compute though, which is part of why it's 
interesting.

Post a reply to this message

>>>>> As a closed-form expression.
>>
>> Right. So what you're actually saying is that you can't compute the 
>> confidence interval exactly using a finite number of applications of a 
>> particular arbitrarily chosen set of functions - the elementary 
>> functions.
> 
> That is indeed the definition.
> 
> This obviously doesn't matter for scott's case since he just wants a 
> numeric answer and Excel seems to have erf built in, I just wanted to 
> point out that far from being "relatively easy" to work out, the 
> cumulative distribution function of a Gaussian is generally the first 
> function people encounter which is impossible to actually compute in 
> closed form (normally this will come up in first or second year calculus 
> at some point).  I'll agree that at first glance it certainly *looks* 
> like it would be simple to compute though, which is part of why it's 
> interesting.

Well, the sine and cosine functions can't be computed by a finite number 
of additions, subtractions, multiplications, divisions and exponents. 
But since sine and cosine are included in the arbitrary "set of 
permissible functions", they don't count. But erf is not, so it does count.

To me, it seems that approximating erf (or its inverse) is no harder 
than approximating a sine or cosine - and we do that all day.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Well, the sine and cosine functions can't be computed by a finite number 
> of additions, subtractions, multiplications, divisions and exponents. 

  They can if you allow the parameters to be complex numbers (which is why
trigonometric functions are included in the set of elementary functions).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> Well, the sine and cosine functions can't be computed by a finite number 
>> of additions, subtractions, multiplications, divisions and exponents. 
> 
>   They can if you allow the parameters to be complex numbers (which is why
> trigonometric functions are included in the set of elementary functions).

OK, but that just brings us back to the fact that the exponential 
operator has to be approximated. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> http://office.microsoft.com/en-us/excel/HP052090051033.aspx

Nice, that link crashed my browser :) Clearly Microsoft and KDE don't like 
each other.

Post a reply to this message

Orchid XP v8 wrote:
> Warp wrote:
>> Orchid XP v8 <voi### [at] devnull> wrote:
>>> Well, the sine and cosine functions can't be computed by a finite 
>>> number of additions, subtractions, multiplications, divisions and 
>>> exponents. 
>>
>>   They can if you allow the parameters to be complex numbers (which is 
>> why
>> trigonometric functions are included in the set of elementary functions).
> 
> OK, but that just brings us back to the fact that the exponential 
> operator has to be approximated. ;-)
> 

Did you read the Wikipedia page on closed form expressions?  It's not 
very long and all of these points are addressed there.

Post a reply to this message

Nicolas Alvarez wrote:
> Invisible wrote:
>> http://office.microsoft.com/en-us/excel/HP052090051033.aspx
> 
> Nice, that link crashed my browser :) Clearly Microsoft and KDE don't like 
> each other.

Crashed it? Or just upset it?

Microsoft may use proprietry features and write terrible markup, but if 
a browser crashes when fed the wrong data, methinks the browser should 
be rewritten to fail gracefully. ;-)

The only unusual thing I can see about the page [other than too much 
JavaScript] is a flash advert.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Kevin Wampler wrote:

> Did you read the Wikipedia page on closed form expressions?  It's not 
> very long and all of these points are addressed there.

...OK, just read it. Doesn't seem to address very much.

Also, I've often wondered how the **** you compute something like the 
Gamma function or the Bessel-J function. I mean, have you *seen* the 
definition?!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Kevin Wampler wrote:
> 
>> Did you read the Wikipedia page on closed form expressions?  It's not 
>> very long and all of these points are addressed there.
> 
> ...OK, just read it. Doesn't seem to address very much.

I was thinking of:

" constants, one variable x, elementary operations of arithmetic (+ – × 
÷ –), nth roots, exponent and logarithm (which thus also include 
trigonometric functions and inverse trigonometric functions)."

and

"For purposes of numeric computations, being in closed form is not in 
general necessary, as many limits and integrals can be efficiently 
computed."

Which seem to exactly cover both of the points you recently mentioned, 
but perhaps I misunderstood what points you were making.


> Also, I've often wondered how the **** you compute something like the 
> Gamma function or the Bessel-J function. I mean, have you *seen* the 
> definition?!

Yes.  If you take a look at the Wikipedia article for the gamma function 
you'll see that it includes a couple of nice representations in terms of 
infinite products.  The Bessel functions seem a bit more involved, but 
it has representations in terms of a sum over terms involving the gamma 
function, a hypergeometric series, and a recursive relation to a 
continued fraction -- so there seem to be many ways to go about 
computing it (I didn't look up what the standard approach in practice was).

I know that you say that you have trouble digesting the Wikipedia 
articles on these in full (entirely understandable, they are very dense 
and not always well written) but you still can answer these questions by 
spending a minute or two just skimming over them without trying to 
understand everything.

Post a reply to this message

>> ...OK, just read it. Doesn't seem to address very much.
> 
> I was thinking of:
> 
> " constants, one variable x, elementary operations of arithmetic (+ – × 
> ÷ –), nth roots, exponent and logarithm (which thus also include 
> trigonometric functions and inverse trigonometric functions)."
> 
> and
> 
> "For purposes of numeric computations, being in closed form is not in 
> general necessary, as many limits and integrals can be efficiently 
> computed."
> 
> Which seem to exactly cover both of the points you recently mentioned, 
> but perhaps I misunderstood what points you were making.

Oh, I see. I thought it was going to say something more insightful than 
that. (How the hell do you compute a limit or an integral anyway?)

>> Also, I've often wondered how the **** you compute something like the 
>> Gamma function or the Bessel-J function. I mean, have you *seen* the 
>> definition?!
> 
> Yes.  If you take a look at the Wikipedia article for the gamma function 
> you'll see that it includes a couple of nice representations in terms of 
> infinite products.

But you can't compute an infinite product.

> The Bessel functions seem a bit more involved, but 
> it has representations in terms of a sum over terms involving the gamma 
> function, a hypergeometric series, and a recursive relation to a 
> continued fraction -- so there seem to be many ways to go about 
> computing it (I didn't look up what the standard approach in practice was).

Uh...OK.

> I know that you say that you have trouble digesting the Wikipedia 
> articles on these in full (entirely understandable, they are very dense 
> and not always well written) but you still can answer these questions by 
> spending a minute or two just skimming over them without trying to 
> understand everything.

Heh. Some of them explain things quite clearly, but others are 
incomprehensible. That's the trouble with a reference source written by 
bored Internet surfers; first it's a reference, not an introduction, and 
second the quality is *highly* variable. ;-)

Post a reply to this message

>> Not really more complex, just a game that is played repeatedly and you 
>> have a certain % chance of winning (say 57%).  I just want to know if you 
>> play 10,100, 1000 times what is the *likely* number of wins in some kind 
>> of worst case and best case scenario.  ie it's obviously possible to win 
>> every single game, but that is *really* unlikely, I want to know how many 
>> you'd win with 90% or 99% confidence.
>
> Right. So it's ye olde "2SD = 95% confidence" rule then.

Indeed.  It turns out in my game that you break even if you win 54% of the 
time, and in practise you can only realistically expect to win 57% of the 
time if you are good at the game.  These two facts mean that after even 1000 
games there is still a huge variation in how much profit you can expect to 
make - 95% confidence you will make between -7 and 607 arbitrary units of 
profit.

Post a reply to this message

Invisible wrote:
> Oh, I see. I thought it was going to say something more insightful than 
> that. (How the hell do you compute a limit or an integral anyway?)

Ahh, no nothing more insightful, just that it did address the major 
points you were worrying about.

Also, I'll assume you mean "how do you numerically compute a limit or 
integral?":

If it's a limit, just compute it for numbers as close as possible to the 
limiting value (or really really big numbers if the limiting value is 
infinite).  The closer (or the bigger) the number you compute it for the 
closer your answer will be.

If it's an integral do something like this: 
http://en.wikipedia.org/wiki/Riemann_sum

> But you can't compute an infinite product.

If the product converges (which it does, otherwise you couldn't define a 
number/function with it) then you can by definition get an arbitrarily 
good approximation by computing the product of the first n terms for a 
large enough n.

You might want to read up on these, they're pretty much fundamental to 
all of calculus and many many other ways of defining things over the 
real (or complex) numbers (Taylor expansions, Fourier series, numeric 
optimization and root finding, etc.):

http://en.wikipedia.org/wiki/Limit_(mathematics)
http://en.wikipedia.org/wiki/Limit_of_a_sequence

Out of curiosity have you ever had a calculus class?  I'd think that 
these things should have been covered there, and it makes me wonder if 
maybe the UK curriculum is somewhat different that what I'm used to.

Post a reply to this message

>> Oh, I see. I thought it was going to say something more insightful 
>> than that. (How the hell do you compute a limit or an integral anyway?)
> 
> Ahh, no nothing more insightful, just that it did address the major 
> points you were worrying about.
> 
> Also, I'll assume you mean "how do you numerically compute a limit or 
> integral?":
> 
> If it's a limit, just compute it for numbers as close as possible to the 
> limiting value (or really really big numbers if the limiting value is 
> infinite).  The closer (or the bigger) the number you compute it for the 
> closer your answer will be.

Wouldn't that be increadibly unstable, numerically?

> If it's an integral do something like this: 
> http://en.wikipedia.org/wiki/Riemann_sum

I see. (Although I'm still not sure how you compute an infinite integral 
this way...)

>> But you can't compute an infinite product.
> 
> If the product converges (which it does, otherwise you couldn't define a 
> number/function with it) then you can by definition get an arbitrarily 
> good approximation by computing the product of the first n terms for a 
> large enough n.

I don't see how that is the case.

If you have an infinite *sum*, then as long as the terms get 
progressively more tiny and never get larger again, you can disregard 
all the terms after a certain point. But if you're taking a *product* 
then any term, anywhere in the series could radically alter the final 
result.

> Out of curiosity have you ever had a calculus class?

I've never had *any* maths class!

(Unless you count what we did at school. This simply involved filling 
out hundreds of thousands of pages of long-division problems over a 
7-year period...)

Hypothetically I shouldn't be able to do algebra at all...

Post a reply to this message

Invisible wrote:
> Wouldn't that be increadibly unstable, numerically?

How could it be?  If you're taking the limit of something that's going to a 
finite value in a continuous curve, how could your calculation of the value 
closer to the limit have more error than the error calculated farther from 
the limit?

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Invisible wrote:
>> If it's a limit, just compute it for numbers as close as possible to 
>> the limiting value (or really really big numbers if the limiting value 
>> is infinite).  The closer (or the bigger) the number you compute it 
>> for the closer your answer will be.
> 
> Wouldn't that be increadibly unstable, numerically?

How much a a problem this is depends on the limit.  For most limits that 
I've ever numerically computed it's worked fine.  If you're taking the 
limit of a series (as opposed to the limit of a function) then it'll 
almost certainly be fine.


>> If it's an integral do something like this: 
>> http://en.wikipedia.org/wiki/Riemann_sum
> 
> I see. (Although I'm still not sure how you compute an infinite integral 
> this way...)

Combine this definition with how you compute the limit of an infinite 
sum.  So you'll have two approximations, one in approximating the 
integral with an infinite sum, and another with approximating the 
infinite sum with a finite one.  If you're doing this, it'd be wise to 
prove that these approximations both converge to the correct value.

>>> But you can't compute an infinite product.
>>
>> If the product converges (which it does, otherwise you couldn't define 
>> a number/function with it) then you can by definition get an 
>> arbitrarily good approximation by computing the product of the first n 
>> terms for a large enough n.
> 
> I don't see how that is the case.
> 
> If you have an infinite *sum*, then as long as the terms get 
> progressively more tiny and never get larger again, you can disregard 
> all the terms after a certain point. But if you're taking a *product* 
> then any term, anywhere in the series could radically alter the final 
> result.

The same is true for a sum actually.  The point is proving that an 
infinite sum or product *converges* is to show that this doesn't happen. 
  Basically you show that the partial sums/products form a convergent 
sequence (see the "Limit of a sequence" Wikipedia article I linked). 
Then you know by definition that you can get a good approximation by 
computing a large enough partial sum/product.

In the case of a sum this requires that the terms progressively get 
closer to zero, for a product it'll require they get closer to one.


>> Out of curiosity have you ever had a calculus class?
> 
> I've never had *any* maths class!
> 
> (Unless you count what we did at school. This simply involved filling 
> out hundreds of thousands of pages of long-division problems over a 
> 7-year period...)
> 
> Hypothetically I shouldn't be able to do algebra at all...

That's too bad, it seems like you would have greatly enjoyed being able 
to do some math that was more advanced than long division.

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Wouldn't that be increadibly unstable, numerically?
> 
> How could it be?  If you're taking the limit of something that's going 
> to a finite value in a continuous curve, how could your calculation of 
> the value closer to the limit have more error than the error calculated 
> farther from the limit?

According to Google calculator, sin(1e-14)/1e-14 = 1, but 
sin(1e-15)/1e-15 = 0.

Post a reply to this message

Kevin Wampler wrote:
> 
> In the case of a sum this requires that the terms progressively get 
> closer to zero, for a product it'll require they get closer to one.
> 

*caveat: unless the product converges to zero.

Post a reply to this message

>>> Wouldn't that be increadibly unstable, numerically?
>>
>> How could it be?  If you're taking the limit of something that's going 
>> to a finite value in a continuous curve, how could your calculation of 
>> the value closer to the limit have more error than the error 
>> calculated farther from the limit?
> 
> According to Google calculator, sin(1e-14)/1e-14 = 1, but 
> sin(1e-15)/1e-15 = 0.

Indeed, this was going to be my example. When x is small, sin(x) is 
approximately equal to x. But whatever, sin(x)/x when x is small 
involves division by a tiny number - which is equivilant to 
multiplication by a huge number. It's numerically unstable.

(Of course, the limit of sin(x)/x as x approaches zero is just 1, which 
you don't need to "estimate" in the first place. But if you had a 
similar formula which approximates some irrational quantity...)

Post a reply to this message

>>> If it's a limit, just compute it for numbers as close as possible to 
>>> the limiting value (or really really big numbers if the limiting 
>>> value is infinite).  The closer (or the bigger) the number you 
>>> compute it for the closer your answer will be.
>>
>> Wouldn't that be increadibly unstable, numerically?
> 
> How much of a problem this is depends on the limit.

True enough.

>>>> But you can't compute an infinite product.
>>>
>>> If the product converges then you can by definition get an 
>>> arbitrarily good approximation by computing the product of the first 
>>> n terms for a large enough n.
>>
>> I don't see how that is the case.
>>
>> If you have an infinite *sum*, then as long as the terms get 
>> progressively more tiny and never get larger again, you can disregard 
>> all the terms after a certain point. But if you're taking a *product* 
>> then any term, anywhere in the series could radically alter the final 
>> result.
> 
> The same is true for a sum actually.  The point is proving that an 
> infinite sum or product *converges* is to show that this doesn't happen. 
>  Basically you show that the partial sums/products form a convergent 
> sequence (see the "Limit of a sequence" Wikipedia article I linked). 
> Then you know by definition that you can get a good approximation by 
> computing a large enough partial sum/product.
> 
> In the case of a sum this requires that the terms progressively get 
> closer to zero, for a product it'll require they get closer to one.

I guess it's just the case that an infinite sum or product can be 
convergent, and yet converge really, *really* slowly...

>>> Out of curiosity have you ever had a calculus class?
>>
>> I've never had *any* maths class!
>>
>> (Unless you count what we did at school. This simply involved filling 
>> out hundreds of thousands of pages of long-division problems over a 
>> 7-year period...)
>>
>> Hypothetically I shouldn't be able to do algebra at all...
> 
> That's too bad, it seems like you would have greatly enjoyed being able 
> to do some math that was more advanced than long division.

Well, I *did* go to a school for stupid people, after all...

Post a reply to this message

Orchid XP v8 wrote:
> Nicolas Alvarez wrote:
>> Invisible wrote:
>>> http://office.microsoft.com/en-us/excel/HP052090051033.aspx
>> 
>> Nice, that link crashed my browser :) Clearly Microsoft and KDE don't
>> like each other.
> 
> Crashed it? Or just upset it?

Crashed. A khtml::BidiContext object supposedly on the memory address 
0xffffffffffffffff had one of its member methods called. *Boom*.

I filed a bug: http://bugs.kde.org/show_bug.cgi?id=225954

Post a reply to this message

>>>> http://office.microsoft.com/en-us/excel/HP052090051033.aspx
>>> Nice, that link crashed my browser :) Clearly Microsoft and KDE don't
>>> like each other.
>> Crashed it? Or just upset it?
> 
> Crashed. A khtml::BidiContext object supposedly on the memory address 
> 0xffffffffffffffff had one of its member methods called. *Boom*.
> 
> I filed a bug: http://bugs.kde.org/show_bug.cgi?id=225954

OK, that's not good...

Post a reply to this message