From [email protected] on June 18, 2009 10:28:37

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

Attachment: add-abs.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=20

From [email protected] on June 23, 2008 19:38:10
#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: http://code.google.com/p/numexpr/issues/detail?id=6

From [email protected] on February 13, 2009 16:45:30

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: http://code.google.com/p/numexpr/issues/detail?id=16

From [email protected] on January 23, 2009 12:25:26

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
}}}

Attachment: multidim.py

Original issue: http://code.google.com/p/numexpr/issues/detail?id=12

From [email protected] on August 06, 2010 15:50:20

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 ofthr
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 ofcou
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 ofcou
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 ofcou
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 functioncheck_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 functionpthread_m
utex_lock'
numexpr\interpreter.c:1039: warning: implicit declaration of function pthread_c ond_wait' numexpr\interpreter.c:1042: warning: implicit declaration of functionpthread_c
ond_broadcast'
numexpr\interpreter.c:1044: warning: implicit declaration of function pthread_m utex_unlock' numexpr\interpreter.c: In functioninit_threads':
numexpr\interpreter.c:1284: warning: implicit declaration of function pthread_m utex_init' numexpr\interpreter.c:1288: warning: implicit declaration of functionpthread_c
ond_init'
numexpr\interpreter.c:1294: warning: implicit declaration of function pthread_c reate' numexpr\interpreter.c: In functionnumexpr_set_nthreads':
numexpr\interpreter.c:1342: warning: implicit declaration of function pthread_j oin' numexpr\interpreter.c: In functionnumexpr_free_resources':
numexpr\interpreter.c:1395: warning: implicit declaration of function pthread_m utex_destroy' numexpr\interpreter.c:1397: warning: implicit declaration of functionpthread_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: http://code.google.com/p/numexpr/issues/detail?id=31

From [email protected] on September 27, 2010 11:33:29

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: http://code.google.com/p/numexpr/issues/detail?id=33

From [email protected] on January 19, 2009 19:38:11

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: http://code.google.com/p/numexpr/issues/detail?id=9

From [email protected] on November 15, 2010 16:18:45

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: http://code.google.com/p/numexpr/issues/detail?id=37

From [email protected] on April 14, 2008 13:50:39

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/numexpr/compiler.py",
line 590, in evaluate
_names_cache[expr_key] = getExprNames(ex, context)
File
"/home/faltet/PyTables/pytables/PyTablesPro/branches/multi-index-query/tables/numexpr/compiler.py",
line 565, in getExprNames
ex = stringToExpression(text, {}, context)
File
"/home/faltet/PyTables/pytables/PyTablesPro/branches/multi-index-query/tables/numexpr/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.

Attachment: numexpr-threading.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=2

From [email protected] on May 03, 2011 17:39:28

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.

Attachment: mingw_build.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=50

