I would also argue against deprecating these functions that we are using increasingly in several projects that I am involved in.
On Sat, Oct 27, 2018, 01:28 Travis Oliphant <teoliph...@gmail.com> wrote: > What is the justification for deprecation exactly? These functions have > been well documented and have had the intended behavior of producing arrays > with dimension at least 1 for some time. Why is it unexpected to produce > arrays of at least 1 dimension? For some users this is exactly what is > wanted. I don't understand the statement that behavior with 0-d arrays is > unexpected. > > If the desire is to shrink the API of NumPy, I could see that. But, it > seems odd to me to remove a much-used function with an established behavior > except as part of a wider API-shrinkage effort. > > 0-d arrays in NumPy are a separate conversation. At this point, I think > it was a mistake not to embrace 0-d arrays in NumPy from day one. In some > sense 0-d arrays *are* scalars at least conceptually and for JIT-producing > systems that exist now and will be growing in the future, they can be > equivalent to scalars. > > The array scalars should become how you define what is *in* a NumPy array > making them true Python types, rather than Python 1-style "instances" of a > single "Dtype" object. You would then have 0-d arrays and these Python > "memory" types describing what is *in* the array. > > There is a clear way to do this, some of which has been outlined by > Nathaniel, and the rest I have an outline for how to implement. I can > advise someone on how to do this. > > -Travis > > > > > On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov < > alex.rogozhni...@yandex.ru> wrote: > >> Dear numpy community, >> >> I'm planning to depreciate np.asfortranarray and np.ascontiguousarray >> functions due to their misbehavior on scalar (0-D tensors) with PR #12244 >> . >> >> Current behavior (converting scalars to 1-d array with single element) >> - is unexpected and contradicts to documentation >> - probably, can't be changed without breaking external code >> - I believe, this was a cause for poor support of 0-d arrays in mxnet. >> - both functions are easily replaced with asarray(..., order='...'), >> which has expected behavior >> >> There is no timeline for removal - we just need to discourage from using >> this functions in new code. >> >> Function naming may be related to how numpy treats 0-d tensors specially, >> >> and those probably should not be called arrays. >> https://www.numpy.org/neps/nep-0027-zero-rank-arrarys.html >> However, as a user I never thought about 0-d arrays being special and >> being "not arrays". >> >> >> Please see original discussion at github for more details >> https://github.com/numpy/numpy/issues/5300 >> >> Your comments welcome, >> Alex Rogozhnikov >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
