gradient() function now supports datetime64 and timedelta64#167
gradient() function now supports datetime64 and timedelta64#167WeatherGod wants to merge 4 commits intonumpy:masterfrom
Conversation
Also allows for an array-like input instead of strictly numpy arrays.
|
actually, good thing we have the existing tests. My change breaks masked arrays (which I find surprising given how much I have been pushing for their support...). The problem with zeros_like() is that it does not take a dtype argument, as that would defeat the point of the *_like() part of the function. Not exactly sure how to make this work, but I am going to go ahead and push up my test case. |
|
zeros_like does take a dtype argument, why wouldn't it? By default it matches the prototype's dtype, but it makes sense to me to be able to override the dtype. |
|
Hmm, I guess that's what I get for assuming... I will change it to use zeros_like. Side note: would empty_like() be better since we are filling in the data anyway? |
|
empty_like seems like a good idea to me, yeah. It's hard to see at a glance that the various slices are covering all of out, but if they don't that's probably a bug. |
feat: Add vmax[q]_[s16|s32|f32|u8|u16|u32]
3 participants
Needed to keep gradient() from changing the output type to floats.
Also allows for an array-like input instead of strictly numpy arrays.
Yes, I know... we need tests... I will get to that after the mpl release.