Hi,
On Wed, Oct 11, 2023 at 9:17 AM Peter Cock via NumPy-Discussion
wrote:
>
>
>
> On Tue, Oct 10, 2023 at 6:32 PM Matthew Brett wrote:
>>
>> Hi,
>>
>>
>> On Tue, 10 Oct 2023 at 00:55, Andrew Nelson wrote:
>> >
>> >
>> > On Mon, 9 Oct 2023 at 23:50, Matthew Brett wrote:
>> >>
>> >> Hi,
>> >>
>
On Tue, Oct 10, 2023 at 6:32 PM Matthew Brett
wrote:
> Hi,
>
>
> On Tue, 10 Oct 2023 at 00:55, Andrew Nelson wrote:
> >
> >
> > On Mon, 9 Oct 2023 at 23:50, Matthew Brett
> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson
> wrote:
> >> Could you say more about why y
Hi,
On Tue, 10 Oct 2023 at 00:55, Andrew Nelson wrote:
>
>
> On Mon, 9 Oct 2023 at 23:50, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson wrote:
>> Could you say more about why you consider:
>> np.mean(x, dropna=True)
>> to be less clear in intent than:
>> np
On Mon, 9 Oct 2023 at 23:50, Matthew Brett wrote:
> Hi,
>
> On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson wrote:
> Could you say more about why you consider:
> np.mean(x, dropna=True)
> to be less clear in intent than:
> np.nanmean(x)
> ? Is it just that someone could accidentally forget that t
Hi,
On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson wrote:
>
> On Mon, 9 Oct 2023 at 20:34, wrote:
>>
>> Surely you can do this for all functions of eg.nan*. Why separate them is
>> the only thing that distinguishes them. Setting the parameter seems to be
>> more handy and user-friendly. Well
Just to mention for visibility: Introducing a "nan" option and deprecating
nan* functions was considered for 2.0 main namespace refactor but it
was deemed large enough to be (hopefully) tackled in a separate
story/project.
https://github.com/numpy/numpy/issues/24306#issuecomment-1660073584 (first
On Mon, 9 Oct 2023 at 20:34, wrote:
> Surely you can do this for all functions of eg.nan*. Why separate them is
> the only thing that distinguishes them. Setting the parameter seems to be
> more handy and user-friendly. Well for me it's seems better to do it right
> away in NumPy 2.0
>
I think
Surely you can do this for all functions of eg.nan*. Why separate them is the
only thing that distinguishes them. Setting the parameter seems to be more
handy and user-friendly. Well for me it's seems better to do it right away in
NumPy 2.0
___
NumPy
Hi,
Is there any reason to have separate functions - or to keep enforcing
that?I agree, an equivalent of R's rm.na argument seems like a
very reasonable and useful addition, such as (sorry for the
obviousness):
np.mean(x, dropna=True)
and so on,
Cheers,
Matthew
On Mon, Oct 9, 2023 at 9:17
On Mon, 9 Oct 2023, at 7:07 PM, Andrew Nelson wrote:
> On Mon, 9 Oct 2023 at 16:36, Jerome Kieffer wrote:
> I'd be ambivalent on making this change. THere are a whole host of other
> `np.nan*` functions, would they all need to be modified as well? e.g.
> nanprod, nansum, nanargmin, ..
I th
On Mon, 9 Oct 2023 at 16:36, Jerome Kieffer wrote:
> On Fri, 06 Oct 2023 19:17:22 -
> norbertpiotraduc...@gmail.com wrote:
>
> > Hi,
> > I have an idea to change the numpy.percentile. Think numpy.percentile
> and numpy.nanpercentyl are the same features, and the only difference is
> that nump
On Fri, 06 Oct 2023 19:17:22 -
norbertpiotraduc...@gmail.com wrote:
> Hi,
> I have an idea to change the numpy.percentile. Think numpy.percentile and
> numpy.nanpercentyl are the same features, and the only difference is that
> numpy.nanpercentyl doesn't include NaN values. Wouldn't it be e
12 matches
Mail list logo
