| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
|
||
|
|
||
| def _to_ordinalf(dt): | ||
| def _to_ordinalf(dts): |
There was a problem hiding this comment.
I think it's probably worth writing a new function called something like _dtime64_to_ordinalf(dts) with the new code to handle np.datetime64s. (for clarity)
Sorry, something went wrong.
|
The normal use case would be with an ndarray of dtype np.datetime64. The conversion of this to matplotlib float datenums should be direct and vectorized--no loop--otherwise the performance will be terrible. |
Sorry, something went wrong.
|
|
||
| locator.set_axis(self.axis) | ||
|
|
||
| if self.axis is not None: |
There was a problem hiding this comment.
ooops, I guess I missed a rebase here. Will fix after
Sorry, something went wrong.
| zerod = False | ||
| if isinstance(d, np.datetime64): | ||
| zerod = True | ||
| d = np.atleast_1d(d) |
There was a problem hiding this comment.
It runs for me without converting a single item into array and back. This is needed for some older numpy (mine is 1.13.3)?
Sorry, something went wrong.
There was a problem hiding this comment.
Hmmm, I didn't even try! You're right..
Sorry, something went wrong.
| d = np.atleast_1d(d) | ||
| extra = d - d.astype('datetime64[s]') | ||
| extra = extra.astype('timedelta64[ns]') | ||
| t0 = np.datetime64('0001-01-01T00:00:00').astype('datetime64[s]') |
There was a problem hiding this comment.
t0 = np.datetime64('0001-01-01T00:00:00', 's')
Sorry, something went wrong.
| import matplotlib.dates as mdates | ||
|
|
||
|
|
||
| def test_date_numpyx(): |
There was a problem hiding this comment.
any reason this isn't done with base/time/timenp being pytest fixtures and the test parameterized or split into two?
Sorry, something went wrong.
There was a problem hiding this comment.
Because I can understand this, and I have no idea what a pytest fixture is. Is there an advantage to doing something more obscure than a simple assert?
Sorry, something went wrong.
There was a problem hiding this comment.
Only cause you're repeating yourself a lot so it's hard to tell what the specific tests are. Factoring out common features into a fixture means you can make two tests that are uniquely named for the things they're testing.
Sorry, something went wrong.
There was a problem hiding this comment.
I'll look into it. OTOH, I find some of the tests aren't very easy to follow. Sometime verbosity is a good thing!
Sorry, something went wrong.
There was a problem hiding this comment.
OK, happy to take suggestions, but I find the uses of fixtures in the existing tests makes for pretty obfuscated code.
Sorry, something went wrong.
There was a problem hiding this comment.
shrugs can agree on that somewhat, either way it's not something I'd hold the PR up on.
Sorry, something went wrong.
There was a problem hiding this comment.
Well, I didn't mean to say I wasn't willing to learn, just that I don't get it... More than happy if you wanted to push a change or give me some pseudo code to get it to work... Thanks!
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry for missing your reply (the embedded ones seem to not pop up as notifications), and will totally try to remember your suggestion for the future. I should have been way clearer on what I wanted and given you an example. :/
Sorry, something went wrong.
| assert np.array_equal(h.get_ydata(orig=False), hnp.get_ydata(orig=False)) | ||
|
|
||
|
|
||
| def test_date_date2num_numpy(): |
There was a problem hiding this comment.
same here, could this be parameterized with ids?
Sorry, something went wrong.
There was a problem hiding this comment.
I sympathise with @jklymak re. pytest, (I still have no idea what a fixture is) but find paramaterising fairly easy to understand (https://docs.pytest.org/en/latest/parametrize.html)
Something like this should work:
@pytest.mark.parametrize('t0', [datetime.datetime(2017, 1, 1, 0, 1, 1),
[datetime.datetime(2017, 1, 1, 0, 1, 1),
datetime.datetime(2017, 1, 1, 1, 1, 1)],
[[datetime.datetime(2017, 1, 1, 0, 1, 1),
datetime.datetime(2017, 1, 1, 1, 1, 1)],
[datetime.datetime(2017, 1, 1, 2, 1, 1),
datetime.datetime(2017, 1, 1, 3, 1, 1)]]])
@pytest.mark.parameterize('dtype', ['datetime64[s]',
'datetime64[us]',
'datetime64[ms]'])
def test_date_numpyx(t0, dytpe):
time = mdates.date2num(t0)
tnp = np.array(t0, dtype=dtype)
nptime = mdates.date2num(tnp)
assert time == nptimeThis will run through every possible combination of t0 and dtype, and avoids copy/pasting the actual testing code.
Sorry, something went wrong.
There was a problem hiding this comment.
OK, I agree that parametrize works well here (despite pytests odd way of spelling it) Thanks for the example!
Sorry, something went wrong.
|
That was easier than I expected... |
Sorry, something went wrong.
|
Could someone open up a follow-on PR to add a whats_new about this? |
Sorry, something went wrong.
|
Oops sorry I’ll do so tonight and prob add an example as well. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
This allows numpy.datetime64 dates. New and improved!
works fine.
PR Checklist