Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Secondary axis called with [0, 1] might produce exceptions in case these are invalid data #14270

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
Closed
maxnoe opened this issue May 20, 2019 · 9 comments
Closed

Secondary axis called with [0, 1] might produce exceptions in case these are invalid data #14270

maxnoe opened this issue May 20, 2019 · 9 comments
Milestone
v3.2.0

Comments

@maxnoe
Copy link
Contributor

maxnoe commented May 20, 2019 •
edited
Loading

Bug report

Transform functions for the new feature secondary_xaxis are always called with 0 and 1 at
instantiation, which might be invalid input for transformations.

Code for reproduction

E.g. trying to get a secondary axis showing mjd for a date axis

import matplotlib.pyplot as plt
from matplotlib.dates import date2num, num2date
from datetime import datetime, timedelta
import numpy as np


MJDREF = datetime(1858, 11, 17, 0)


def trans(mpl_date):
    print(mpl_date)
    return (num2date(mpl_date) - MJDREF).total_seconds() / 86400


def inv(mjd):
    return date2num(MJDREF + timedelta(days=mjd))


t = np.array(['2018-01-01', '2018-03-03', '2018-04-10'], dtype='datetime64[s]')


fig, ax = plt.subplots()
ax.plot(t, [1, 2, 1])

t_ax = ax.secondary_xaxis('top', functions=(trans, inv))

Results in:

ValueError: Cannot convert 0 to a date.  This often happens if non-datetime values are passed to an axis that expects datetime objects.

Matplotlib version

  • Operating system: linux, but should be indepenent
  • Matplotlib version: 3.1
  • Matplotlib backend: all
  • Python version: 3.7
@anntzer
Copy link
Contributor

anntzer commented May 20, 2019

I think the 0-1 invalid values problem is mostly fixed by #13593 (already merged), although there are some subsequent problems:

  1. num2date returns a list, so subtracting MJDREF results in TypeError: unsupported operand type(s) for -: 'list' and 'datetime.datetime'.
  2. even casting the result to an array
def trans(mpl_date):
    return (np.asarray(num2date(mpl_date)) - MJDREF).total_seconds() / 86400

results in TypeError: can't subtract offset-naive and offset-aware datetimes.

So I think at that point (in master) it's more a datetime handling problem (well, I don't know enough about datetime handling to really judge) rather than a secondary_axis problem. Perhaps(??) it would be nice to have a num2datearray that returns a numpy array rather than a list of datetimes?

@jklymak
Copy link
Member

jklymak commented May 20, 2019

Sorry secondary_axis has some issues. Thanks for trying it out! I’m away from computer until next weekend so I can’t look at this right away.

@maxnoe
Copy link
Contributor Author

maxnoe commented May 20, 2019

Btw. I found an easy solution, see: https://gist.github.com/MaxNoe/3deef353cf377245f28a04f32dee6ee8

Still, I think it's a bit surprising that functions get called with hard-coded 0, 1

@maxnoe
Copy link
Contributor Author

maxnoe commented May 20, 2019

results in TypeError: can't subtract offset-naive and offset-aware datetimes.

Works if you specify tzinfo=timezone.utc for the MJDREF.

@jklymak
Copy link
Member

jklymak commented May 20, 2019

I guess new axes have to be instantiated with some limits. But in this case I guess secondary axes should check the parent axes at least before it tries to get ticks etc.

@maxnoe
Copy link
Contributor Author

maxnoe commented May 20, 2019

The [0, 1] thingy is gone on master, so I'll close this. Thx for the help.

@maxnoe maxnoe closed this as completed May 20, 2019
@jklymak
Copy link
Member

jklymak commented May 20, 2019

Ok but does it need to be backported to 3.1.x?

@jklymak jklymak reopened this May 20, 2019
@dstansby
Copy link
Member

I think #13593 is probably too big to backport to master, but maybe if there's not an easier fix to this problem we could?

@anntzer anntzer added this to the v3.1.2 milestone Oct 16, 2019
@tacaswell
Copy link
Member

Given the scale of the backport that would be required, and that 3.2 is coming out soon, marking this as 3.2 and closing.

@tacaswell tacaswell modified the milestones: v3.1.2, v3.2.0 Oct 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v3.2.0
Development

No branches or pull requests
5 participants
@tacaswell @anntzer @jklymak @maxnoe @dstansby