Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Bug in numpy.where #369

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
philhodge opened this issue Jul 30, 2012 · 2 comments · Fixed by #395
Closed

Bug in numpy.where #369

philhodge opened this issue Jul 30, 2012 · 2 comments · Fixed by #395

Comments

@philhodge
Copy link

On a Linux machine:

uname -srvop
Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64
GNU/Linux

this example shows a problem with the where function:

Python 2.7.1 (r271:86832, Dec 21 2010, 11:19:43)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import numpy as np
print np.version
1.5.1
net = np.zeros(3, dtype='>f4')
net[1] = 0.00458849
net[2] = 0.605202
max_net = net.max()
test = np.where(net <= 0., max_net, net)
print test
[ -2.23910537e-35 4.58848989e-03 6.05202019e-01]

When I specified the dtype for net as '>f8', test[0] was 3.46244974e+68. It worked as expected (i.e. test[0] should be 0.605202) when I specified float(max_net) as the second argument to np.where.
@seberg
Copy link
Member

seberg commented Aug 3, 2012

Hey, thought about looking a bit at numpy code... and while I don't quite understand it, I think I found the bug. Maybe instead of PyArray_EquivTypes adding check for ->byteorder or such makes more sense.

Here is a Diff fixing the issue for me:

--- a/numpy/core/src/multiarray/scalarapi.c
+++ b/numpy/core/src/multiarray/scalarapi.c
@@ -334,7 +334,7 @@ finish:
     if (outcode == NULL) {
         return (PyObject *)r;
     }
-    if (outcode->type_num == typecode->type_num) {
+    if (PyArray_EquivTypes(outcode, typecode)) {
         if (!PyTypeNum_ISEXTENDED(typecode->type_num)
                 || (outcode->elsize == typecode->elsize)) {
             Py_DECREF(outcode);

@certik certik mentioned this issue Aug 30, 2012
Merged
@certik
Copy link
Contributor

certik commented Aug 30, 2012

@seberg, thank you for your patch. Would you mind reviewing my PR (395) above? I also wrote tests.

@certik certik closed this as completed in ecbd938 Aug 31, 2012
certik added a commit to certik/numpy that referenced this issue Sep 12, 2012
@certik
FIX: bug in np.where and recarray swapping
996a9fb 
Fixes numpy#369 and the Ticket 2185

Thanks to @seberg for providing the patch.
This was referenced Oct 16, 2012
Closed
Closed
luyahan pushed a commit to plctlab/numpy that referenced this issue Apr 25, 2024
@howjmay
Merge pull request numpy#369 from howjmay/vgetq_lane_f64
4cefa0f 
feat: Add vget[q]_lane_f64
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

FIX: bug in np.where and recarray swapping certik/numpy
3 participants
@certik @seberg @philhodge