>
> s = -s *,
> (6*n) * (6*n-1) * (6*n-2) * (6*n-3) * (6*n-4) * (6*n-5),
> /,
> ((3*n) * (3*n-1) * (3*n-2) * n * n * n * k3_power3)
> t = t + s * (k1 + n*k2)
Hi Bertram for the square root you will need to implement *Newtons *quadratic
convergence algorithm
And in order to remove the slow division from the inner loop, you'll have
to go for *binary splitting*
There's a nice (and readable) explanation at
http://www.craig-wood.com/nick/articles/pi-chudnovsky/ showing how to do
above in Python - so it's an almost 1:1 to convert to ooRexx.
Still, to get decent performance, you will have to use the gmp library
(above article shows that for the Python implmentation). Unfortunately
ooRexx doesn't yet have an interface to gmp - one of my really long-time
wishes ..
Erich
On Wed, Mar 5, 2014 at 3:52 AM, Bertram Moshier <[email protected]>wrote:
> Hi,
>
> I'm working on a program to compute Pi and noticed two interesting
> situations.
>
> 1. Bug #445 "RxMath functions do not honor precision on Windows" is
> back.
> 2. Something I accept, but can't figure out why and would like to
> understand.
>
> Bug 445: RxMath functions do not honor precision on Windows
>
> The Pi program I'm writing is using Chudnovsky and as such needs the
> square root of K3 to the same precision as the final result (say Pi to
> 100,000 places or even more). Yet, when I call RxCalcSqrt(k3), the number
> of places is only 11, which is not close enough to provide valid results.
> I tried it and the result wasn't even close to the known results of Pi at
> the 100,000 places.
>
> As I read bug 445, Mark closed it as "Committed revision 986." Thus it
> looks like bug 445 is back in 4.2.0 64-bit.
>
> As for the second item: Something just doesn't make sense, as when I
> change the values of the variables used in the MATH (same precision) the
> amount of time it takes to compute is up to 10X longer. The code is the
> same and precision is the same for both runs. I know you need details to
> be specific. The "heart" of the loop is:
>
> s = -s *,
> (6*n) * (6*n-1) * (6*n-2) * (6*n-3) * (6*n-4) * (6*n-5),
> /,
> ((3*n) * (3*n-1) * (3*n-2) * n * n * n * k3_power3)
> t = t + s * (k1 + n*k2)
>
>
> and what I'm seeing is more time spent here when the values for s,
> k3_power3, k1, k2, and t are different, but the precisions are the same.
> They are different because the code supports a fast and normal convergence
> (14 versus 25). The difference is the fast and normal have different
> values for the previously mentioned variables, but the same precision. I'm
> noticing the "fast" is actually 10X slower than the normal. I just don't
> understand why and thus am thinking there is something "inside" Rexx
> causing it to go slower, but what?
>
> Well, thanks for listening. :-)
>
> Bertram Moshier
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Oorexx-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-users
>
>
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Oorexx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-users
