Hi All, This is apropos gh-5582 <https://github.com/numpy/numpy/pull/5582> dealing with some corner cases of np.where. The following are the current behavior
import numpy numpy.where(True) # case 1 ... (array([0]),) numpy.where(True, None, None) # case 2 ... array(None, dtype=object) numpy.ma.where(True) # case 3 ... (array([0]),) numpy.ma.where(True, None, None) # case 4 ... (array([0]),)
The question is, what exactly should be done in these cases? I'd be inclined to raise an error for cases 1 and 3. Case two looks correct to me if we agree that scalar inputs are acceptable. Case 4 looks wrong. Thoughts? Chuck
On Mar 12, 2015 5:02 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
Hi All,
This is apropos gh-5582 dealing with some corner cases of np.where. The
following are the current behavior
import numpy numpy.where(True) # case 1 ... (array([0]),) numpy.where(True, None, None) # case 2 ... array(None, dtype=object) numpy.ma.where(True) # case 3 ... (array([0]),) numpy.ma.where(True, None, None) # case 4 ... (array([0]),)
The question is, what exactly should be done in these cases? I'd be
inclined to raise an error for cases 1 and 3. Case two looks correct to me if we agree that scalar inputs are acceptable. Case 4 looks wrong. I can't think of any reason scalars wouldn't be acceptable. So everything you suggest sounds right to me. -n Hi All, This is apropos gh-5582 <https://github.com/numpy/numpy/pull/5582> dealing with some corner cases of np.where. The following are the current behavior
import numpy numpy.where(True) # case 1 ... (array([0]),) numpy.where(True, None, None) # case 2 ... array(None, dtype=object) numpy.ma.where(True) # case 3 ... (array([0]),) numpy.ma.where(True, None, None) # case 4 ... (array([0]),)
The question is, what exactly should be done in these cases? I'd be inclined to raise an error for cases 1 and 3. Case two looks correct to me if we agree that scalar inputs are acceptable. Case 4 looks wrong. Thoughts? Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I think the question is if scalars should be acceptable for the first argument, not if it should be for the 2nd and 3rd argument. If scalar can be given for the first argument, the the first three makes sense. Although, I have no clue why we would allow that. Ben Root On Mar 12, 2015 9:25 PM, "Nathaniel Smith" <njs@pobox.com> wrote:
On Mar 12, 2015 5:02 PM, "Charles R Harris" <charlesr.harris@gmail.com> wrote:
Hi All,
This is apropos gh-5582 dealing with some corner cases of np.where. The
following are the current behavior
import numpy numpy.where(True) # case 1 ... (array([0]),) numpy.where(True, None, None) # case 2 ... array(None, dtype=object) numpy.ma.where(True) # case 3 ... (array([0]),) numpy.ma.where(True, None, None) # case 4 ... (array([0]),)
The question is, what exactly should be done in these cases? I'd be
inclined to raise an error for cases 1 and 3. Case two looks correct to me if we agree that scalar inputs are acceptable. Case 4 looks wrong.
I can't think of any reason scalars wouldn't be acceptable. So everything you suggest sounds right to me.
-n Hi All,
This is apropos gh-5582 <https://github.com/numpy/numpy/pull/5582> dealing with some corner cases of np.where. The following are the current behavior
import numpy numpy.where(True) # case 1 ... (array([0]),) numpy.where(True, None, None) # case 2 ... array(None, dtype=object) numpy.ma.where(True) # case 3 ... (array([0]),) numpy.ma.where(True, None, None) # case 4 ... (array([0]),)
The question is, what exactly should be done in these cases? I'd be inclined to raise an error for cases 1 and 3. Case two looks correct to me if we agree that scalar inputs are acceptable. Case 4 looks wrong.
Thoughts?
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Mar 12, 2015 at 9:35 PM, Benjamin Root <ben.root@ou.edu> wrote:
I think the question is if scalars should be acceptable for the first argument, not if it should be for the 2nd and 3rd argument.
If scalar can be given for the first argument, the the first three makes sense. Although, I have no clue why we would allow that.
Why wouldn't we? The where function takes three arguments which are broadcast against each other, so disallowing scalars would require adding a special case. -n -- Nathaniel J. Smith -- http://vorpus.org
On Fri, Mar 13, 2015 at 1:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Mar 12, 2015 at 9:35 PM, Benjamin Root <ben.root@ou.edu> wrote:
I think the question is if scalars should be acceptable for the first argument, not if it should be for the 2nd and 3rd argument.
If scalar can be given for the first argument, the the first three makes sense. Although, I have no clue why we would allow that.
Why wouldn't we? The where function takes three arguments which are broadcast against each other, so disallowing scalars would require adding a special case.
I'm coming to the conclusion that only #4 is incorrect. The process seems to go: cast scalars to 1-D arrays (hence #1 and #3), and indexing results in #2. The oddity is that the second and third arguments are optional, and the action of the function depends on that. I would have made those arguments required as omitting them gives the same as a call to nonzero. But things are as they are... Chuck
On Fri, Mar 13, 2015 at 2:09 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Fri, Mar 13, 2015 at 1:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Mar 12, 2015 at 9:35 PM, Benjamin Root <ben.root@ou.edu> wrote:
I think the question is if scalars should be acceptable for the first argument, not if it should be for the 2nd and 3rd argument.
If scalar can be given for the first argument, the the first three makes sense. Although, I have no clue why we would allow that.
Why wouldn't we? The where function takes three arguments which are broadcast against each other, so disallowing scalars would require adding a special case.
I'm coming to the conclusion that only #4 is incorrect. The process seems to go: cast scalars to 1-D arrays (hence #1 and #3), and indexing results in #2.
The oddity is that the second and third arguments are optional, and the action of the function depends on that. I would have made those arguments required as omitting them gives the same as a call to nonzero. But things are as they are...
To summarize, np.where is OK as is, np.ma.where needs fixing. As for deprecating the use of np.where as np.nonzero, that looks very easy to do in the code. However, the PyArray_Where function is in the numpy C-API so we might want to be careful about doing that. Chuck
On Thu, Mar 12, 2015 at 5:02 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
This is apropos gh-5582 dealing with some corner cases of np.where. The following are the current behavior
import numpy numpy.where(True) # case 1 ... (array([0]),) numpy.where(True, None, None) # case 2 ... array(None, dtype=object) numpy.ma.where(True) # case 3 ... (array([0]),) numpy.ma.where(True, None, None) # case 4 ... (array([0]),)
The question is, what exactly should be done in these cases? I'd be inclined to raise an error for cases 1 and 3.
Actually, I forgot about the annoying thing where np.where is two-functions-for-the-price-of-one, and np.where(x) is equivalent to np.nonzero(asarray(x)). That's documented, and is what's happening in cases 1 and 3. So I take back my previous email: I'm -1 on specifically making np.where(scalar) into an error -- we should either consistently stick with the current nonzero() behavior, or consistently remove it. I'd be happy with deprecating np.where(x) entirely and eventually making it an error, since it's just a weird ugly alias for nonzero(). (Case 2 still looks correct to me, and case 4 just looks like an accidental side-effect of someone being lazy and using None to mean "not specified".) -n -- Nathaniel J. Smith -- http://vorpus.org
participants (3)
-
Benjamin Root -
Charles R Harris -
Nathaniel Smith