Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display precision doesn't affect complex float numbers #25514

Closed
jay-pee opened this issue Mar 1, 2019 · 5 comments

Comments

@jay-pee
Copy link

commented Mar 1, 2019

Code Sample

import numpy as np
import pandas as pd

pd.set_option("display.precision", 3)

A = np.random.rand(3,3)
df_A = pd.DataFrame(A)

B = np.random.rand(3,3)+1j*np.random.rand(3,3)
df_B = pd.DataFrame(B)

print(df_A)
print(df_B)

Output:

    0      1      2
0  0.665  0.824  0.953
1  0.341  0.078  0.408
2  0.945  0.411  0.078
                                            0  \
0    (0.2553045397887609+0.8464631779709604j)   
1  (0.5724405361700162+0.047300152111596105j)   
2     (0.5824766758024993+0.974755917539835j)   

                                           1  \
0  (0.3533797280121552+0.20515824034905894j)   
1    (0.928312255311234+0.3909443194373995j)   
2   (0.2700966337410404+0.9137483492310767j)   

                                           2  
0  (0.21748538025578568+0.7730350615682122j)  
1  (0.2435709287109903+0.46366472945887327j)  
2   (0.6531622218102532+0.5102462678094016j)

Problem description

Display precision (pd.set_option("display.precision", 3)) doesn't affect complex float numbers like shown in the example.

Expected Output

    0      1      2
0  0.665  0.824  0.953
1  0.341  0.078  0.408
2  0.945  0.411  0.078

               0               1               2
0   0.976+0.935j    0.739+0.851j    0.436+0.734j
1   0.998+0.867j    0.774+0.849j    0.553+0.749j
2   0.405+0.049j    0.965+0.912j    0.292+0.958j

Output of pd.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.6.7.final.0
python-bits: 64
OS: Windows
OS-release: 10
machine: AMD64
processor: Intel64 Family 6 Model 142 Stepping 9, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: None.None

pandas: 0.23.4
pytest: None
pip: 18.1
setuptools: 39.0.1
Cython: 0.29
numpy: 1.15.4
scipy: 1.1.0
pyarrow: None
xarray: None
IPython: 7.1.1
sphinx: None
patsy: None
dateutil: 2.7.5
pytz: 2018.9
blosc: None
bottleneck: 1.2.1
tables: None
numexpr: None
feather: None
matplotlib: 3.0.1
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: None
sqlalchemy: None
pymysql: None
psycopg2: None
jinja2: 2.10
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

@mroeschke

This comment has been minimized.

Copy link
Member

commented Mar 3, 2019

Agreed. Investigations and PR's welcome!

@sakarpanta

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2019

I'm relatively new to the project but here is what I found:
Currently format.py doesn't handle complex values formatting properly. For integers there is an IntArrayFormatter, for floats a FloatArrayFormatter and so on. The complex numbers are complex128 data types and are fed into a GenericArrayFormatter which just outputs the values however Numpy generates them. We need something like a ComplexArrayFormatter.

This ComplexArrayFormatter needs to distinguish between a complex float array and a complex int array, and for this, an is_complex_float type checker is needed in the util library. It would then need to apply the display.precision for complex floats (as is done for floats) and the return the proper formatted output.

@mroeschke

This comment has been minimized.

Copy link
Member

commented Mar 13, 2019

Maybe we can just dispatch the complex formatting to the FloatArrayFormatter? pandas only (somewhat) supports Numpy's complex dtypes which are all float based AFAICT.

@sakarpanta

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2019

Yes, the FloatArrayFormatter will format to the display.precision properly, but after that all complex numbers will have the format of 1.0+2.0j instead of (1+2j). Is this something we might be okay with?

@jay-pee

This comment has been minimized.

Copy link
Author

commented Mar 14, 2019

I think this would be perfectly fine, after all the complex numbers is still a float (in this case) and when you have the dot zero format you immediately know that it is a float and not an integer complex number. Its the same reason why you have the dot zero format for plain float numbers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.