From [email protected] on April 14, 2008 14:26:04

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('a3', optimization="none")
print "result-->", numexpr.evaluate('a3', 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: http://code.google.com/p/numexpr/issues/detail?id=3

From [email protected] on July 27, 2010 16:22:24

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.

Attachment: numexpr_bool_ops.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=28

From [email protected] on August 11, 2009 00:34:05

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: http://code.google.com/p/numexpr/issues/detail?id=22

Hi,

is this the official repository to post issues or this one:

https://code.google.com/p/numexpr/

?

From [email protected] on February 01, 2011 20:19:51

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 tosqrt'

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: http://code.google.com/p/numexpr/issues/detail?id=44

From [email protected] on December 01, 2010 15:04:53

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: http://code.google.com/p/numexpr/issues/detail?id=40

From [email protected] on October 13, 2010 21:45:17

Any chance of adding these soon?

Thanks.

Original issue: http://code.google.com/p/numexpr/issues/detail?id=34

From [email protected] on February 20, 2011 21:34:15

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: http://code.google.com/p/numexpr/issues/detail?id=46

From [email protected] on March 30, 2011 07:27:17

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: http://code.google.com/p/numexpr/issues/detail?id=49

From [email protected] on January 19, 2009 19:41:38

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: http://code.google.com/p/numexpr/issues/detail?id=10

From [email protected] on July 31, 2010 22:12:54

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: http://code.google.com/p/numexpr/issues/detail?id=30

From [email protected] on February 05, 2010 10:23:51

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: http://code.google.com/p/numexpr/issues/detail?id=26

From [email protected] on June 23, 2008 19:29:32

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.

Attachment: numexpr-unaligned.patch numexpr-unaligned-1.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=4

From [email protected] on January 21, 2011 16:03:38

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: http://code.google.com/p/numexpr/issues/detail?id=42

From [email protected] on November 01, 2010 22:18:57

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: http://code.google.com/p/numexpr/issues/detail?id=36

From [email protected] on June 23, 2009 09:41:30

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: http://code.google.com/p/numexpr/issues/detail?id=21

From [email protected] on September 08, 2009 22:54:48

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: http://code.google.com/p/numexpr/issues/detail?id=23

From [email protected] on July 21, 2010 12:09:42

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: http://code.google.com/p/numexpr/issues/detail?id=27

From [email protected] on January 17, 2009 05:00:17

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

In [1]: import numexpr

IOError Traceback (most recent call last)

/Users/fonnesbeck/ in ()

/Library/Frameworks/Python.framework/Versions/4.1.30101/lib/python2.5/site-packages/numexpr-1.1-py2.5-macosx-10.3-i386.egg/numexpr/init.py
in ()
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-packages/numexpr-1.1-py2.5-macosx-10.3-i386.egg/numexpr/VERSION'

Original issue: http://code.google.com/p/numexpr/issues/detail?id=8

From [email protected] on June 17, 2009 17:19:17

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/ in ()

/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: http://code.google.com/p/numexpr/issues/detail?id=19

From [email protected] on January 21, 2011 16:40:46

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

Attachment: cache_ast_hashes.patch faster_ast_hashes.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=43

From jakob.malm on January 14, 2011 08:58:30

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: http://code.google.com/p/numexpr/issues/detail?id=41

From [email protected] on December 12, 2009 04:23:42

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: http://code.google.com/p/numexpr/issues/detail?id=24

From [email protected] on July 31, 2010 03:23:14

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: http://code.google.com/p/numexpr/issues/detail?id=29

From [email protected] on February 13, 2009 21:04:15

I should remember doing this for every release.

Original issue: http://code.google.com/p/numexpr/issues/detail?id=17

From [email protected] on February 11, 2011 18:12:25

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

Attachment: failtest.txt buildlog.txt

Original issue: http://code.google.com/p/numexpr/issues/detail?id=45

From [email protected] on November 28, 2010 10:40:15

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: http://code.google.com/p/numexpr/issues/detail?id=39

From [email protected] on March 05, 2009 14:31:30

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: http://code.google.com/p/numexpr/issues/detail?id=18

From [email protected] on February 28, 2011 19:39:17

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_t2)* cos(x3+x4*t+x5t)')

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

Original issue: http://code.google.com/p/numexpr/issues/detail?id=47

From [email protected] on February 13, 2009 15:49:46

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: http://code.google.com/p/numexpr/issues/detail?id=14

From [email protected] on November 19, 2010 10:55:05

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

Attachment: loop_optimization.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=38

From [email protected] on January 23, 2009 12:05:32

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: http://code.google.com/p/numexpr/issues/detail?id=11

From [email protected] on February 13, 2009 16:10:04

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: http://code.google.com/p/numexpr/issues/detail?id=15

From [email protected] on March 10, 2008 17:34:03

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: http://code.google.com/p/numexpr/issues/detail?id=1

From [email protected] on September 03, 2010 15:40:59

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: http://code.google.com/p/numexpr/issues/detail?id=32

From [email protected] on October 20, 2010 09:56:33

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: http://code.google.com/p/numexpr/issues/detail?id=35

From [email protected] on November 11, 2008 18:20:44

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

Attachment: r3997-ne.patch r3998-ne.patch

Original issue: http://code.google.com/p/numexpr/issues/detail?id=7

From [email protected] on June 23, 2008 19:35:28

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.

Attachment: numpy_funcs.diff check_to_test.diff

Original issue: http://code.google.com/p/numexpr/issues/detail?id=5

From [email protected] on March 22, 2011 23:59:51

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-macosx-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-macosx-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: http://code.google.com/p/numexpr/issues/detail?id=48

From [email protected] on January 29, 2010 15:19:16

This fails:

a = numpy.array([1, 2, 4, 8, 16, 231-1, 232-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: http://code.google.com/p/numexpr/issues/detail?id=25