BUG: Printing of a pandas Series of complex numbers with e-notation has broken between 2.0.x and older versions and the newer 2.1.x, 2.2.x versions

[gitBwhitlat]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd
input_array = [(1.8816e-09+0j), (3.39676e-09+0j)]
print("input_array=\n", input_array)
print("pd.Series(input_array)=\n", pd.Series(input_array))

Issue Description

We use the pandas Series method to store a list of complex numbers but when upgrading from the pandas 1.3, 1.5, or 2.0 versions we are seeing a regression issue where in pandas 2.1.x and 2.2.x and latest 2.2.3 version the print out is adding extra white space to the imaginary value's e-notation portion.

example:
import pandas as pd
input_array = [(1.8816e-09+0j), (3.39676e-09+0j)]
print("input_array=\n", input_array)
print("pd.Series(input_array)=\n", pd.Series(input_array))

For example in pandas 1.3, 1.5, 2.0.3 we see the following output that we expect from the following example:

input_array=
[(1.8816e-09+0j), (3.39676e-09+0j)]
pd.Series(input_array)=
0 1.881600e-09+0.000000e+00j
1 3.396760e-09+0.000000e+00j
dtype: complex128

But now in pandas version 2.1.x, 2.2.x, and latest 2.2.3 we are getting the output instead:
input_array=
[(1.8816e-09+0j), (3.39676e-09+0j)]
pd.Series(input_array)=
0 1.881600e-09+0.000000e+ 00j
1 3.396760e-09+0.000000e+ 00j
dtype: complex128

Thanks.

Expected Behavior

The expected output is the following:
input_array=
[(1.8816e-09+0j), (3.39676e-09+0j)]
pd.Series(input_array)=
0 1.881600e-09+0.000000e+00j
1 3.396760e-09+0.000000e+00j
dtype: complex128

Where the +0j portion of the complex value is printed as +0.000000e+00j
not what it is printed now as: 0.000000e+ 00j

Installed Versions

INSTALLED VERSIONS

commit : 0691c5c
python : 3.12.2
python-bits : 64
OS : Windows
OS-release : 10
Version : 10.0.19045
machine : AMD64
processor : Intel64 Family 6 Model 141 Stepping 1, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : English_United States.1252

pandas : 2.2.3
numpy : 1.26.4
pytz : 2024.2
dateutil : 2.9.0.post0
pip : 24.2
Cython : None
sphinx : None
IPython : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
blosc : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.4
lxml.etree : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
psycopg2 : None
pymysql : None
pyarrow : None
pyreadstat : None
pytest : 8.3.3
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
tzdata : 2024.2
qtpy : None
pyqt5 : None

Thanks

[asishm]

Thanks for the report. Confirmed on main

[snitish]

I believe this is due to the regex in the _trim_zeros_complex function not being able to handle +/- in the exponent. It assumes the complex number string to be of the form (-)xxx(+/)yyyj. I raised a PR to fix the regex so it doesn't split on +/- if preceded by an exponent: #60405