Hi again Danny, Very interesting note, thanks for the details. The problem is a slightly easier version of one the ProjectEuler.net problems (see here: http://projecteuler.net/problem=210) Basically the hard part of the problem is finding the grid points that fall in a circle with origin at (12500000, 12500000) with radius = ldiv8xrad2 (sqrt(2)*100000000/8).
-Joe On Tue, Jun 4, 2013 at 4:20 PM, Danny Yoo <[email protected]> wrote: > > Yes, makes perfect sense, hmmm... there's probably a way to avoid so many >> sqrt calls. >> > > This probably won't help. No individual iteration in that inner loop is > beyond 32 bits. The accumulated sum itself is what grows beyond the bounds > of a 32-bit representation. Reducing the number of sqrt calls is likely > not to noticeably improve the runtime performance on 32-bit platforms: the > dominant part of your runtime is the fact that bignum operations will not > be constant time for the quantities your program is working with. > > If you can tell us more about the problem domain, maybe we can suggest > improvements. It looks like it's a numerical computation of something. Do > you need the result to be exact? What is it actually computing, and why? > > > > How do you like Go? How is the performance on this code? >> > > I can't say anything too informed about it yet. I just started learning > it a few days ago. As far as compile and run times are concerned, here's > what I see: > > ###### > bash-3.2$ time go build euler210.go > real 0m0.193s > user 0m0.152s > sys 0m0.037s > > bash-3.2$ time ./euler210 > 15981747679237090 > > real 0m0.117s > user 0m0.112s > sys 0m0.003s > > bash-3.2$ time raco make euler210.rkt > > real 0m0.291s > user 0m0.211s > sys 0m0.058s > bash-3.2$ time racket euler210.rkt > 15981747679237090 > > real 0m0.803s > user 0m0.736s > sys 0m0.037s > ###### > > Note that my Go version is "cheating" in a sense: I kept changing the size > of the numeric representations until I stopped seeing differences from the > canonical Racket version. What I've got is not backed by any kind of > numeric tower. If I were to really write it in a way that tries to do a > better job at preserving the meaning of the program, I'd need to add a > whole bunch of references to Go's math/big library, and be very careful in > doing so. >
____________________ Racket Users list: http://lists.racket-lang.org/users
