numexpr.evaluate result type != numpy type

[GoogleCodeExporter]

E.g:

a = np.array([1], np.int32)
b=ne.evaluate('a')
print a.dtype.type,b.dtype.type
print a.dtype.type==b.dtype.type
print a.dtype.type==np.int32
print b.dtype.type==np.int32

Expected output:
<type 'numpy.int32'> <type 'numpy.int32'>
True
True
True

Actual output:
<type 'numpy.int32'> <type 'numpy.int32'>
False
True
False

Original issue reported on code.google.com by lukepinn...@gmail.com on 29 Aug 2013 at 5:24

[GoogleCodeExporter]

Forgot to mention, I'm not doing the type checking. I'm using the GDAL library 
(http://gdal.org) which does the type checking when writing ndarrays to 
geospatial raster files (http://gdal.org/python/osgeo.gdal_array-module.html)

Original comment by lukepinn...@gmail.com on 29 Aug 2013 at 5:29

[GoogleCodeExporter]

Hmm, your code works for me:

<type 'numpy.int32'> <type 'numpy.int32'> True True True

This is my environment:

$ PYTHONPATH=. python -c"import numexpr; numexpr.print_versions()" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Numexpr version: 2.1.1.dev NumPy version: 1.7.1 Python version: 2.7.5 |Anaconda 1.6.1 (64-bit)| (default, Jun 28 2013, 22:10:09) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] Platform: linux2-x86_64 AMD/Intel CPU? True VML available? False Number of threads used by default: 4 (out of 4 detected cores) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Can you send yours please?

Original comment by fal...@gmail.com on 29 Aug 2013 at 8:57

• Changed state: Started

[GoogleCodeExporter]

Win 7 Enterprise 64bit

64bit python
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Numexpr version:   2.1
NumPy version:     1.6.2
Python version:    2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit 
(AMD64)]
AMD/Intel CPU?     True
VML available?     False
Detected cores:    4
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

32bit python
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Numexpr version:   2.1
NumPy version:     1.6.2
Python version:    2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit 
(Intel)]
AMD/Intel CPU?     True
VML available?     False
Detected cores:    4
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Interestingly it works fine on my Ubuntu 12.04 box
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Numexpr version:   1.4.2
NumPy version:     1.6.1
Python version:    2.7.3 (default, Apr 10 2013, 06:20:15) 
[GCC 4.6.3]
Platform:          linux2-x86_64
AMD/Intel CPU?     True
VML available?     False
Detected cores:    6
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Original comment by lukepinn...@gmail.com on 30 Aug 2013 at 12:54

[GoogleCodeExporter]

Also tried with numpy 1.6.1 and 1.7.0 on Win 7 with 32bit python, no changes to 
numexpr/python versions. Same result as original report.

Original comment by lukepinn...@gmail.com on 30 Aug 2013 at 1:49

[GoogleCodeExporter]

Uh, so apparently NumPy on Windows is messing things up.  Well, the print of 
the dtypes seems to suggest that numexpr is indeed creating an 'int32'  
correctly, so not sure why the type equality should not work in this case.

I would say that this is a problem with NumPy on Windows.  Could you please 
file a ticket on github NumPy and tell us the result of your findings?

Original comment by fal...@gmail.com on 31 Aug 2013 at 12:44

[GoogleCodeExporter]

Done. Ticket https://github.com/numpy/numpy/issues/3667

Original comment by lukepinn...@gmail.com on 31 Aug 2013 at 11:45

[GoogleCodeExporter]

Duh!

Comparing dtype not type works as expected.:

a = np.array([1], np.int32)
b=ne.evaluate('a')
print a.dtype,b.dtype
print a.dtype==b.dtype
print a.dtype==np.int32
print b.dtype==np.int32

Original comment by lukepinn...@gmail.com on 1 Sep 2013 at 11:39

[GoogleCodeExporter]

From the numpy report:

"The type returned by numexpr will be np.intc in your case. Maybe this should 
be changed in numpy, but as I said, there is the fix by using the dtype's 
equality check instead of the type equality check which is probably an identity 
check. I think there was a recent bugreport suggesting to change the printing 
for the types to include this difference, dunno what is the right approach, 
maybe nothing can be done and just care must be taken."

Original comment by lukepinn...@gmail.com on 2 Sep 2013 at 12:39

[GoogleCodeExporter]

Okay, so I would say that filing a ticket in the GDAL project asking them to 
compare dtypes instead of types would be the thing to do.

Closing this.

Original comment by fal...@gmail.com on 3 Sep 2013 at 12:55

• Changed state: Invalid

[GoogleCodeExporter]

Already filed a ticket against GDAL with a patch 
(http://trac.osgeo.org/gdal/ticket/5223). Thanks for looking into this.

Original comment by lukepinn...@gmail.com on 4 Sep 2013 at 8:02