> 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]. > > [1] as_strided does not currently support arr.flags.writable = True for its result array.
Can you explain this in more detail? I'm writing to the result without problem. Anyway, it only occurred to me after your response that the deprecation path would be quite disruptive to downstream libraries, including scikit-image. My feeling is that unless someone has been bitten by this (?), the benefit does not outweigh the cost of deprecation. Perhaps something to push to 2.0? On Sun, Jan 24, 2016 at 8:17 PM, Sebastian Berg <sebast...@sipsolutions.net> wrote: > 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 > > _______________________________________________ > 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
