> 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
