ooguntola/numexpr

Automatically exported from code.google.com/p/numexpr

numexpr's Issues

Potential missing Py_END_ALLOW_THREADS

I've just spotted a *potential* bug (it doesn't seem to cause any problem in 
the usual case):

In interpreter.c (trunk), shouldn't there be "Py_END_ALLOW_THREADS" also on 
lines 1271, 1276, 1279?

Original issue reported on code.google.com by [email protected] on 21 Jan 2011 at 3:03

Build fails on OSX 10.6.6

I am not able to build numexpr on OSX 10.6.6 due to what appears to be lack of 
support for ppc in gcc 4.2.1 (see below). I have no interest in building for 
ppc architecture, but there does not appear to be a way of excluding it. Any 
idea how to get numexpr built on OSX?

creating build/temp.macosx-10.6-universal-2.6
creating build/temp.macosx-10.6-universal-2.6/numexpr
compile options: 
'-I/Library/Python/2.6/site-packages/numpy-1.6.0.dev_b28b115_20110307-py2.6-maco
sx-10.6-universal.egg/numpy/core/include 
-I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c'
extra options: '-funroll-all-loops'
gcc-4.2: numexpr/interpreter.c
/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler 
(/usr/bin/../libexec/gcc/darwin/ppc/as or 
/usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
numexpr/interpreter.c:1934: fatal error: error writing to -: Broken pipe
compilation terminated.
numexpr/interpreter.c: In function ‘NumExpr_run’:
numexpr/interpreter.c:1458: warning: comparison is always false due to limited 
range of data type
numexpr/interpreter.c:1461: warning: comparison is always false due to limited 
range of data type
numexpr/interpreter.c:1679: warning: comparison is always false due to limited 
range of data type
lipo: can't open input file: 
/var/folders/kf/kfvsPUulHTyPN2AtGPwOdk+++TI/-Tmp-//cc0PBe1c.out (No such file 
or directory)
/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler 
(/usr/bin/../libexec/gcc/darwin/ppc/as or 
/usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
numexpr/interpreter.c:1934: fatal error: error writing to -: Broken pipe
compilation terminated.
numexpr/interpreter.c: In function ‘NumExpr_run’:
numexpr/interpreter.c:1458: warning: comparison is always false due to limited 
range of data type
numexpr/interpreter.c:1461: warning: comparison is always false due to limited 
range of data type
numexpr/interpreter.c:1679: warning: comparison is always false due to limited 
range of data type
lipo: can't open input file: 
/var/folders/kf/kfvsPUulHTyPN2AtGPwOdk+++TI/-Tmp-//cc0PBe1c.out (No such file 
or directory)
error: Command "gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g 
-fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc 
-arch x86_64 -pipe 
-I/Library/Python/2.6/site-packages/numpy-1.6.0.dev_b28b115_20110307-py2.6-macos
x-10.6-universal.egg/numpy/core/include 
-I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c 
numexpr/interpreter.c -o 
build/temp.macosx-10.6-universal-2.6/numexpr/interpreter.o -funroll-all-loops" 
failed with exit status 1
removed __svn_version__.py

Original issue reported on code.google.com by [email protected] on 22 Mar 2011 at 10:59

Fortran-ordered arrays give wrong results

Numexpr does not consider the fact that an array might have a
'transposed' (or Fortran-ordered) view.  This should be fixed.

The next reproduces the problem:

{{{
In [13]: a = np.arange(10).reshape(2,5)

In [14]: b = a.transpose()

In [15]: numexpr.evaluate("a*2")
Out[15]:
array([[ 0,  2,  4,  6,  8],
       [10, 12, 14, 16, 18]])

In [16]: numexpr.evaluate("b*2")
Out[16]:
array([[ 0, 10],
       [96, 34],
       [10, 34],
       [ 0, 60],
       [ 0,  0]])
}}}

Original issue reported on code.google.com by [email protected] on 5 Mar 2009 at 1:31

Release files also in PyPI

I should remember doing this for *every* release.

Original issue reported on code.google.com by [email protected] on 13 Feb 2009 at 8:04

isnan and isfinite function in numexpr like in numpy

It would be really nice if there were isnan and isfinite function in 
numexpr like in numpy:

An example would be:

>>> a = numpy.arange(10.0)

>>> a[2]=numpy.nan

>>> a
array([  0.,   1.,  NaN,   3.,   4.,   5.,   6.,   7.,   8.,   9.])

>>> numexpr.evaluate('where(isnan(a), 0, a)')
array([ 0.,  1.,  0.,  3.,  4.,  5.,  6.,  7.,  8.,  9.])

Original issue reported on code.google.com by [email protected] on 8 Sep 2009 at 8:54

Unable to install numexpr-1.3.1 on Mac OSX v 10.6.4

What steps will reproduce the problem?

$ python setup.py install (from numpexpr directory)


What is the expected output? What do you see instead?

Markm-Mac:numexpr-1.3.1 markhmoulton$ python setup.py install
Warning: Assuming default configuration (numexpr/tests/{setup_tests,setup}.py 
was not found)
Appending numexpr.tests configuration to numexpr
Ignoring attempt to set 'name' (from 'numexpr' to 'numexpr.tests')
running install
running bdist_egg
running egg_info
running build_src
build_src
building py_modules sources
building extension "numexpr.interpreter" sources
build_src: building npy-pkg config files
writing numexpr.egg-info/PKG-INFO
writing top-level names to numexpr.egg-info/top_level.txt
writing dependency_links to numexpr.egg-info/dependency_links.txt
reading manifest file 'numexpr.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files found matching 'numexpr/__config__.py'
warning: no previously-included files found matching 'RELEASING.txt'
writing manifest file 'numexpr.egg-info/SOURCES.txt'
installing library code to build/bdist.macosx-10.3-fat/egg
running install_lib
running build_py
copying build/src.macosx-10.3-fat-2.6/numexpr/__config__.py -> 
build/lib.macosx-10.3-fat-2.6/numexpr
running build_ext
customize UnixCCompiler
customize UnixCCompiler using build_ext
building 'numexpr.interpreter' extension
compiling C sources
C compiler: gcc-4.0 -arch ppc -arch i386 -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic 
-DNDEBUG -g -O3

