On Thu, Aug 4, 2011 at 10:49 AM, Victor Miller <victorsmil...@gmail.com> wrote: > There's a real bug in Cython. It looks like it's some sort of parsing bug. > Consider the following program: > > > def Check(P,x): > Q = 2**(1+len(x))*P > R = P > for _ in range(1+len(x)): > R = 2*R > if Q != R: > print "Check: Got it!, Q=",Q," R=",R > else: > print "Ok" > def Check0(P,x): > Q = 2**x*P > R = P > for _ in range(x): > R = 2*R > if Q != R: > print "Check0: Check: Got it!, Q=",Q," R=",R > else: > print "Ok" > def Testit(n,m): > x = m*[0] > Check(1,x) > Check0(1,1+len(x)) > Testit(201,100) > > when run as a .py program it prints > > Ok > Ok > > when run as a .pyx program it prints > > Check: Got it!, Q=0, R= 2535301200456458802993406410752 > Ok
Ah hah. It's an overflow bug. 2**(1+len(x)) is computed as a (32- or 64-bit) C value, as the base and exponents are C ints. I'm not sure what the best solution is, short of automatic integer overflow checking and unboxing. Pow is especially tricky. Do we want to force "cdef int a; a**2" to be a Python operation? What about "len(a) * len(b)" or even "len(L) + 1"? An intermediate solution might be to have "overflow-checking" int types, which would be appropriate for implicitly-inferred values (including buildtin return types like len). These would raise a runtime Overflow exception rather than silently giving bad values. A directive could specify that they should be Python objects rather than overflow-raising C values. Correctly and efficiently handling integer arithmetic is just such a pain... - Robert -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
