Robert McLeod

Yes they haven't been implemented yet. This does remind me that I wrote a bunch of issues in London but didn't post them. How to handle reductions (e.g. `mean`, `sum`,...

It's been suggested in a number of places that we offer the ability to control the accumulator dtype (#236, #271), so this could be an additional keyword option in-addition to...

Unfortunately the NumExpr 2.6 reductions are single threaded so you will not see a performance improvement from using `sum` inside NumExpr. I would suggest you try, `dist_2 = ne.evaluate('(nodes -...

Fred, Ooph, I was writing a response and then Chrome crashed on me. Thanks for the article on machine precision. I've read a similar (yet less detailed) manuscript long ago...

Perhaps a intermediate approach would be to simply allow the ast parser to recognize `numpy.` attributes as potential function calls, so the user doesn't have to bother with dropping the...

Generally speaking NumExpr 2.6 does _not_ support logical operations. That you can trick it into using `is` is due to the fact that Python falls back on the `__eq__` dunder,...

The current, deployed branch (2.6) calls Python's `compile` and then generates its own custom AST from that. The development branch (3.0) actually uses the Python `ast` module and then parses...

Thanks for the suggestion but as `numexpr` is a requirement of modules like `pandas`, `pytables`, we basically have a hard rule against requiring any external modules outside of `numpy`. We...

A new `cpuinfo.py` has been pushed now in https://github.com/pydata/numexpr/commit/d35a846b1454f90d5d12be88100893b3cdd0a268 but it's quite slow so it will need some work.

Hi Frédéric, thanks for the suggestion. One problem I can see is a lot of people who have NumExpr installed don't have compilers, they're using pre-built wheels. I should mention...