[Numpy-discussion] feature request - increment counter on write check

[Sebastian Berg]

On Fr, 2015-09-11 at 06:00 -0700, Daniel wrote:
> >...you would have to "notify" the array itself that it has changed..
> 
> I don't get what you mean..or maybe I do...? Do you mean that if there are
> two arrays with non-overlapping views of the same data then modifying one
> will change the mutablehash of both?  That's true I guess, and I hadn't
> considered it, but I don't think it matters hugely because inequality of
> mutablehashes is not supposed to imply inequality of data.
> 
> 

I just meant you need to propagate the "changed" flag to the parent,
which yes, means that you also propagate it down again (when testing if
a change occured) to other non-overlapping children (which is not a
problem). As Anne said, propagating to the parents usually means only
the ultimate base (there are some exceptions for subclasses IIRC), so it
might be fine. Though there will be failures cases if the ultimate base
is not a numpy array.

As Anne suggested, I think the writable flag is actually a flag, meaning
there is no room for a counter there. There should be room for a "dirty"
flag.

Another issue is, which may be a non-issue, that this design is
inherently not quite thread safe.

Anyway, I do not know whether or not it is doable or makes sense in
numpy right now, just some things to think about.

- Sebastian


> 
> --
> View this message in context: http://numpy-discussion.10968.n7.nabble.com/feature-request-increment-counter-on-write-check-tp41015p41018.html
> Sent from the Numpy-discussion mailing list archive at Nabble.com.
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150911/8e365d8f/attachment.sig>