On Mar 3, 2008, at 7:52 AM, David Roe wrote: > I was not suggesting eliminating the ability to directly > access .value from Cython. Rather, I see set_si() and get_si() as > convenience functions so that if the only thing you're doing is > converting back and forth between sage integer and long, one can > use object oriented notation (and so that you don't have to rewrite > the overflow checking each time: I've done that over and over).
What overflow code is to be written with set_si? I can understand the OO notation bit, but really I think a better solution would be to have a function that makes a new Integer object from a long. > On Mon, Mar 3, 2008 at 10:34 AM, Carl Witty <[EMAIL PROTECTED]> > wrote: > > On Mar 3, 5:42 am, "David Roe" <[EMAIL PROTECTED]> wrote: > > I think they should still exist, but should be cdef'd. This > means I can > > interface between C longs and sage Integers without having to > reach in and > > grab n.value, but one can't use them to make Integers mutable in > Python. A > > function get_si() would also be useful if it did bounds checking > so that I > > don't have to worry about the mpz_t not fitting in a long. > > David > > I disagree. I think we should either allow the use of .value in > Cython code or ensure that the WHOLE of the GMP API is available > through methods on Integer. Since the latter is a huge chunk of work > for no benefit, I think the former is the way to go. > > So +1 for deleting the methods. +1 I agree with this (for the set_* methods). - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