compile options: 
'-I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
/numpy/core/include 
-I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c'
extra options: '-funroll-all-loops'
gcc-4.0: numexpr/interpreter.c
sh: gcc-4.0: command not found
sh: gcc-4.0: command not found
error: Command "gcc-4.0 -arch ppc -arch i386 -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic 
-DNDEBUG -g -O3 
-I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/
numpy/core/include 
-I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c 
numexpr/interpreter.c -o build/temp.macosx-10.3-fat-2.6/numexpr/interpreter.o 
-funroll-all-loops" failed with exit status 127



What version of the product are you using? On what operating system?
numexpr-1.3.1.tar.gz
numpy 1.4.0
python 2.6
Mac OSX 10.6.4



Please provide any additional information below.

I am really looking forward to using numexpr to support PyTables, but until I 
can get the install to work, I'm dead in the water.  I am not expert at doing 
installs, so probably doing something dumb.  Help greatly appreciated.

Mark Moulton
Sunnyvale, CA

Original issue reported on code.google.com by [email protected] on 31 Jul 2010 at 1:23

Add string support to Numexpr

#415 from scipy:

The attached patch attachment:numexpr_str.diff adds support to Numexpr for 
comparing string 
values (constants and arrays) as in PyTables.

Original issue reported on code.google.com by [email protected] on 23 Jun 2008 at 5:38

forward scipy ticket 400:Patch for accelerating operations in numexpr when unaligned matrices are present

 By F. Altet:

I don't actually know why, but my benchmarks show that doing a copy in python 
space of an 
unaligned array is between a 30% and 70% faster (depending on the CPU) than 
doing this in C space 
(using PyArray_SimpleNewFromDescr).

I'm adding the patch just in case you want to try it out and/or eventually 
apply it.

Original issue reported on code.google.com by [email protected] on 23 Jun 2008 at 5:29

Attachments:

• numexpr-unaligned.patch
• numexpr-unaligned-1.patch

Numexpr does not work correctly when run in sub-processes

The recent support for threads does not behave well when running numexpr in 
sub-processes.

The next code snippet reproduces the problem:

{{{
import numexpr as ne
import numpy as np
import multiprocessing as mp

def _worker(qout = None):
    ra = np.arange(1e3)
    rows = ne.evaluate('ra > 0')
    print "Succeeded in evaluation!\n"

    if qout is not None:
            qout.put("Done")

if __name__ == "__main__":
    #print ne.set_num_threads(1)
    print "**** Running from main process:"
    _worker()
    print "**** Running from subprocess:"
    qout = mp.Queue()
    ps = mp.Process(target=_worker, args=(qout,))
    ps.daemon = True
    ps.start()

    print qout.get()
}}}

which has the next output

{{{
**** Running from main process:
Succeeded in evaluation!

**** Running from subprocess:
[waits forever!]
}}}

Original issue reported on code.google.com by [email protected] on 27 Sep 2010 at 9:33

[deleted issue]

[deleted issue]

Raising array containing 0s to a negative power causes core dump in numexpr 1.4

What steps will reproduce the problem?
1. import numexpr
2. a = [-1, 0, 1]
3. numexpr.evaluate('a**-1')
Floating point exception (core dumped)



I am using numexpr version 1.4 on python:

Python 2.5.4 (r254:67916, Jun 11 2009, 16:53:32)

On linux.

Original issue reported on code.google.com by [email protected] on 15 Nov 2010 at 3:18

Import fails: missing VERSION

Installing numexpr occurs without error, but importing reveals a missing file:

In [1]: import numexpr
---------------------------------------------------------------------------
IOError                                   Traceback (most recent call last)

/Users/fonnesbeck/<ipython console> in <module>()

/Library/Frameworks/Python.framework/Versions/4.1.30101/lib/python2.5/site-packa
ges/numexpr-1.1-py2.5-macosx-10.3-i386.egg/numexpr/__init__.py
in <module>()
      6 from numexpr.tests import test
      7 
      8 dirname = os.path.dirname(__file__)
      9 
---> 10 __version__ = open(os.path.join(dirname,'VERSION')).read().strip()
        global __version__ = undefined
        global open = undefined
        global os.path.join = undefined
        global dirname.read.strip = undefined

IOError: [Errno 2] No such file or directory:
'/Library/Frameworks/Python.framework/Versions/4.1.30101/lib/python2.5/site-pack
ages/numexpr-1.1-py2.5-macosx-10.3-i386.egg/numexpr/VERSION'

Original issue reported on code.google.com by [email protected] on 17 Jan 2009 at 4:00

Please add link flags option

mkl is not on my normal link search path.  I'd like to build using -Xlinker
--rpath -Xlinker blah so I don't have to do LD_LIBRARY_PATH.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 13 Feb 2009 at 3:45

numexpr does not parallelize well long column, short row size array

from pylab import *
import numexpr

numexpr.set_num_threads(8)
x0,x1,x2,x3,x4,x5 = [0,1,2,3,4,5]
t = linspace(0,1,44100000).reshape(-1,1)
numexpr.evaluate('(x0+x1*t+x2*t**2)* cos(x3+x4*t+x5**t)')


This does not take advantage of 8 threads, but if I remove .reshape, it does.

Original issue reported on code.google.com by [email protected] on 28 Feb 2011 at 6:39

Link need with libmkl_solver_ilp64 to avoid libmkl_vml_mc3.so: undefined symbol: mkl_serv_mkl_malloc

What steps will reproduce the problem?
1. install numexpr linked with mkl
2. execute the test

What is the expected output? What do you see instead?

The test returns "libmkl_vml_mc3.so: undefined symbol: mkl_serv_mkl_malloc"


What version of the product are you using? On what operating system?

I am on Linux on a x86_64. It is a Altix ICE 8200 EX.

To solve the problem, I need to link with libmkl_solver_ilp64. I get the 
information on 
http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/.

I think it could be writen in the site.cfg.example.

Original issue reported on code.google.com by [email protected] on 21 Jul 2010 at 10:09

Slow down compared to numpy

In [1]: import numexpr as ne

In [2]: a =  np.random.random((3550, 8000))

In [3]: b = array(a[0])
\
In [4]: %timeit ne.evaluate('a - b')
1 loops, best of 3: 476 ms per loop

In [5]: %timeit a-b
1 loops, best of 3: 197 ms per loop

