<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 7:14 PM Alex Rogozhnikov <<a href="mailto:alex.rogozhnikov@yandex.ru">alex.rogozhnikov@yandex.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> If the desire is to shrink the API of NumPy, I could see that.</div><div> </div><div>Very good desire, but my goal was different. </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div><div>> For some users this is exactly what is wanted.</div><div> </div><div>Maybe so, but I didn't face such example (and nobody mentioned those so far in the discussion).</div><div>The opposite (according to the issue) happened. Mxnet example is sufficient in my opinion.</div></blockquote><div><br></div><div>I agree that the old motivation of APIs that would make it easy to create SciPy is no longer a major motivation for most users and even developers and so these reasons would not be very present (as well as why it wasn't even mentioned in the documentation).  </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div><div>Simple example:</div><div><span style="font-family:courier new,monospace">x = np.zeros([])</span></div><div><span style="font-family:courier new,monospace">assert(x.flags.c_contiguous)</span></div><div><span style="font-family:courier new,monospace">assert(np.ascontiguousarray(x).shape == x.shape)</span></div><div> </div><div><span style="font-family:courier new,monospace">Behavior contradicts to documentation (shape is changed) and to name (flags are saying - it is already c_contiguous)</span></div><div> </div><div>If you insist, that keeping ndmin=1 is important (I am not yet convinced, but I am ready to believe your autority),</div><div>we can add ndmin=1 to functions' signatures, this way explicitly notifying users about expected dimension.</div></blockquote><div><br></div><div>I understand the lack of being convinced.  This is ultimately a problem of 0-d arrays not being fully embraced and accepted by the Numeric community originally (which NumPy inherited during the early days).   Is there a way to document functions that will be removed on a major version increase which don't print warnings on use? I would support this.</div><div><br></div><div>I'm a big supporter of making a NumPy 2.0 and have been for several years. Now that Python 3 transition has happened, I think we could seriously discuss this.  I'm trying to raise funding for maintenance and progress for NumPy and SciPy right now via Quansight Labs <a href="http://www.quansight.com/labs">http://www.quansight.com/labs</a> and I hope to be able to help find grants to support the wonderful efforts that have been happening for some time. <br></div><div><br></div><div>While I'm thrilled and impressed by the number of amazing devs who have kept NumPy and SciPy going in mostly their spare time, it has created challenges that we have not had continuous maintenance funding to allow continuous paid development so that several people who know about the early decisions could not be retained to spend time on helping the transition.  </div><div><br></div><div>Your bringing the problem of mxnet devs is most appreciated.  I will make a documentation PR.</div><div><br></div><div>-Travis</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div><div>Alex.</div><div> </div><div> </div><div>27.10.2018, 02:27, "Travis Oliphant" <<a href="mailto:teoliphant@gmail.com" target="_blank">teoliphant@gmail.com</a>>:</div><blockquote type="cite"><div>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.<div> </div><div>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. </div><div> </div><div>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.  </div><div> </div><div>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.  </div><div> </div><div>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.  </div><div> </div><div>-Travis</div><div> </div><div> </div><div> </div></div> <div><div>On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <<a rel="noopener noreferrer" href="mailto:alex.rogozhnikov@yandex.ru" target="_blank">alex.rogozhnikov@yandex.ru</a>> wrote:</div><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Dear numpy community,</div><div> </div><div>I'm planning to depreciate np.asfortranarray and np.ascontiguousarray</div><div>functions due to their misbehavior on scalar (0-D tensors) with PR <span>#12244</span>.</div><div> </div><div>Current behavior (converting scalars to 1-d array with single element)</div><div>- is unexpected and contradicts to documentation</div><div>- probably, can't be changed without breaking external code</div><div>- I believe, this was a cause for poor support of 0-d arrays in mxnet.</div><div>- both functions are easily replaced with asarray(..., order='...'), which has expected behavior</div><div> </div><div>There is no timeline for removal - we just need to discourage from using this functions in new code.</div><div> </div><div>Function naming may be related to how numpy treats 0-d tensors specially,  </div><div>and those probably should not be called arrays.</div><div><div><a rel="noopener noreferrer" href="https://www.numpy.org/neps/nep-0027-zero-rank-arrarys.html" target="_blank">https://www.numpy.org/neps/nep-0027-zero-rank-arrarys.html</a></div><div>However, as a user I never thought about 0-d arrays being special and being "not arrays".</div><div> </div></div><div> </div><div>Please see original discussion at github for more details</div><div><a rel="noopener noreferrer" href="https://github.com/numpy/numpy/issues/5300" target="_blank">https://github.com/numpy/numpy/issues/5300</a></div><div> </div><div>Your comments welcome,</div><div>Alex Rogozhnikov<br> </div>_______________________________________________<br>NumPy-Discussion mailing list<br><a rel="noopener noreferrer" href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br><a rel="noopener noreferrer" href="https://mail.python.org/mailman/listinfo/numpy-discussion" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a></blockquote></div>,<p>_______________________________________________<br>NumPy-Discussion mailing list<br><a rel="noopener noreferrer" href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br><a rel="noopener noreferrer" href="https://mail.python.org/mailman/listinfo/numpy-discussion" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a></p></blockquote>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div>