Describe the bug
np.complex64 and np.complex128 both accept 2 arguments: a real and imaginary part.
When called inside a kernel, however, these functions error with "too many positional arguments".
These leaves 2 methods to construct a complex number of a desire precision:
- To write
realpart + 1j * imagpart which (lexically at least) involves a needless complex multiplication operation. Of course it's possible the compiler elides this operation.
- To use
np.complex64(complex(realpart, imagpart)), since complex() will default to complex128. Again, it's not clear if this casting is elided by the compiler or not.
Expected behavior
I expect these functions to act as constructors for complex numbers using both real and imaginary components as arguments.
Describe the bug
np.complex64andnp.complex128both accept 2 arguments: a real and imaginary part.When called inside a kernel, however, these functions error with "too many positional arguments".
These leaves 2 methods to construct a complex number of a desire precision:
realpart + 1j * imagpartwhich (lexically at least) involves a needless complex multiplication operation. Of course it's possible the compiler elides this operation.np.complex64(complex(realpart, imagpart)), sincecomplex()will default tocomplex128. Again, it's not clear if this casting is elided by the compiler or not.Expected behavior
I expect these functions to act as constructors for complex numbers using both real and imaginary components as arguments.