The expected output is that it would speed it up rathern than slow it down. 

Thanks for your help
     Wolfgang

Original issue reported on code.google.com by [email protected] on 30 Mar 2011 at 5:27

possible build problem with gcc 4.5.2?

When I recently tried to build numexpr 1.4.2 on an x86_64 Linux system with gcc 
4.5.2 and numpy 1.5.1, the build failed with numerous errors similar to the 
following:

build/temp.linux-x86_64-2.7/numexpr/interpreter.o: In function `nc_abs':
/home/lev/numexpr-1.4.2/numexpr/complex_functions.inc:387: undefined reference 
to `sqrt'

Given that /usr/include/math.h is in place and given that
I am able to build the package successfully on a similar system running gcc 
4.4.3, I'm wondering whether the above error might be due to gcc 4.5.2. Any 
ideas?

Original issue reported on code.google.com by [email protected] on 1 Feb 2011 at 7:19

Support for different logarithmic and exponential functions

Hi,

I've recently added support for arcsinh, arccosh, arctanh, log, log10,
log1p, exp and expm1 functions (including complex versions) to the numexpr
module in PyTables.  I've backported the changes to plain Numexpr and I'm
attaching a couple of patches here:

- r3997-ne (backport of http://pytables.org/trac/changeset/3897/).  This is
where the real meat is.  Here, the addition of new functions has been made,
and also the test suite has been improved a lot in order to check all the
functions implemented in Numexpr.  This refinement discovered some issues
(fixed now) in inverse trigonometric functions already in Numexpr.

- r3998-ne (backport of http://pytables.org/trac/changeset/3898 and also
includes backport of http://pytables.org/trac/changeset/3897).  This is a
refinement of the previous patch consisting in removing functions sin,
arctan2 and others from the opcodes of the virtual machine.  My benchmarks
show that the additional lookup in the function table is negligible, so I
thought that it would be better to get rid of them from the main VM loop
(where performance is critical).

Feel free to include one or the other patches.

Also, be in mind that these patches do require NumPy 1.2.  This is mainly
for compatibility with the new test framework used by NumPy (they recently
switched to nose).  There is no more dependency on NumPy testing framwork now.

Cheers,

Francesc

Original issue reported on code.google.com by [email protected] on 11 Nov 2008 at 5:20

Attachments:

• r3997-ne.patch
• r3998-ne.patch

Problem with "and" (also, __nonzero__ should not be defined)

>>> a = numpy.array([1, 2, 1, 2, 1], dtype=numpy.int8)   # or numpy.int32
>>> b = numpy.array([1, 2, 3, 4, 1], dtype=numpy.int8)   # or numpy.int32
>>> numexpr.evaluate("(a==1) & (b>2)")
array([False, False,  True, False, False], dtype=bool)

All good so far.  But, now, if we try to use "and" instead of "&":

>>> numexpr.evaluate("(a==1) and (b>2)")
array([False, False,  True,  True, False], dtype=bool)

Which isn't right.  Seems as if only the RHS expression of the "and" is
evaluated. Ie. the result given is just "b>2".

This on windows XP, python 2.5.

Original issue reported on code.google.com by [email protected] on 12 Dec 2009 at 3:23

symbol lookup error: /usr/pkg/fortran90/intel/mkl/10.2.5.035/lib/em64t/libmkl_vml_mc2.so: undefined symbol: mkl_serv_mkl_malloc

I'm experiencing the "symbol lookup error: 
/usr/pkg/fortran90/intel/mkl/10.2.5.035/lib/em64t/libmkl_vml_mc2.so: undefined 
symbol: mkl_serv_mkl_malloc" error when running python -vvv -c "import numexpr; 
numexpr.test()".

The fix r171 which solves #27 apparently does not work in my case. I'm working 
in a Fedora 8 x86_64 box, with Python 2.5.5 and compiling with gcc 4.1.2. MKL 
is version 10.2.5.035.

Both the build and the install steps were apparently successfull, and as far as 
I can see the site.cfg is correct (it includes the mkl_solver_ilp64
entry).

I include here the relevant snippets from the configuration file, the build 
step and the test run.

site.cfg:

library_dirs = /usr/pkg/fortran90/intel/mkl/10.2.5.035/lib/em64t
include_dirs = /usr/pkg/fortran90/intel/mkl/10.2.5.035/include
mkl_libs = mkl_core, mkl_solver_ilp64, mkl_intel_ilp64, mkl_intel_thread, iomp5


output of build stage:

mkl_info:
  FOUND:
    libraries = ['mkl_core', 'mkl_solver_ilp64', 'mkl_intel_ilp64', 'mkl_intel_thread', 'iomp5', 'pthread']
    library_dirs = ['/usr/pkg/fortran90/intel/mkl/10.2.5.035/lib/em64t']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/usr/pkg/fortran90/intel/mkl/10.2.5.035/include']


Test:

Numexpr version:   1.4
NumPy version:     1.4.1
Python version:    2.5.5 (r255:77872, Mar 17 2010, 12:10:50)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)]
Platform:          linux2-x86_64
AMD/Intel CPU?     True
VML available?     True
VML/MKL version:   Intel(R) Math Kernel Library Version 10.2.5 Product Build 
20100325 for Intel(R) 64 architecture applications
Detected cores:    1
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
../usr/pkg/python/Python-2.5.5/bin/python: symbol lookup error: 
/usr/pkg/fortran90/intel/mkl/10.2.5.035/lib/em64t/libmkl_vml_mc2.so: undefined 
symbol: mkl_serv_mkl_malloc

Thanks very much

Original issue reported on code.google.com by [email protected] on 3 Sep 2010 at 1:40

The number of threads should be set only for Numexpr native pthreads, not for VML

Numexpr seems to be more efficient when using native pthreads parallel code 
instead of the VML implementation, but currently, both native and VML threads 
are set to the total number of detected cores, leading to bad performance.

For example, with a 2-core machine:

