complex64 multipled by float32 produces a complex128

[sjperkins]

This occurs on numexpr 2.4, Ubuntu 14.04

The following evaluation results in a complex128 being produced, rather than a complex64. I don't think this follows the casting rules, but I may be interpreting them incorrectly.

import numexpr as ne
import numpy as np

A = (np.random.random(20) + np.random.random(20)*1j).astype(np.complex64)
B = np.random.random(20)
ne.evaluate('a*b', {'a':A,'b':B},out=A)

Without the out parameter, we could use astype as a stopgap. However, with an out parameter we can't output the result to the A array The following exception is thrown:

TypeError: Iterator requested dtype could not be cast from dtype('complex128') to dtype('complex64'), the operand 0 dtype, according to the rule 'safe'

[pakodekker]

@sjperkins did anything happen on this front? I see that you a pull request. Support for complex64 seems critical to me!

[sjperkins]

@pakodekker I started on it -- see the complex64 pull request. This became less critical for me and my time got taken up by other things, so I'm not actively pursuing it at present.

[robbmcleod]

I was able to get this working, you can see it on my page:

https://github.com/robbmcleod/numexpr

I will need to make some reverts to make it more compatible with the commits that have been made since Nov 2014 before it can be merged with the master branch. I've tested it with both the numexpr/tests/testexpr.py and bench/timing_complex.py.

Perhaps more importantly I tested it with my own code that also uses pyFFTW, and it plays nice with it. pyFFTW is really picky with regards to array alignment and dtype so I'm confident it's working. There are some casting issues, with regards to how does double cast to complex64.

[sjperkins]

@robbmcleod Great! I'm glad the initial work didn't go to waste.

[FrancescAlted]

@robbmcleod would you please send a PR of your work so that we can use that instead of #156? Thanks!

[robbmcleod]

There's still one outstanding problem of how to deal with real, imag, and
complex64 casts. The AST interpreter is really bad at figuring out return
signatures, so it casts them all to double.

I'm hopeful that it can be dealt with quickly, or at least that I can
figure out a work-around/hack.

[robbmcleod]

Closing as this was the case for the NumExpr-3 branch. Complex64 works as expected in NE3.

[mutricyl]

Working on pandas-dev/pandas#21374 I am Coming across unexpected complex128 upcasting.

The above example fails with numexpr 2.10. I am not sure to understand if it is solve in numexpr 3 branch which is not release yet or if it was solved in 2.3 and some kind of regression append since. @robbmcleod should this issue be re-opened ?

edit: some more details

>>> compl = 1 + 1j
>>> ne.evaluate('compl + 2').dtype
dtype('complex128')
>>> ne.evaluate('compl + compl').dtype
dtype('complex128')
>>> compl+compl
(2+2j)
>>> type(compl+compl)
<class 'complex'>
>>> type(compl+2)
<class 'complex'>