Add complex64 support to numexpr. #156
Conversation
|
numexpr compiles at present and all tests run, except for test_reductions and the test_complexf_expr test that I added. I'm not sure how to proceed from here, so help would be appreciated at this point. Also, I've chosen the 'x' character for the complex float opcode. Any other suggestions? |
|
Looks pretty good to me! I am fine with the 'X' character for the complex64 opcodes. I don't know what is happening here. I would recommend doing a bit more of debugging and it things does not improve, then ask for more help in the mailing list. |
… 128 byte range of ASCII characters. We need access to the 128-255 range. Thus, we use unicode(opcode).encode('latin-1'), since this code page encoding converts the 128-255 range perfectly. See http://en.wikipedia.org/wiki/ISO/IEC_8859-1 for e.g. and the following
for i in range(255): assert ord(unichr(i).encode('latin-1')) == i
also works.
|
This entry serves as a record. We need to handle:
|
|
@FrancescAlted I'm struggling a bit with how the numexpr parser handles things internally. As far as I understand the code, it consistently tries to convert types in an expression into internal Python types. e.g. bytes, strings,ints, floats, doubles and complexes. However, Python doesn't have an internal type for single-precision complex numbers. I'm trying to use np.complex64 instead, but it feels like I'm working against a particular coding stategy here. It would be helpful if I could get some input from someone who understand the parser internals at this point. Time for the mailing list? |
|
Well, in numexpr there is support for int32 and int64 as well as for float32 and float64 and for these types some numpy types are used. So in that light I think that using np.complex64 is just fine. Regarding the casting rules, numexpr follows this: https://github.com/pydata/numexpr/wiki/Numexpr-Users-Guide#casting-rules so you should try to implement the same for complex64 / complex128. |
|
OK. I'm trying to get to grips with the mapping. It seems to me that, in a general sense, there's a Python types -> NumPy Types and a NumPy types -> Python Types mapping in the code. The first case is easy enough to understand, but the second seems less clear to me. An example of the latter is here. In the above example, I could distinguish between np.complex64 and np.complex128 as in the case for the floats, but it seems that we have to return a python type here. I guess I could try return an np.complex64 but thats not a plain Python type. So my first question is how you would handle this case? Also, it looks like the expression gets cast into Python types before being passed into the AST parser. I'm guessing this casting happens because the ast library doesn't inherently understand NumPy types? And then there's a step to go back to the actual NumPy types once the tree has been produced? I'm trying to figure out the bidirectionality here. Thanks for your help :) |
|
Hi, new pull request is here (intended to be for discussion more than accepted as is): |
|
Closing as this was the case for the NumExpr-3 branch. |
Hi, I thought I'd have a stab at adding complex64 support to numexpr, since after logging #155, I realised that support doesn't seem to exist.