Re: [Numpy-discussion] np.in1d() sets, bug?
Not really, it is simply because ``np.asarray(set([1, 2, 3]))`` returns an object array Holy crap! To be pedantic, it looks like it turns it into a numpy scalar, but still! I wouldn't have expected np.asarray() on a set (or dictionary, for that matter) to work because order is not guaranteed. Is this expected behavior? Digging into the implementation of in1d(), I can see now how passing a set() wouldn't be useful at all (as an aside, pretty clever algorithm). I know sets aren't array-like, but the code that used this seemed to work at first, and this problem wasn't revealed until I created some unit tests to exercise some possible corner cases. Silently producing possibly erroneous results is dangerous. Don't know if better documentation or some better sanity checking would be called for here, though. Ben Root On Mon, Aug 10, 2015 at 1:10 PM, Sebastian Berg sebast...@sipsolutions.net wrote: On Mo, 2015-08-10 at 12:09 -0400, Benjamin Root wrote: Just came across this one today: np.in1d([1], set([0, 1, 2]), assume_unique=True) array([ False], dtype=bool) np.in1d([1], [0, 1, 2], assume_unique=True) array([ True], dtype=bool) I am assuming this has something to do with the fact that order is not guaranteed with set() objects? I was kind of hoping that setting assume_unique=True would be sufficient to overcome that problem. Should sets be rejected as an error? Not really, it is simply because ``np.asarray(set([1, 2, 3]))`` returns an object array and 1 is not the same as ``set([1, 2, 3])``. I think earlier numpy versions may have had short cuts for short lists or something so this may have worked in some cases - Sebastian This was using v1.9.0 Cheers! Ben Root ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.in1d() sets, bug?
On Mon, Aug 10, 2015 at 1:40 PM, Benjamin Root ben.r...@ou.edu wrote: Not really, it is simply because ``np.asarray(set([1, 2, 3]))`` returns an object array Holy crap! To be pedantic, it looks like it turns it into a numpy scalar, but still! I wouldn't have expected np.asarray() on a set (or dictionary, for that matter) to work because order is not guaranteed. Is this expected behavior? Digging into the implementation of in1d(), I can see now how passing a set() wouldn't be useful at all (as an aside, pretty clever algorithm). I know sets aren't array-like, but the code that used this seemed to work at first, and this problem wasn't revealed until I created some unit tests to exercise some possible corner cases. Silently producing possibly erroneous results is dangerous. Don't know if better documentation or some better sanity checking would be called for here, though. Ben Root On Mon, Aug 10, 2015 at 1:10 PM, Sebastian Berg sebast...@sipsolutions.net wrote: On Mo, 2015-08-10 at 12:09 -0400, Benjamin Root wrote: Just came across this one today: np.in1d([1], set([0, 1, 2]), assume_unique=True) array([ False], dtype=bool) np.in1d([1], [0, 1, 2], assume_unique=True) array([ True], dtype=bool) I am assuming this has something to do with the fact that order is not guaranteed with set() objects? I was kind of hoping that setting assume_unique=True would be sufficient to overcome that problem. Should sets be rejected as an error? Not really, it is simply because ``np.asarray(set([1, 2, 3]))`` returns an object array and 1 is not the same as ``set([1, 2, 3])``. I think earlier numpy versions may have had short cuts for short lists or something so this may have worked in some cases is it possible to get at least a UserWarning when creating an object array and dtype object hasn't been explicitly requested or underlying data is already in an object dtype? Josef - Sebastian This was using v1.9.0 Cheers! Ben Root ___ 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 ___ 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
Re: [Numpy-discussion] np.in1d() sets, bug?
Another case where refusing to implicitly create object arrays would have avoided a lot of confusion... On Aug 10, 2015 10:13 AM, Sebastian Berg sebast...@sipsolutions.net wrote: On Mo, 2015-08-10 at 12:09 -0400, Benjamin Root wrote: Just came across this one today: np.in1d([1], set([0, 1, 2]), assume_unique=True) array([ False], dtype=bool) np.in1d([1], [0, 1, 2], assume_unique=True) array([ True], dtype=bool) I am assuming this has something to do with the fact that order is not guaranteed with set() objects? I was kind of hoping that setting assume_unique=True would be sufficient to overcome that problem. Should sets be rejected as an error? Not really, it is simply because ``np.asarray(set([1, 2, 3]))`` returns an object array and 1 is not the same as ``set([1, 2, 3])``. I think earlier numpy versions may have had short cuts for short lists or something so this may have worked in some cases - Sebastian This was using v1.9.0 Cheers! Ben Root ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.in1d() sets, bug?
On Mo, 2015-08-10 at 12:09 -0400, Benjamin Root wrote: Just came across this one today: np.in1d([1], set([0, 1, 2]), assume_unique=True) array([ False], dtype=bool) np.in1d([1], [0, 1, 2], assume_unique=True) array([ True], dtype=bool) I am assuming this has something to do with the fact that order is not guaranteed with set() objects? I was kind of hoping that setting assume_unique=True would be sufficient to overcome that problem. Should sets be rejected as an error? Not really, it is simply because ``np.asarray(set([1, 2, 3]))`` returns an object array and 1 is not the same as ``set([1, 2, 3])``. I think earlier numpy versions may have had short cuts for short lists or something so this may have worked in some cases - Sebastian This was using v1.9.0 Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] np.in1d() sets, bug?
Just came across this one today: np.in1d([1], set([0, 1, 2]), assume_unique=True) array([ False], dtype=bool) np.in1d([1], [0, 1, 2], assume_unique=True) array([ True], dtype=bool) I am assuming this has something to do with the fact that order is not guaranteed with set() objects? I was kind of hoping that setting assume_unique=True would be sufficient to overcome that problem. Should sets be rejected as an error? This was using v1.9.0 Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
