In investigating, why Numeric does not allow a.real for non-complex
arrays which many have argued that it should, I think I uncovered an old
bug in Numeric.
In looking at the code, it appears that the intention was to have a.real
just return a new array (pointing to the same data as a but having a new
header) whenever a was not a complex array. Unfortunately, the code had
a bug and did not actually return the newly created array. As a result,
the default behavior of raising an "Attribute not found" exception
occurred. But, before this happened, the array the reference count on
the array occurred, thereby springing a memory leak.
Try this out.
a = ones((10,10))
print sys.getrefcount(a)
a.real # will generate an exception
print sys.getrefcount(a)
a.real
print sys.getrefcount(a)
Notice that each time a.real is called the reference count for a goes up
by one even though no object is returned.
I have fixed the bug in Numeric CVS by returning the created object for
a.real.
The end result is that a.real works for all arrays (not just
complex-valued ones).
-Travis O.
On Wed, 2002-12-11 at 16:24, Tim Hochberg wrote:
>
> Here's my latest thinking on this. I'll put this in the form of a proposal
> so that it's easier to comment on. Please comment on part I and part II
> separately.
>
> I. Attributes real and imag/imaginary[1]
>
> All numeric array types (i.e., excluding character and object arrays) would
> have both a real and imag/imaginary attribute. For complex types ('F', 'D')
> this would behave just as it does now. For non-complex types ('i', 'f', 'd',
> etc.), the real attribute would return the object itself, while the
> imaginary attribute would return a ReadOnlyZeroArray [2] of the correct
> shape and typecode. I think that this would provide behaviour consistent
> with the current real and imag attributes on complex arrays without
> introducing and spooky corner cases (that statement is asking for trouble!).
> Examples:
>
> >>> a = array([1,2,3])
> >>> a.real[0] = 99
> >>> a.real
> array([99, 2, 3])
> >>> a.imag
> array([0,0,0])
> >>> a.imag[0] = 99
> TypeError: object is read only.
>
> II. Functions real and imag
>
> Two functions real and imag (or imaginary or both) would be provided. The
> would behave as if they were defined as shown below, even if item I. is not
> adopted.
>
> def real(a):
> return asarray(a).real
>
> def imag(a):
> return asarray(a).imag
>
>
> Comments?
>
> I'm currently +0 on I. and +1 on II.
>
> -tim
>
>
>
> [1] Numeric arrays haveboth imag and imaginary attributes, but they are
> identical. I'm not sure what Numarray's plans are in this regard.
>
> [2] A ReadOnlyZeroArray(shape, typecode) would behave like an array of zeros
> with the given shape and typecode for all non mutating operations. For
> mutation operations (a[x] = b, a += c, etc.) it would raise an exception.
> This object does not actually allocate any space, so creation is fast and
> memory efficient. Implementing this might be the hardest part of the
> proposal.
>
>
> _______________________________________________
> SciPy-user mailing list
> Sci...@sc...
> http://www.scipy.net/mailman/listinfo/scipy-user
|
