@WarrenWeckesser I think your intuition is correct that there would be limitations to a complex_int_NN type, but this is not unique to complex integers. This is a general problem when dealing with fixed bitwidth integers. You get weird answers if you don't convert your data to a type that can handle the operation. consider

>>> np.square( np.int16( [ 181, 182 ] ) )
array([ 32761, -32412], dtype=int16)

Motivation for complex integers

The use case for complex integers is anywhere large amounts of complex data are to be stored efficiently. One might want to analyze/modify slices of the data (e.g. via memmapped file) without converting the whole thing.
Here are some example applications

radio signals digitized in "complex baseband" format
MRI raw samples
synthetic aperture radar (SAR) raw data
seismic data
Fourier data of any kind

As python (and jupyter) grows more popular for dealing with huge datasets, so does the need for a workable complex integer type.

Desired behavior

What would be nice is if basic manipulation worked as expected or gave an error when trying to do so.

# a complex `view` of integer data, analogous to casting  float32 as complex64
civec = some_ndarray_of_int16.view(  np.complex_int_32 )

# setting from a complex value should behave as expected
civec[:] = 1+2j # broadcasts/interleave int16 1,2 

# setting from a real value should zero the imag part, and vice versa
civec[:] = 42

# get/set  real or imag parts through attributes/properties
q = civec[:].imag # q should be an array of np.int16
civec[:].imag *= -1   # creates the complex conjugate  (same as q *= -1) 

# math manipulations should either work as expected or fail loudly
# (the former is more tempting, but perilous)
d = civec + civec # what is "expected" here?  wrap? clip?  promote sometimes? always?

# convert to a complex floating point class when more math is required
F = np.fft.fft( civec.astype(np.complex64) )

Partial solutions

Note a user-customized dtype (e.g. np.dtype([('real', np.int16), ('imag', np.int16)]) )
is not even close to the above desired behavior.
I've had some success combining such a custom dtype with an ndarray subclass that overrides __setitem__, and adds property/setters for real and imag.

Uh oh!

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions