Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Bertram Moshier <bertrammoshier@gm...>  20140305 02:52:57
Attachments:
Message as HTML

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 64bit. 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*n1) * (6*n2) * (6*n3) * (6*n4) * (6*n5), /, ((3*n) * (3*n1) * (3*n2) * 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 
From: Mark Miesfeld <miesfeld@gm...>  20140305 05:03:40
Attachments:
Message as HTML

On Tue, Mar 4, 2014 at 6:52 PM, Bertram Moshier <bertrammoshier@...>wrote: > > 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. > >From the rxmath doc: The precision of calculation depends on: * The value specified when the command is issued * The numeric digits settings of the calling Rexx activity Note Precision is limited to 16 digits. So, you are not going to get a precision greater than 16 digits no matter what you do. Try this: RxCalcSqrt(k3, 16) So, you can specify the precision as a second argument, but it can't be greater than 16. The rxmath package is just an interface to the C math library and has all the restrictions of that library. > 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 64bit. > The bug was that when digits was set to 6 (or 5, or 4) the answer had the same precision as when digits was 9. In other words, it was not honoring digits 6. That bug is not back. As for the second item Bert, I don't know. ;) It's the kind of thing that doesn't really interest me. Maybe someone else will pipe up on that.  Mark Miesfeld 
From: Erich Steinböck <erich.steinboeck@gm...>  20140305 10:36:47
Attachments:
Message as HTML

> > s = s *, > (6*n) * (6*n1) * (6*n2) * (6*n3) * (6*n4) * (6*n5), > /, > ((3*n) * (3*n1) * (3*n2) * 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.craigwood.com/nick/articles/pichudnovsky/ 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 longtime wishes .. Erich On Wed, Mar 5, 2014 at 3:52 AM, Bertram Moshier <bertrammoshier@...>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 64bit. > > 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*n1) * (6*n2) * (6*n3) * (6*n4) * (6*n5), > /, > ((3*n) * (3*n1) * (3*n2) * 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 hasslefree workflows. Merge that actually works. > Faster operations. Version large binaries. Builtin 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 > _______________________________________________ > Oorexxusers mailing list > Oorexxusers@... > https://lists.sourceforge.net/lists/listinfo/oorexxusers > > 
From: Moritz Hoffmann <antiguru@gm...>  20140305 11:01:23

BEGIN PGP SIGNED MESSAGE Hash: SHA256 On 03/05/2014 11:36 AM, Erich Steinböck wrote: > s = s *, (6*n) * (6*n1) * (6*n2) * (6*n3) * (6*n4) * (6*n5), > /, ((3*n) * (3*n1) * (3*n2) * n * n * n * k3_power3) t = t + s * > (k1 + n*k2) [...] > 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 longtime wishes .. > > Erich gmp would be the right thing to chose for doing arbitraryprecision calculations. Rexx is nice with the numeric digits settings, but it's not very optimized. Also, you can optimize the instruction yourself to some extent: extract common subexpressions (e.g. 6*n) to avoid them being evaluated more often than necessary. ooRexx does not perform any rewriting of the program, so it's all executed as written by the programmer. Using gmp with c++ is more convenient as it supports operator overloading. Using gmp with cgal is even more fun! http://doc.cgal.org/latest/Manual/ (It has nice c++ wrappers for gmp) Moritz   Moritz Hoffmann http://antiguru.de/ BEGIN PGP SIGNATURE Version: GnuPG v1 Comment: Using GnuPG with Icedove  http://www.enigmail.net/ iF4EAREIAAYFAlMXA/UACgkQ264ap80Va8eEtAD9EUKN/wrsazIw+oZnEJVv0z5G ng3XjVALnW17nPUnIaQA/36JDTTxUJlO8fsGxg6zTMgEhEByCLdaho0+kmnIVKIt =9hQ2 END PGP SIGNATURE 
From: David Ashley <w.ashley@gm...>  20140305 15:25:48

Erich  I invite you to look at the following file in the ooRexx SVN repository. http://sourceforge.net/p/oorexx/code0/HEAD/tree/incubator/ZabrodskyAAT/ZabrodskyAAT.cls This file contains some extremely useful math functions written entirely in Rexx. Therefore they all can be pushed to the 100 digit limit currently imposed by ooRexx. There is a precomputed value for pi already in the library but there should be enough there for you to write the program you want. David Ashley 