[Numpy-discussion] real/imag for non complex numbers [was numarray complex comparisons]

[Travis O. <oli...@ie...>]

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