> If the desire is to shrink the API of NumPy, I could see that.
Very good desire, but my goal was different.
> For some users this is exactly what is wanted.
Maybe so, but I didn't face such example (and nobody mentioned those so far in the discussion).
The opposite (according to the issue) happened. Mxnet example is sufficient in my opinion.
Simple example:
x = np.zeros([])
assert(x.flags.c_contiguous)
assert(np.ascontiguousarray(x).shape == x.shape)
Behavior contradicts to documentation (shape is changed) and to name (flags are saying - it is already c_contiguous)
If you insist, that keeping ndmin=1 is important (I am not yet convinced, but I am ready to believe your autority),
we can add ndmin=1 to functions' signatures, this way explicitly notifying users about expected dimension.
Alex.
27.10.2018, 02:27, "Travis Oliphant" <teoliph...@gmail.com>:
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.ascontiguousarrayfunctions 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 behaviorThere 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.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 detailsYour 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
