Hi Charles,
Just providing an outsider's perspective...
Your specific use-case doesn't address the general definition of nansum:
perform a sum while ignoring nans. As others have pointed out, (especially in
the linked thread) the sum of nothing is 0. Although the current behaviour of
nansu
I saw this thread and I totally disagree with thouis argument…
Of course, you can have NaN if there are only NaNs. Thanks goodness, There is a
lot of way to do that.
But it’s not convenient, consistent and above all, it is wrong logically to do
that. NaN does not mean zeros and operation with Na
Hi Charles,
You should read the previous discussion about this issue on GitHub:
https://github.com/numpy/numpy/issues/1721
For what it's worth, I do think the new definition of nansum is more
consistent.
If you want to preserve NaN if there are no non-NaN values, you can often
calculate this des
Why do we keep this behaviour ? :
np.nansum([np.nan]) # zero
Firstly, you lose information.
You can easily fill nan with zero after applying nansum but you cannot keep nan
for nan-full rows if you doesn’t have a mask or keep the information about
nan-full row before.
It is not convenient, usef
Grabbing the pandas csv reader would be great, and I hope it happens sooner
than later, though alas, I haven't the spare cycles for it either.
In the meantime though, can we put a deprecation Warning in when using
fromstring() on text files? It's really pretty broken.
-Chris
On Oct 23, 2015, at
> On Oct 23, 2015, at 6:49 PM, Nathaniel Smith wrote:
>
> On Oct 23, 2015 3:30 PM, "Jeff Reback" wrote:
> >
> > On Oct 23, 2015, at 6:13 PM, Charles R Harris
> > wrote:
> >
> >>
> >>
> >> On Thu, Oct 22, 2015 at 5:47 PM, Chris Barker - NOAA Federal
> >> wrote:
> >>>
> >>>
> I think it
On Oct 23, 2015 3:30 PM, "Jeff Reback" wrote:
>
> On Oct 23, 2015, at 6:13 PM, Charles R Harris
wrote:
>
>>
>>
>> On Thu, Oct 22, 2015 at 5:47 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
>>>
>>>
I think it would be good to keep the usage to read binary data at
least.
>>>
> On Oct 23, 2015, at 6:13 PM, Charles R Harris
> wrote:
>
>
>
>> On Thu, Oct 22, 2015 at 5:47 PM, Chris Barker - NOAA Federal
>> wrote:
>>
>>> I think it would be good to keep the usage to read binary data at least.
>>
>> Agreed -- it's only the text file reading I'm proposing to depre
On Thu, Oct 22, 2015 at 5:47 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
>
> I think it would be good to keep the usage to read binary data at least.
>
>
> Agreed -- it's only the text file reading I'm proposing to deprecate. It
> was kind of weird to cram it in there in the fi
The change to nansum() happened several years ago. The main thrust of it
was to make the following consistent:
np.sum([]) # zero
np.nansum([np.nan]) # zero
np.sum([1]) # one
np.nansum([np.nan, 1]) # one
If you want to propagate masks and such, use masked arrays.
Ben Root
On Fri, Oct 23, 201
On Fri, Oct 23, 2015 at 5:45 PM, Charles Rilhac
wrote:
>
> Hello,
>
> I noticed the change regarding nan function and especially nansum
function. I think this choice is a big mistake. I know that Matlab and R
have made this choice but it is illogical and counterintuitive.
What change are you refe
Hello,
I noticed the change regarding nan function and especially nansum function. I
think this choice is a big mistake. I know that Matlab and R have made this
choice but it is illogical and counterintuitive.
First argument is about logic. An arithmetic operation between Nothing and
Nothing c
12 matches
Mail list logo
