[haiku-commits] Re: haiku: hrev46684 - src/apps/deskcalc

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 16 Jan 2014 20:49:05 +0100

On 01/16/2014 08:33 PM, John Scipione wrote:
On Thu, Jan 16, 2014 at 2:22 PM, John Scipione <jscipione@xxxxxxxxx> wrote:
On Thu, Jan 16, 2014 at 7:42 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
On 01/16/2014 01:16 PM, John Scipione wrote:
! (Factorial)

I see. How about using an exact computation up to say n=1000 and beyond that
use a good approximation [1]? It doesn't seem particularly useful to wait 10
minutes for an exact 1000000! result when in the end only a few significant
digits are shown anyway.

Unfortunately Stirling's approximation doesn't seem to be accurate
enough. It is accurate to only 3 significant figures for 1,000! and 5
for 10,000!

I guess we could let the user choose if they want to be fast or
accurate... but that doesn't seem like a very friendly choice.

DeskCalc isn't exactly meant to be relied upon for scientific
accuracy, so maybe it's okay to sacrifice some accuracy for speed.
What do you think?

According to "Speed of convergence and error estimates" section of the Wikipedia page one can use a better approximation of the Stirling series. Guessing from the chart, using 5 terms should get the error down to around 10^-13 for 100! already.

One last thing, even with Stirling's approximation in place we hit
Calculating... for >= 1E7! so it doesn't eliminate the need for a
separate execution thread, just postpones it a couple orders of
magnitude.

I suppose that's due to the use of MAPM as backend. It actually computes the millions of decimal places (it will probably even run out of memory due to that, when computing a sufficiently large number). I don't recall, if there was an actual reason for using MAPM. It obviously doesn't make much sense in this case.

CU, Ingo


Other related posts: