On So, 2016-01-24 at 13:00 +1100, Juan Nunez-Iglesias wrote: > I've used as_strided before to create an "endless" output array when > I didn't care about the result of an operation, just the side effect. > See eg here. So I would certainly like option to remain to get a > writeable array. In general, I'm sceptical about whether the benefits > outweigh the costs.
Yeah, that is a real use case. I am not planning to remove the option, but it would be as a `readonly` keyword argument, which means you would need to make the code depend on the numpy version if you require a writable array [1]. This actually somewhat defeats the purpose of all of this, but `np.ndarray` can do this dummy thing for you I think, so you could get around that, but.... The purpose is that if you actually would use an as_strided array in your operation, the result is unpredictable (not just complicated). And while as_strided is IMO designed to be used by people who know what they are doing, I have a feeling it is being used quite a lot in general. We did a similar thing for the new `broadcast_to`, though I think there we decided to skip the readonly until complains happen. Actually there is one more thing I might do. And that is issue a UserWarning when new array quite likely points to invalid memory. - Sebastian [1] as_strided does not currently support arr.flags.writable = True for its result array. > On Sun, Jan 24, 2016 at 9:20 AM, Nathaniel Smith <n...@pobox.com> > wrote: > > On Sat, Jan 23, 2016 at 1:25 PM, Sebastian Berg > > <sebast...@sipsolutions.net> wrote: > > > > > > Hi all, > > > > > > I have just opened a PR, to make as_strided writeonly (as > > default). The > > > > I think you meant readonly :-) > > > > > reasoning for this change is that an `as_strided` array often > > have self > > > overlapping memory. However, writing to an array where multiple > > > elements have the identical memory address can be confusing, and > > the > > > results are typically unpredictable. > > > > > > Considering the danger, the proposal is to add a `readonly=True`. > > A > > > poweruser (who that function is designed for anyway), could thus > > still > > > get a writeable array. > > > > > > For the moment, writing to the result would raise a FutureWarning > > with > > > `readonly="warn"`. > > > > This should just be a deprecation warning, right? (Because > > switching > > an array from writeable->readonly might cause previously correct > > code > > to error out, but not to silently start returning different > > results.) > > > > > Do you agree with this, or would it be a major inconvenience? > > > > AFAIK the only use cases for as_strided involve self-overlap (for > > non-self-overlap you can generally use reshape / indexing / etc. > > and > > it's much simpler). So +1 from me. > > > > -n > > > > -- > > Nathaniel J. Smith -- https://vorpus.org > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
