On 9/27/07, Bill Page <[EMAIL PROTECTED]> wrote: > > On 9/27/07, Fernando Perez wrote: > > > > On 9/27/07, Robert Bradshaw wrote: > > > > > You have a good point, though fortunately we're looking for refcounts > > > so low that (essentially) nothing else can be holding onto it but the > > > current stack frame. If b is pointing to a, it doesn't matter how > > > many other things are (directly or indirectly). If nothing is > > > pointing to it directly, it's difficult (but not impossible) for > > > things to safely point to it indirectly. Also, we would only play > > > this trick with SAGE elements, which we have more control over. > > > > The subtlety appears if the object you're dealing with is itself a > > view of something else: > > > > In [3]: a = N.arange(10) > > > > In [4]: b = a[::2] > > > > In [5]: sys.getrefcount(b) > > Out[5]: 2 > > > > In [6]: sys.getrefcount(a) > > Out[6]: 3 > > > > I think there might be some confusion here over what is an "object" > and what is a "reference" to an object. The first object here is the > result of 'N.arange(10)'.
The problematic issue is that some extensions (numpy first and foremost, but this buffer API is going into the core of the language for 2.6/3.0) allow multiple, distinct *python objects* to share the same (or parts of the same) chunk of raw memory. The refcount mechanism only tracks python objects, not raw memory. Hopefully this helps: In [12]: a = N.arange(10) In [13]: sys.getrefcount(a) Out[13]: 2 Here the refcount is 2, as expected: the original array and the name 'a' pointing to it. Now, a naked, unassigned slice of the original array has a refcount of 1: In [14]: sys.getrefcount(a[::2]) Out[14]: 1 And yet, modifying it in-place has an effect on the original object (which we have called 'a'): In [15]: a[::2].fill(999) In [16]: a Out[16]: array([999, 1, 999, 3, 999, 5, 999, 7, 999, 9]) The slice 'a[::2]' has a refcount of 1, so it appears 'safe' from a purely refcounting argument. But it actually shares memory with the original N.arange(10) object, so it can overwrite it. Note that I'm only pointing this out as a word of caution that there are cases where refcounting arguments can be a bit delicate. The basic idea of reusing in-place objects as an optimization is a very good one for cases where you know that your underlying objects simply don't expose any interface for antics like the above. Cheers, f --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