{{{
>>> from numpy import pi
>>> import numpy as np
>>> import numexpr as ne

>>> i = np.arange(1e6)
>>> timeit ne.evaluate("cos(2*pi*i/100.)")
10 loops, best of 3: 16.6 ms per loop  # 2 th native, 2 th VML
>>> ne.set_vml_num_threads(1)
>>> timeit ne.evaluate("cos(2*pi*i/100.)")  # 2 th native, 1 th VML
100 loops, best of 3: 8.95 ms per loop
>>> ne.set_num_threads(1)
>>> timeit ne.evaluate("cos(2*pi*i/100.)")  # 1 th native, 1 th VML
100 loops, best of 3: 14.9 ms per loop
>>> ne.set_vml_num_threads(2)
>>> timeit ne.evaluate("cos(2*pi*i/100.)")
100 loops, best of 3: 12.9 ms per loop  # 1 th native, 2 th VML
}}}

As can be seen, the maximum performance can be achieved when setting the number 
of threads only in the native pthreads implementation.

Original issue reported on code.google.com by [email protected] on 28 Nov 2010 at 9:40

support for class instant variables. (self.abc)

class t:
    def __init__(self):
        self.t = 1
    def test(self, a):
        numexpr.evaluate('a + self.t')
test = t()
t.test(2)


I think evaluate() should be able to process 'self.t' but it doesn't

Original issue reported on code.google.com by [email protected] on 20 Feb 2011 at 8:34

'uint32' is not supported

The next reproduces the problem:

{{{
In [4]: a = np.array([1], 'uint32')

In [5]: ne.evaluate('a')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/faltet/python/numexpr/trunk/<ipython console> in <module>()

/home/faltet/python/numexpr/trunk/numexpr/necompiler.pyc in evaluate(ex,
local_dict, global_dict, **kwargs)
    682         compiled_ex = _numexpr_cache[numexpr_key]
    683     except KeyError:
    684         compiled_ex = _numexpr_cache[numexpr_key] = \
    685                       NumExpr(ex, signature, copy_args, **kwargs)
--> 686     return compiled_ex(*arguments)

TypeError: array cannot be safely cast to required type
}}}

My guess is that simply upcasting 'uint32' to a 'long' numexpr type would
be enough to implement the support.

Original issue reported on code.google.com by [email protected] on 17 Jun 2009 at 3:19

get_optimization() is called twice

If you apply the next patch to numexpr sources:

{{{
--- numexpr/expressions.py      (revision 14)
+++ numexpr/expressions.py      (working copy)
@@ -180,6 +192,7 @@

 @ophelper
 def pow_op(a, b):
+    print "get_optimization()-->", get_optimization()
     if allConstantNodes([a,b]):
         return ConstantNode(a**b)
     if isinstance(b, ConstantNode):

}}}

and run the next code:

{{{
import numpy
import threading
import numexpr

a = numpy.arange(3)

class ThreadTest(threading.Thread):
    def run(self):
        print "result-->", numexpr.evaluate('a**3', optimization="none")
        print "result-->", numexpr.evaluate('a**3', optimization="moderate")
        print "result-->", numexpr.evaluate('a**3', optimization="aggressive")

test = ThreadTest()
test.start()

}}}

you will get the next result:

{{{
result--> get_optimization()--> none
get_optimization()--> aggressive
[0 1 8]
result--> get_optimization()--> moderate
get_optimization()--> aggressive
[0 1 8]
result--> get_optimization()--> aggressive
get_optimization()--> aggressive
[0 1 8]
}}}

There are two problems here:

1. I don't know why get_optimization() is called twice
2. It seems to me that the optimization flag is used in 'aggressive' mode
always.

Please notice that this is probably not related with threading, but the
example includes threads so as to see if the contexts work as they should.

Original issue reported on code.google.com by [email protected] on 14 Apr 2008 at 12:26

sum big array causes segmentation fault

