Skip to content

Plotting irregular timeseries with different indexes: last plotted timeseries dictates xaxis range #2960

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

Closed
lesteve opened this issue Mar 2, 2013 · 4 comments · Fixed by #7322
Labels
Milestone

Comments

@lesteve
Copy link
Contributor

lesteve commented Mar 2, 2013

In the following I took the extreme case where there is no overlap between the two indexes for illustration purposes. When there is some overlap there is still the same issue and the last plotted timeseries is dictating the xaxis range.

Here is the code, tested on pandas 0.13.1:

import numpy as np
import pandas as pd
import pandas.util.testing
import matplotlib.pyplot as plt

np.random.seed(0)

ts = pd.util.testing.makeTimeSeries()[:20]
tsIrregular = ts.drop(ts.index[[3,7,11,16]])

def myPlot(ts):
    fig, axes = plt.subplots(1,2)
    ax = axes[0]
    ax.set_title('left series first')
    ts[:5].plot(ax=ax, label='left series')
    ts[6:].plot(style='or', ax=ax, label='right series')
    ax.legend(loc='best')

    ax = axes[1]
    ax.set_title('right series first')
    ts[6:].plot(style='or', ax=ax, label='right series')
    ts[:5].plot(ax=ax, label='left series')
    ax.legend(loc='best')

    return axes

myPlot(ts)
myPlot(tsIrregular)

What you get for the regular timeseries case is what you expect, i.e. the order you plot timeseries doesn't matter and the xaxis range is the union of the two timeseries indexes:
regularTimeSeries

but what you get for the irregular timeseries case is rather suprising:
irregularTimeSeries

There are easy work-arounds, like aligning the timeseries before plotting, but it feels like irregular timeseries shouldn't be second-class citizens compared to regular ones.

@jreback
Copy link
Contributor

jreback commented Mar 9, 2014

stale

@jreback jreback closed this as completed Mar 9, 2014
@lesteve
Copy link
Contributor Author

lesteve commented Mar 9, 2014

FWIW the behaviour is still the same in 0.13.1 (I slightly updated the code in the example to this effect)

I completely understand that it's not at the top of anyone's priority list though.

@jreback jreback reopened this Mar 9, 2014
@jreback jreback modified the milestones: 0.15.0, 0.14.0 Mar 9, 2014
@jreback
Copy link
Contributor

jreback commented Mar 9, 2014

you are welcome to submit a pr

@rosnfeld
Copy link
Contributor

Just wanted to note that I am working on this. A 1-line change can clear up the example presented above, all tests pass, and I think it's "correct", but unfortunately it then exposes a deeper version of the regular/irregular timeseries mismatch issue I noted in #6608. I'm tempted to try and fix both at once.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants