<div dir="ltr">Hi Danny,<div><br></div><div style>Yes, makes perfect sense, hmmm... there&#39;s probably a way to avoid so many sqrt calls.</div><div style><br></div><div style>How do you like Go?  How is the performance on this code?</div>
<div style><br></div><div style>Thanks,</div><div style>-joe</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 12:59 PM, Danny Yoo <span dir="ltr">&lt;<a href="mailto:dyoo@hashcollision.org" target="_blank">dyoo@hashcollision.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Some of the involved numbers are bigger than can be represented in 32 bits.  Therefore, the computation on 32 bit platforms will need to use more software-emulated bigintegers to perform the computation successfully, and that&#39;s where the performance difference is coming from.<div>


<br></div><div><br></div><div>I played with this by rewriting the code in another language, Go, just out of curiosity:</div><div><br></div><div><div>    <a href="https://gist.github.com/dyoo/5708928" target="_blank">https://gist.github.com/dyoo/5708928</a></div>


<div class="gmail_extra"><br></div><div class="gmail_extra">If we switch out the representation from int64 to int32, for example, we&#39;ll see that the result is wrong.  So it&#39;s very much a data representation issue.</div>


<div class="gmail_extra"><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">The sum you&#39;re accumulating altogether is:</div><div class="gmail_extra"><br></div><div class="gmail_extra">

    15981747679237090<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">which is an integer that&#39;s much bigger than natively representable with 32 bits.</div></div>
</blockquote></div><br></div>