What steps will reproduce the problem?
1. python
Python 2.6.5 (r265:79063, Jul 14 2010, 11:36:05) 
[GCC 4.4.4 20100630 (Red Hat 4.4.4-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.version.version
'1.5.1'
>>> a = np.arange(91 * 720 * 361).reshape((91, 720, 361))
>>> import numexpr as ne
>>> ne.__version__
'1.4.1'
>>> nesum = ne.evaluate("sum(a, axis=0)")
Segmentation fault

2.
3.

What is the expected output? What do you see instead?
I expect to get the sum of *a* along the first axis.


What version of the product are you using? On what operating system?
numexpr 1.4.1
numpy 1.5.1
python 2.6.5
RHEL6


Please provide any additional information below.

Original issue reported on code.google.com by jakob.malm on 14 Jan 2011 at 7:58

[Patch] Add support for more boolean operations

Hi,

Here is a patch to add two more opcodes to numexpr:
where_bbbb and cast_ib.

I had to shift many opcodes numbers in opcodes.inc. Not sure if this is alright 
or not. The thing is that I couldn't simply put them just before OP_END, 
because of the constraint of being before OP_REDUCTION, so I figured that since 
I have to move a dozen, moving a few more so that it is sorted like the other 
opcodes wouldn't hurt that much.

Original issue reported on code.google.com by [email protected] on 27 Jul 2010 at 2:22

Attachments:

• numexpr_bool_ops.patch

trunk fails to build on MingW

At least for recent MingW (gcc 4.5.2), it gives:

customize Mingw32CCompiler
customize Mingw32CCompiler using build_ext
building 'numexpr.interpreter' extension
compiling C sources
C compiler: gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes

compile options: '-Ic:\soft\Python26-32b\Lib\site-packages\numpy\core\include -I
C:\soft\Python26-32b\include -IC:\soft\Python26-32b\PC -c'
extra options: '-funroll-all-loops'
gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes -Ic:\soft\Python26-32b\Lib\site-pa
ckages\numpy\core\include -IC:\soft\Python26-32b\include -IC:\soft\Python26-32b\
PC -c numexpr\win32\pthread.c -o build\temp.win32-2.6\Release\numexpr\win32\pthr
ead.o -funroll-all-loops
Found executable C:\soft\MinGW\bin\gcc.exe
gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes -Ic:\soft\Python26-32b\Lib\site-pa
ckages\numpy\core\include -IC:\soft\Python26-32b\include -IC:\soft\Python26-32b\
PC -c numexpr\interpreter.c -o build\temp.win32-2.6\Release\numexpr\interpreter.
o -funroll-all-loops
In file included from numexpr\interpreter.c:31:0:
numexpr\/missing_posix_functions.inc:7:22: error: static declaration of 'log1p'
follows non-static declaration
numexpr\/missing_posix_functions.inc:17:22: error: static declaration of 'expm1'
 follows non-static declaration
numexpr\/missing_posix_functions.inc:29:22: error: static declaration of 'asinh'
 follows non-static declaration
numexpr\/missing_posix_functions.inc:49:22: error: static declaration of 'acosh'
 follows non-static declaration
numexpr\/missing_posix_functions.inc:54:22: error: static declaration of 'atanh'
 follows non-static declaration
numexpr\/missing_posix_functions.inc:65:21: error: static declaration of 'log1pf
' follows non-static declaration
numexpr\/missing_posix_functions.inc:70:21: error: static declaration of 'expm1f
' follows non-static declaration
numexpr\/missing_posix_functions.inc:75:21: error: static declaration of 'asinhf
' follows non-static declaration
numexpr\/missing_posix_functions.inc:80:21: error: static declaration of 'acoshf
' follows non-static declaration
numexpr\/missing_posix_functions.inc:85:21: error: static declaration of 'atanhf
' follows non-static declaration
numexpr\interpreter.c: In function 'initinterpreter':
numexpr\interpreter.c:1893:5: warning: dereferencing type-punned pointer will br
eak strict-aliasing rules
error: Command "gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes -Ic:\soft\Python26
-32b\Lib\site-packages\numpy\core\include -IC:\soft\Python26-32b\include -IC:\so
ft\Python26-32b\PC -c numexpr\interpreter.c -o build\temp.win32-2.6\Release\nume
xpr\interpreter.o -funroll-all-loops" failed with exit status 1
removed __svn_version__.py

Attached patch fixes the problem on my machine. Previously, I had only 
warnings, now these are errors.

Original issue reported on code.google.com by [email protected] on 3 May 2011 at 3:39

Attachments:

• mingw_build.patch

Multi-threading code should be disabled for small arrays

When working with small arrays, the threaded code should be avoided for getting 
better performance.  See this thread for more info:

http://mail.scipy.org/pipermail/scipy-user/2010-November/027263.html

Original issue reported on code.google.com by [email protected] on 1 Nov 2010 at 9:18

numexpr 1.4 does not build (as is) on Mingw

A couple comments: 
- 1.3.x was building fine
- it seems related to pthreads.
- changing "#if defined(_WIN32) && !defined(__MINGW32__)" in "interpreter.c" to 
"#if defined(_WIN32)" seems to fix the problem.

Build log follows:
===========================
C:\Users\gdm\devel\numexpr>python setup.py build
mkl_info:
  libraries mkl,vml,guide not found in C:\soft\Python26-32b\lib
  libraries mkl,vml,guide not found in C:\
  libraries mkl,vml,guide not found in C:\soft\Python26-32b\libs
  NOT AVAILABLE

Warning: Assuming default configuration (numexpr\tests/{setup_tests,setup}.py wa
s not found)
Appending numexpr.tests configuration to numexpr
Ignoring attempt to set 'name' (from 'numexpr' to 'numexpr.tests')
Creating __svn_version__.py (version='234')
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands --compiler opti
ons
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands --fcompiler opt
ions
running build_src
build_src
building py_modules sources
building extension "numexpr.interpreter" sources
building data_files sources
build_src: building npy-pkg config files
running build_py
copying build\src.win32-2.6\numexpr\__config__.py -> build\lib.win32-2.6\numexpr

running build_ext
customize Mingw32CCompiler
customize Mingw32CCompiler using build_ext
building 'numexpr.interpreter' extension
compiling C sources
C compiler: gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes

creating build\temp.win32-2.6\Release\numexpr\win32
compile options: '-Ic:\soft\Python26-32b\Lib\site-packages\numpy\core\include -I
C:\soft\Python26-32b\include -IC:\soft\Python26-32b\PC -c'
extra options: '-funroll-all-loops'
gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes -Ic:\soft\Python26-32b\Lib\site-pa
ckages\numpy\core\include -IC:\soft\Python26-32b\include -IC:\soft\Python26-32b\
PC -c numexpr\win32\pthread.c -o build\temp.win32-2.6\Release\numexpr\win32\pthr
ead.o -funroll-all-loops
Found executable C:\soft\MinGW\bin\gcc.exe
gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes -Ic:\soft\Python26-32b\Lib\site-pa
ckages\numpy\core\include -IC:\soft\Python26-32b\include -IC:\soft\Python26-32b\
PC -c numexpr\interpreter.c -o build\temp.win32-2.6\Release\numexpr\interpreter.
o -funroll-all-loops
numexpr\interpreter.c:12:23: pthread.h: No such file or directory
In file included from numexpr\interpreter.c:28:
numexpr\missing_posix_functions.inc:8: warning: static declaration of 'log1p' fo
llows non-static declaration
numexpr\missing_posix_functions.inc:18: warning: static declaration of 'expm1' f
ollows non-static declaration
numexpr\missing_posix_functions.inc:30: warning: static declaration of 'asinh' f
ollows non-static declaration
numexpr\missing_posix_functions.inc:50: warning: static declaration of 'acosh' f
ollows non-static declaration
numexpr\missing_posix_functions.inc:55: warning: static declaration of 'atanh' f
ollows non-static declaration
numexpr\missing_posix_functions.inc:66: warning: static declaration of 'log1pf'
follows non-static declaration
numexpr\missing_posix_functions.inc:71: warning: static declaration of 'expm1f'
follows non-static declaration
numexpr\missing_posix_functions.inc:76: warning: static declaration of 'asinhf'
follows non-static declaration
numexpr\missing_posix_functions.inc:81: warning: static declaration of 'acoshf'
follows non-static declaration
numexpr\missing_posix_functions.inc:86: warning: static declaration of 'atanhf'
follows non-static declaration
numexpr\interpreter.c:57: error: syntax error before "threads"
numexpr\interpreter.c:57: warning: type defaults to `int' in declaration of `thr
eads'
numexpr\interpreter.c:57: warning: data definition has no type or storage class
numexpr\interpreter.c:65: error: syntax error before "count_mutex"
numexpr\interpreter.c:65: warning: type defaults to `int' in declaration of `cou
nt_mutex'
numexpr\interpreter.c:65: warning: data definition has no type or storage class
numexpr\interpreter.c:67: error: syntax error before "count_threads_mutex"
numexpr\interpreter.c:67: warning: type defaults to `int' in declaration of `cou
nt_threads_mutex'
numexpr\interpreter.c:67: warning: data definition has no type or storage class
numexpr\interpreter.c:68: error: syntax error before "count_threads_cv"
numexpr\interpreter.c:68: warning: type defaults to `int' in declaration of `cou
nt_threads_cv'
numexpr\interpreter.c:68: warning: data definition has no type or storage class
numexpr\interpreter.c: In function `last_opcode':
numexpr\interpreter.c:461: warning: dereferencing type-punned pointer will break
 strict-aliasing rules
numexpr\interpreter.c: In function `check_program':
numexpr\interpreter.c:484: warning: dereferencing type-punned pointer will break
 strict-aliasing rules
numexpr\interpreter.c: In function `vm_engine_parallel':
numexpr\interpreter.c:1036: warning: implicit declaration of function `pthread_m
utex_lock'
numexpr\interpreter.c:1039: warning: implicit declaration of function `pthread_c
ond_wait'
numexpr\interpreter.c:1042: warning: implicit declaration of function `pthread_c
ond_broadcast'
numexpr\interpreter.c:1044: warning: implicit declaration of function `pthread_m
utex_unlock'
numexpr\interpreter.c: In function `init_threads':
numexpr\interpreter.c:1284: warning: implicit declaration of function `pthread_m
utex_init'
numexpr\interpreter.c:1288: warning: implicit declaration of function `pthread_c
ond_init'
numexpr\interpreter.c:1294: warning: implicit declaration of function `pthread_c
reate'
numexpr\interpreter.c: In function `numexpr_set_nthreads':
numexpr\interpreter.c:1342: warning: implicit declaration of function `pthread_j
oin'
numexpr\interpreter.c: In function `numexpr_free_resources':
numexpr\interpreter.c:1395: warning: implicit declaration of function `pthread_m
utex_destroy'
numexpr\interpreter.c:1397: warning: implicit declaration of function `pthread_c
ond_destroy'
numexpr\interpreter.c: In function `initinterpreter':
numexpr\interpreter.c:1868: warning: dereferencing type-punned pointer will brea
k strict-aliasing rules
numexpr\interpreter.c:1869: warning: dereferencing type-punned pointer will brea
k strict-aliasing rules
error: Command "gcc -mno-cygwin -O2 -Wall -Wstrict-prototypes -Ic:\soft\Python26
-32b\Lib\site-packages\numpy\core\include -IC:\soft\Python26-32b\include -IC:\so
ft\Python26-32b\PC -c numexpr\interpreter.c -o build\temp.win32-2.6\Release\nume
xpr\interpreter.o -funroll-all-loops" failed with exit status 1
removed __svn_version__.py

Original issue reported on code.google.com by [email protected] on 6 Aug 2010 at 1:50

Support abs function

The attached patch adds support for using `abs` and `absolute` functions in
numexpr expressions.

Original issue reported on code.google.com by [email protected] on 18 Jun 2009 at 8:28

Attachments:

• add-abs.patch

Support of 32-bit floats

Some people would like to see float32 support in Numexpr.  This is doable,
but we may have to proceed with caution.  For example, this would imply the
implementation of a simple precision version for the complex type too?

Original issue reported on code.google.com by [email protected] on 19 Jan 2009 at 6:41

forwarded from scipy #614: Minor changes to Numexpr test module

From ivilata:

Hi, I'm attaching two small patches to the test module of Numexpr:

attachment:numpy_funcs.diff imports some functions from the numpy package 
instead of getting 
them by pure chance from scipy.testing.
attachment:check_to_test.diff makes the names of generated test methods 
consistent with the other 
ones, by changing their name from check_* to test_*.
Those two changes make adapting the test module of Numexpr to run without SciPy 
(just with 
NumPy) a little easier, and I think they improve the overall consistence of the 
module.

Original issue reported on code.google.com by [email protected] on 23 Jun 2008 at 5:35

Attachments:

• numpy_funcs.diff
• check_to_test.diff

[PATCH] Loop optimization to gain ~15% performance

Here is an *experimental* (ie incomplete and not heavily tested) patch which 
leads to a ~15% performance improvement here in a simple expression, at the 
expense of slightly uglier code.

Several comments:
- I'm compiling this with MingW 5.1.6, and other compilers might optimize the 
old version as well as what I did manually (I don't know).

- It is incomplete: so far, I didn't bother with VML code, and I might have 
broken reduce operations (possibly other stuff -- didn't run the test suite 
yet).

- It might be possible to do the same optimisation more cleanly.

I'm ready to try to make this a complete patch and maybe try to do it in a 
cleaner way, but before I spend any more time into it, I would like to know 
what you guys think about it and possibly try it on other compilers to see if 
it is worth the effort.

Here are my benchmarks:
without patch:

In [1]: import numpy as np
In [2]: import numexpr as ne
In [3]: a = np.arange(1e6)
In [4]: timeit ne.evaluate('0.25 * a ** 2 + 0.34 * a + 0.54')
100 loops, best of 3: 8.47 ms per loop

with patch:
In [4]: timeit ne.evaluate('0.25 * a ** 2 + 0.34 * a + 0.54')
100 loops, best of 3: 7.45 ms per loop

Original issue reported on code.google.com by [email protected] on 19 Nov 2010 at 9:55

Attachments:

• loop_optimization.patch

Some complementary info in README.txt

Hi,

This is a minor correction on attributions.  In README.txt it reads:

"""
Francesc Altet <[email protected]>
contributed support for booleans, and initial support for strided arrays.
"""

However, Ivan Vilata gave support for string type also.  So, I'd say:

"""
Francesc Altet <[email protected]> contributed support for booleans and
for efficient strided and unaligned array operations.  Ivan Vilata
<[email protected]> contributed support for strings.
"""

Original issue reported on code.google.com by [email protected] on 10 Mar 2008 at 4:34

Trunk cannot be compiled

When trying to compile trunk, I'm getting the next errors:

{{{
gcc: numexpr/interpreter.c                                                

In file included from numexpr/interpreter.c:944:                          

numexpr/interp_body.c: In function ‘vm_engine_1’:                         

numexpr/interp_body.c:228: error: ‘OP_ONES_LIKE_II’ undeclared (first use
in this function)                             
numexpr/interp_body.c:228: error: (Each undeclared identifier is reported
only once                                     
numexpr/interp_body.c:228: error: for each function it appears in.)       

numexpr/interp_body.c:241: error: ‘OP_ONES_LIKE_LL’ undeclared (first use
in this function)                             
}}}

and a bunch of similar ones.

I suppose that this has something to do with latests changesets (r157:161).

Original issue reported on code.google.com by [email protected] on 5 Feb 2010 at 9:23

Broadcasting does not work for parallel code correctly

After some refactoring, it seems that broadcasting does not work correctly in 
parallel mode.  I've no time to see what exactly happens, but the problem can 
be seen on Win64, where the next test always fail:

C:\Users\Francesc\Desktop\Numexpr\trunk>python numexpr\tests\test_numexpr.py 
test_evaluate.test_broadcasting
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Numexpr version:   1.4
NumPy version:     1.4.1
Python version:    2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit
(AMD64)]
AMD/Intel CPU?     True
VML available?     False
Detected cores:    6
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
F
======================================================================
FAIL: test_broadcasting (__main__.test_evaluate)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "numexpr\tests\test_numexpr.py", line 188, in test_broadcasting
    assert_array_equal(evaluate("a+c"), a+c)
  File "C:\Python26_64\lib\site-packages\numpy\testing\utils.py", line 677, in a
ssert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "C:\Python26_64\lib\site-packages\numpy\testing\utils.py", line 609, in a
ssert_array_compare
    raise AssertionError(msg)
AssertionError:
Arrays are not equal

(mismatch 32.0%)
 x: array([[32, 34, 36, 38, 40, 42, 44, 46, 48, 50],
       [52, 54, 56, 58, 60, 62, 32, 34, 36, 38],
       [40, 42, 44, 46, 48, 50, 52, 54, 56, 58],...
 y: array([[ 0,  2,  4,  6,  8, 10, 12, 14, 16, 18],
       [20, 22, 24, 26, 28, 30, 32, 34, 36, 38],
       [40, 42, 44, 46, 48, 50, 52, 54, 56, 58],...

----------------------------------------------------------------------
Ran 1 test in 0.005s

I'll probably implement a workaround to switch to serial code whenever 
broadcasting is detected, and will let this open until a proper solution would 
be devised.

Original issue reported on code.google.com by [email protected] on 31 Jul 2010 at 8:12

division in numexpr is not consistent with python

In [1]: 1/2
Out[1]: 0

In [2]: import numexpr
In [3]: numexpr.evaluate('1/2')
Out[3]: array(0, dtype=int32)

In [4]: from __future__ import division

In [5]: 1/2
Out[5]: 0.5

In [6]: numexpr.evaluate('1/2')
Out[6]: array(0, dtype=int32)

I would expect the presence of division in the namespace to cause 1/2=.5 
behavior.  It does not.  Instead you get 1/2=0 floor div behavior

Numexpr version= 1.3.1

Original issue reported on code.google.com by [email protected] on 10 Aug 2009 at 10:34

Optimization of "compilation phase" through a better hash

I've noticed that when I work with small arrays (~7000 rows), most of the time 
is spent before the actual computation begins, and most of that time is spend 
computing hashes over and over again (and this is especially apparent which 
profiling). FWIW, I have lots of expressions and some of them are used many 
times (approx. numrows times) with different data.

Here are two small patches which improve that particular use case. The first 
one is pretty conservative and improves the situation only a bit, the second 
one is more aggressive as it caches the hashes. This is is potentially wrong if 
the ASTNode instances are not readonly (except for the .reg). From my quick 
glance at the code it, they seem to be, but I could have missed something.

PS: I know this kind of use case is not optimal for numexpr, but the thing is 
my program can work with both relatively small and very large arrays.

FWIW, the timings of my program are as follow:
without patch: 1.26s
with 1st patch: 1.04s
with 2nd patch: 0.78s

Original issue reported on code.google.com by [email protected] on 21 Jan 2011 at 3:40

Attachments:

• cache_ast_hashes.patch
• faster_ast_hashes.patch

The multidimensional case does not show proper acceleration

Numexpr seems to have problems with speeding up expressions when they
contain multidimensional arrays, as it is shown by running the attached script:

{{{
1000000 f8 (average of 10 runs)
Simple:  0.0279412984848
Numexpr:  0.00955951213837
Chunked:  0.0293267965317
(10000, 100) f8 (average of 10 runs)
Simple:  0.0264149904251
Numexpr:  0.0360975027084
Chunked:  0.0355456829071
(100, 100, 100) f8 (average of 10 runs)
Simple:  0.0269222021103
Numexpr:  0.0370293140411
Chunked:  0.0356401920319
}}}

Original issue reported on code.google.com by [email protected] on 23 Jan 2009 at 11:25

Attachments:

• multidim.py

Numexpr should release the GIL during computations

The main loop that runs computations in the virtual machine is completely 
written in C, so GIL must be released during this stage.

Original issue reported on code.google.com by [email protected] on 20 Oct 2010 at 7:56

Unaligned arrays should not be copied on AMD/Intel architectures

AMD/Intel CPUs can deal with unaligned arrays directly, but also very
efficiently.  This is why a copy can be avoided in Numexpr when dealing
with unaligned arrays in AMD/Intel machines, thus accelerating computations
in this scenario still more.

Original issue reported on code.google.com by [email protected] on 23 Jun 2009 at 7:41

numexpr crashes python on win32 (numexpr-1.4.1.win32-py2.6.exe)

After installing using the provided installer (numexpr-1.4.1.win32-py2.6.exe), 
Python crashes when attempting to import the numexpr module.  

To reproduce:
1. Install numexpr-1.4.1.win32-py2.6.exe
2. Start python
3. type "import numexpr"

I am receiving an Application Error under Windows XP stating "The instruction 
at "0x00000000" referenced memory at "0x00000000".  The memory could not be 
"read"."  The python installation seems to be working fine outside of this 
error.

I'm working with Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 
bit (Intel)] on win32.

Original issue reported on code.google.com by [email protected] on 1 Dec 2010 at 2:04

Numexpr fails most tests with python 2.4

What steps will reproduce the problem?
1. python2.4 numexpr/tests/test_numexpr.py

What is the expected output? What do you see instead?
Almost all tests fail see attached output


What version of the product are you using? On what operating system?
Numexpr version:   1.4.2
NumPy version:     1.5.0
Python version:    2.4.3 (#1, Nov 11 2010, 13:30:19) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]
Platform:          linux2-x86_64
AMD/Intel CPU?     True
VML available?     False
Detected cores:    2

Distribution is Centos 5

Original issue reported on code.google.com by [email protected] on 11 Feb 2011 at 5:12

Attachments:

• failtest.txt
• buildlog.txt

The caches for expressions can potentially consume a lot of resources

Numexpr aggressively tries to cache parsed expressions in dictionaries so
as to minimize the overhead of parsing them.  However, doing this in
scenarios where a *lot* of different expressions are computed can lead to
very large dictionaries which consumes a lot of memory and CPU.  This
should be fixed.

Original issue reported on code.google.com by [email protected] on 23 Jan 2009 at 11:05

No AMD64 builds for numexpr 1.4 and Python 2.7

Any chance of adding these soon?

Thanks.

Original issue reported on code.google.com by [email protected] on 13 Oct 2010 at 7:45

VML support

It is desirable that numexpr have support for the Intel's Vector Math
Library (VML).  The implementation has started in the vml_support branch:

http://code.google.com/p/numexpr/source/browse/#svn/branches/vml_support

This ticket should be closed after the implementation is done and the above
branch closed.

Original issue reported on code.google.com by [email protected] on 19 Jan 2009 at 6:38

numexpr doesn't work in threading environments

The next script:

{{{
import numpy
import threading
from tables import numexpr

a = numpy.arange(10)

class ThreadTest(threading.Thread):
    def run(self):
        print "result-->", numexpr.evaluate('a**3')

test = ThreadTest()
test.start()

}}}

produces the next error in Numexpr:

{{{
Exception in thread Thread-1:
Traceback (most recent call last):
  File "threading.py", line 460, in __bootstrap
    self.run()
  File "thread-numexpr.py", line 12, in run
    print "result-->", numexpr.evaluate('a**3', optimization="none")
  File
"/home/faltet/PyTables/pytables/PyTablesPro/branches/multi-index-query/tables/nu
mexpr/compiler.py",
line 590, in evaluate
    _names_cache[expr_key] = getExprNames(ex, context)
  File
"/home/faltet/PyTables/pytables/PyTablesPro/branches/multi-index-query/tables/nu
mexpr/compiler.py",
line 565, in getExprNames
    ex = stringToExpression(text, {}, context)
  File
"/home/faltet/PyTables/pytables/PyTablesPro/branches/multi-index-query/tables/nu
mexpr/compiler.py",
line 194, in stringToExpression
    old_ctx = expressions._context.ctx
AttributeError: 'thread._local' object has no attribute 'ctx'

}}}


This is due to the fact that the import expressions is only evaluated for
the first thread, not for the others.

I'm attaching a patch for this.

Original issue reported on code.google.com by [email protected] on 14 Apr 2008 at 11:50

Attachments:

• numexpr-threading.patch

OP_NEG_LL treats the argument as an int, not a long long.

This fails:
>>> a = numpy.array([1, 2, 4, 8, 16, 2**31-1, 2**32-1, 2**63-1])
>>> a
array([                  1,                   2,                   4,
                         8,                  16, 2147483647, 4294967295,
       9223372036854775807], dtype=int64)
>>> evaluate('-a')
array([         -1,          -2,          -4,          -8,         -16,
       -2147483647,           1,           1], dtype=int64)

error is in interp_body.c, where OP_NEG_LL uses i1 instead of l1.

Original issue reported on code.google.com by [email protected] on 29 Jan 2010 at 2:19

undefined symbol: _gfortran_internal_malloc64

This is fedora F10 x86_64.  I did put:

[DEFAULT]
libraries = gfortran

And it did link correctly:
gcc -pthread -shared build/temp.linux-x86_64-2.5/numexpr/interpreter.o -
L/usr/lib64 -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core -liomp5 -lpthread -

But:
 sudo python setup.py install
mkl_info:
  libraries gfortran not found in /opt/intel/mkl/10.1.1.019/lib/em64t
Library gfortran was not found. Ignoring
  FOUND:
    libraries = ['mkl_gf_lp64', 'mkl_gnu_thread', 'mkl_core', 'iomp5',
'pthread']
    library_dirs = ['/opt/intel/mkl/10.1.1.019/lib/em64t']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/10.1.1.019/include']


But I think the REAL problem is that /usr/lib64/libgfortran.so doesn't
contain the missing symbol:

readelf -s /usr/lib64/libgfortran.so  | grep malloc64
[silence]

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 13 Feb 2009 at 3:10

vml not detected?

I installed mkl-10.1.1.019.  I edited site.cfg:

[mkl]

# Example for using MKL 10.0
library_dirs = /opt/intel/mkl/10.1.1.019/lib/em64t
include_dirs =  /opt/intel/mkl/10.1.1.019/include

# Example for the MKL included in Intel C 11.0 compiler
# (you may need a recent NumPy version for being able to search libraries
# in different directories at a time)
#library_dirs =
/opt/intel/Compiler/11.0/074/mkl/lib/em64t/:/opt/intel/Compiler/11.0/074/li
#include_dirs =  /opt/intel/Compiler/11.0/074/mkl/include/

##the following set of libraries is suited for compilation with the GNU C
##compiler (gcc). Refer to the MKL documentation if you use other compilers
##(e.g., Intel C compiler)
mkl_libs = mkl_gf_lp64, mkl_gnu_thread, mkl_core, iomp5

python setup.py build
mkl_info:
  FOUND:
    libraries = ['mkl_gf_lp64', 'mkl_gnu_thread', 'mkl_core', 'iomp5',
'pthread']
    library_dirs = ['/opt/intel/mkl/10.1.1.019/lib/em64t']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/10.1.1.019/include']

But then:
>>> import numexpr
>>> numexpr.test()
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Numexpr version:   1.2
NumPy version:     1.2.0
Python version:    2.5.2 (r252:60911, Sep 30 2008, 15:42:03) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)]
Platform:          linux2-x86_64
VML available?     False

Any hints?

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 13 Feb 2009 at 2:49