My vote is for an Overflow exception. Certainly doing nothing is not good.
Victor On Aug 4, 3:05 pm, Robert Bradshaw <[email protected]> wrote: > On Thu, Aug 4, 2011 at 10:49 AM, Victor Miller <[email protected]> > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
