Robert McLeod

You probably want to parse the expression with an Abstract Syntax Tree (AST) first before passing it to NumExpr. You can see the official documentation here: https://docs.python.org/3/library/ast.html and the better...

Explicit casting is on the timeline for NumExpr3.0. In the meantime, I would consider using NumPy to do the sum instead. I.e. return numexpr.evaluate( 'a*a' ).sum() It may be faster...

With NumExpr 2.6 there might be some memory-use advantage to using its `sum` but I haven't seem a benchmark time advantage to it, because it's single-threaded. I think this is...

Since Yeppp! is on Bitbucket it may be helpful to implement a CMake build for NumExpr3 that supports downloading it.

Min and max were implemented awhile ago. There is no room left for more opcodes, so clip cannot be implemented in NumExpr 2.7. I do believe `numexpr3` could have `clip`...

Oh, sorry, they are reductions. Element-wise could be done for `float32` and `float64` but not for integers.

Element-wise are not implemented at this time. However, you can use the `where` function instead. It's just uglier.

Such as this: import numexpr as ne import numpy as np a = np.array([2,3,4]) b = np.array([3,2,4]) out1 = ne.evaluate('where(a < 2, a, 2)') out2 = ne.evaluate('where(a < b, a,...

No, I'd suggest you look at `numba` for such a task.

There isn't any room left in the opcode space for a boolean sum in NumExpr 2.6 unfortunately. In general reductions in NumExpr 2.6 are single-threaded and don't show a speed...