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

Skip to content

bug in nansum with non-float64 dtypes #6209

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
Open
jreback opened this issue Aug 14, 2015 · 10 comments
Open

bug in nansum with non-float64 dtypes #6209

jreback opened this issue Aug 14, 2015 · 10 comments
Labels
00 - Bug component: numpy.lib

Comments

@jreback
Copy link

jreback commented Aug 14, 2015 •
edited by seberg
Loading

These non-float nansum's are a little suspect
xref pandas-dev/pandas#10815

In [1]: np.__version__
Out[1]: '1.11.0.dev0+59bbc06'

In [2]: np.nansum(np.array([np.nan]))
Out[2]: 0.0

In [3]: np.nansum(np.array([np.nan],dtype='object'))
Out[3]: nan

In [4]: np.nansum(np.array([np.timedelta64('nat')]))
Out[4]: numpy.timedelta64('NaT')

Summary 2019-05-03 by @seberg

The second example now actually returns 0 as well, since objects use arr != arr to guess if NaNs exist. Timedelta NaT are still not considered NaN for nanfuncs, which may still be up for discussion.
@charris
Copy link
Member

charris commented Aug 14, 2015

Maybe, although there are no nans in the last two examples. Nansum only looks for nans in floating types as those are the only types that have nans.

@njsmith
Copy link
Member

njsmith commented Aug 14, 2015

Yeah, I'm not sure what to make of the object dtype case either -- it's not
like python provides an isnan predicate for generic objects. (Though
OTOH I guess special casing float and numpy scalars wouldn't be that bad,
because it's such a restricted case -- if that's what the weirdos calling
nansum on object arrays want, then maybe there's no harm in giving it to
them ;-).) Handling NaT as a NaN seems like it'd be pretty uncontroversial,
though? NaT is pretty explicitly "this is NaN, but for times".
On Aug 14, 2015 12:46, "Charles Harris" [email protected] wrote:

Maybe, although there are no nans in the last two examples. Nansum only
looks for nans in floating types as those are the only types that have
nans.

—
Reply to this email directly or view it on GitHub
#6209 (comment).

@jreback
Copy link
Author

jreback commented Aug 14, 2015

just thinking for consistency, a bit unexpected for the function to do different things depending on the dtype

ideally I'd like to match you in pandas, so will special case this for now.

@jreback
Copy link
Author

jreback commented Aug 14, 2015

can you put a pointer to the original motivation for this change.

@seberg
Copy link
Member

seberg commented Aug 14, 2015

@jreback you mean the change that nansum will not return NaN? I think we decided it seemed more right when chuck did some cleanup of the NaN stuff, there is actually a FutureWarning in place for it in NumPy 1.8.
The motivation is that for np.nansum NaN is simply ignored, which leaves [], and the sum of that is well defined to be 0.

@jreback
Copy link
Author

jreback commented Aug 14, 2015

@seberg ok i c.

was their an original issue / discussion?

@seberg
Copy link
Member

seberg commented Aug 14, 2015

A bit hard to find, I think it can be traced back to this discussion (just a random mail from it, it is quite long): http://mail.scipy.org/pipermail/numpy-discussion/2013-July/067160.html

@kjordahl
Copy link
Contributor

Previous discussion on related issue: #1721.

@charris
Copy link
Member

charris commented Jan 6, 2016

@jreback Want to keep this open?

@jreback
Copy link
Author

jreback commented Jan 6, 2016

you guys had lots of discussion in #1721 about the behavior of nansum, so I won't reargue that (though I don't agree with the approach :)

but assuming that you like the behavior for floats. I certainly think this should be consistent across dtypes (that are summable), e.g. np.timedelta64. of course int64 doesn't have nans (and datetime64 doesn't make sense to sum). object I think should also be consistent, but I can understand its 'different'.

@eric-wieser eric-wieser mentioned this issue Apr 21, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug component: numpy.lib
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@seberg @charris @eric-wieser @kjordahl @njsmith @jreback