On Wed, 2009-01-28 at 20:11 -0500, sam lee wrote:
Did you print it? I'm using same code with ghc --make -O2 and it takes forever to finish.
Yes, you can see in the output that it prints the same answer in each case. I was using r = 10^9 as you suggested.
I wouldn't call these answers the same. Can this be ascribed to an overflow error?
C version: $ time ./circ 3141592649589764829
^^
Haskell version: time ./circ2 3141592653589764829
^^ John Lato
On Thu, 2009-01-29 at 10:35 +0000, John Lato wrote:
On Wed, 2009-01-28 at 20:11 -0500, sam lee wrote:
Did you print it? I'm using same code with ghc --make -O2 and it takes forever to finish.
Yes, you can see in the output that it prints the same answer in each case. I was using r = 10^9 as you suggested.
I wouldn't call these answers the same. Can this be ascribed to an overflow error?
Oh yes, you're quite right. I didn't notice because it only affects the middle digits :-)
C version: $ time ./circ 3141592649589764829 ^^
Haskell version: time ./circ2 3141592653589764829
Compare: circ2 r = (1+4*r) + 4 * (circ2' (rs+1) r 1 0) vs # the main loop } sum*=4; sum++; Looks like the C version misses the +4*r at the end. 3141592649589764829 + 4*10^9 = 3141592653589764829 Assuming that's right, the mistake only costs constant-time and doesn't invalidate the timings. Duncan
On Thu, Jan 29, 2009 at 11:30 AM, Duncan Coutts
On Thu, 2009-01-29 at 10:35 +0000, John Lato wrote:
On Wed, 2009-01-28 at 20:11 -0500, sam lee wrote:
Did you print it? I'm using same code with ghc --make -O2 and it takes forever to finish.
Yes, you can see in the output that it prints the same answer in each case. I was using r = 10^9 as you suggested.
I wouldn't call these answers the same. Can this be ascribed to an overflow error?
Oh yes, you're quite right. I didn't notice because it only affects the middle digits :-)
C version: $ time ./circ 3141592649589764829 ^^
Haskell version: time ./circ2 3141592653589764829
Compare:
circ2 r = (1+4*r) + 4 * (circ2' (rs+1) r 1 0)
vs
# the main loop } sum*=4; sum++;
Looks like the C version misses the +4*r at the end.
3141592649589764829 + 4*10^9 = 3141592653589764829
Assuming that's right, the mistake only costs constant-time and doesn't invalidate the timings.
Thank you. That explains it nicely. Giving credit where it's due, Lennart A. also pointed out that the difference is 4e9 and suspected a boundary case. I think I need more coffee today :) John Lato
participants (2)
-
Duncan Coutts -
John Lato