Zachary Pincus wrote:

>  In answer to my previous question, to get an ndarray subclass that  
>  owns its own data, copy() must be called on the new "view" of the  
>  subclass. This makes sense and is reasonable.
> 
>  However a new problem has me nearly tearing my hair out. Calling the  
>  resize method on an instance of such a subclass works fine. However,  
>  calling a method that calls 'self.resize' breaks! And worse, it  
>  breaks in such a way that then subsequent calls to resize also break.


Yeah, this is one difficult aspect of the resize method.  Because memory 
is being re-allocated, the method has to make sure the memory isn't 
being shared by another object.   Right now, it's checking the reference 
count.  Unfortunately, that isn't a fool-proof mechanism as you've 
discovered, because a reference can be held onto in somewhat 
unpredictable ways that would not be bothered by a resize on the memory 
and this messes up the resize method. 

What is really needed is someway to determine if any other object is 
actually pointing to the memory of the ndarray (and not just holding on 
to the object).  But, nobody has figured out a way to do that.

It would be possible to let the user "force" the issue leaving it up to 
them to make sure they don't share the memory and then reallocate it.  
In other words, an extra argument to the resize method could be used to 
bypass the memory check.   I'd be willing to do that because I know the 
check being performed is not foolproof

-Travis




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@[...].net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion