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.

Sign up for GitHub

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

Jump to bottom

subplots=True automatic xlim considers nan values since 0.24 #25160

Open
JoElfner opened this issue Feb 5, 2019 · 6 comments
Open

subplots=True automatic xlim considers nan values since 0.24 #25160

JoElfner opened this issue Feb 5, 2019 · 6 comments
Assignees
@arvinnick
Labels
Bug Visualization plotting

Comments

@JoElfner
Copy link
Contributor

JoElfner commented Feb 5, 2019

Code Sample,:

df = pd.DataFrame(np.random.rand(10, 2))
df.iloc[5:, 1] = np.nan
df.iloc[:5, 0] = np.nan

figs, axs = plt.subplots(2, 1)
df.plot.line(ax=axs, subplots=True, sharex=False)

Problem description

The code sample above produces two plots with different x-limits in pandas version 0.23.4, whereas in 0.24.0 both subplots share the same x-limits.
In my opinion the behavior of pandas version 0.23.4 should be correct, whereas the behavior of 0.24.0 resembles setting sharex=True.

Looking at the changelog, I haven't found any informationen on an intended change, thus I report it as a bug.

Is there any workaround for this which is still using automatic x-limit scaling?
Separate line plotting for example does not solve the problem:

figs, axs = plt.subplots(2, 1, sharex=False)

df.iloc[:,0].plot.line(ax=axs[0], subplots=False)
df.iloc[:,1].plot.line(ax=axs[1], subplots=False)

Expected Output

Expected output is attached as pdf.

Output of pd.show_versions() for 0.24.0

INSTALLED VERSIONS

commit: None
python: 3.7.1.final.0
python-bits: 64
OS: Windows
OS-release: 7
machine: AMD64
processor: Intel64 Family 6 Model 63 Stepping 2, GenuineIntel
byteorder: little
LC_ALL: None
LANG: en
LOCALE: None.None

pandas: 0.24.0
pytest: 4.0.2
pip: 18.1
setuptools: 40.6.3
Cython: 0.29.2
numpy: 1.15.4
scipy: 1.1.0
pyarrow: None
xarray: None
IPython: 7.2.0
sphinx: 1.8.2
patsy: 0.5.1
dateutil: 2.7.5
pytz: 2018.7
blosc: None
bottleneck: 1.2.1
tables: 3.4.4
numexpr: 2.6.8
feather: None
matplotlib: 3.0.2
openpyxl: 2.5.12
xlrd: 1.2.0
xlwt: 1.3.0
xlsxwriter: 1.1.2
lxml.etree: 4.2.5
bs4: 4.6.3
html5lib: 1.0.1
sqlalchemy: 1.2.15
pymysql: None
psycopg2: None
jinja2: 2.10
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None
gcsfs: None

Output of ``pd.show_versions() for 0.23.4

Expected output
``

INSTALLED VERSIONS

commit: None
python: 3.7.1.final.0
python-bits: 64
OS: Windows
OS-release: 7
machine: AMD64
processor: Intel64 Family 6 Model 63 Stepping 2, GenuineIntel
byteorder: little
LC_ALL: None
LANG: en
LOCALE: None.None

pandas: 0.23.4
pytest: 4.0.2
pip: 18.1
setuptools: 40.6.3
Cython: 0.29.2
numpy: 1.15.4
scipy: 1.1.0
pyarrow: None
xarray: None
IPython: 7.2.0
sphinx: 1.8.2
patsy: 0.5.1
dateutil: 2.7.5
pytz: 2018.7
blosc: None
bottleneck: 1.2.1
tables: 3.4.4
numexpr: 2.6.8
feather: None
matplotlib: 3.0.2
openpyxl: 2.5.12
xlrd: 1.2.0
xlwt: 1.3.0
xlsxwriter: 1.1.2
lxml: 4.2.5
bs4: 4.6.3
html5lib: 1.0.1
sqlalchemy: 1.2.15
pymysql: None
psycopg2: None
jinja2: 2.10
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None
@gfyoung gfyoung added the Visualization plotting label Feb 7, 2019
@gfyoung gfyoung added this to the 0.24.2 milestone Feb 7, 2019
@gfyoung
Copy link
Member

gfyoung commented Feb 7, 2019

cc @TomAugspurger

Feel free to change the milestone as you see fit. That being said, this sounds like a behavior change (whether correct or intentional or not).

@JoElfner
Copy link
Contributor Author

JoElfner commented Feb 7, 2019

Imho seing this from a perspective of someone who is working with timeseries 24/7, this change of behavior should be unintentional.
Having synchronized axis is covered by sharex=True, while the behavior of the 0.23.4 "un"shared x-axis currently requires much larger effort to reproduce. Automatically sharing the x-axis of subplots (even though they are not shared in the meaning of setting new limits etc.) is imho not a desired output when working with data.
Thus I'd strongly prefer the behavior of version 0.23.4 .

@TomAugspurger
Copy link
Contributor

All else equal, we probably want to match matplotlib's behavior. But we would need to understand why this changed first. It'd be helpful if someone could bisect which commit caused the change.

@TomAugspurger TomAugspurger modified the milestones: 0.24.2, Contributions Welcome Mar 6, 2019
@TomAugspurger
Copy link
Contributor

Pushing off 0.24.2.

@charlesdong1991 charlesdong1991 mentioned this issue Aug 18, 2019
Merged
5 tasks
@mroeschke mroeschke added the Bug label Jun 26, 2021
@mroeschke mroeschke removed this from the Contributions Welcome milestone Oct 13, 2022
@arvinnick
Copy link

take

@arvinnick
Copy link

take

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@arvinnick arvinnick

Labels
Bug Visualization plotting
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@TomAugspurger @gfyoung @mroeschke @JoElfner @arvinnick