Wed Jun 3 09:05:58 CDT 2009
> On Wed, Jun 3, 2009 at 12:55 AM, Robert Kern <firstname.lastname@example.org> wrote:
>> On Tue, Jun 2, 2009 at 23:50, Pierre GM <email@example.com> wrote:
>>> On Jun 2, 2009, at 11:09 PM, firstname.lastname@example.org wrote:
>>>>> I tried to see if I can introduce a second version _check_asanyarray,
>>>> that doesn't convert to basic np.array, but I didn't get very far.
>>>> nanmedian, and nanstd are not easy to convert to work with matrices,
>>>> nanstd uses multiplication and nanmedian uses np.compress
>>> Well, what about that:
>>> * convert the inputs to ndarray w/ _chk_asarray
>>> * compute as usual
>>> * return a view of the result using the type of the input (using the
>>> type keyword of view)
>>> That should work w/ nanmedian. There might be some adjustment to make
>>> for nanstd (pb of dimensions?)
>> That is what I was suggesting, only in decorator form so it could be
>> applied everywhere. It's not worth wasting time making a small handful
>> of functions work and be inconsistent with all of the others.
> If someone gives me this decorator, I will use it, but I don't know
> how to write a decorator that works for all input and output cases,
> and doesn't screw up our documentation system.
> But I can change 2 lines per function, and I know I still have the
> same signature and docstring. It looks like it will work for all
> descriptive statistics and data transformation in scipy.stats. It
> won't be relevant for most of the remainder.
> Scipy-dev mailing list
Using stats._chk_asarray should be completely unnecessary because most
of numpy functions accept array-like inputs and use flattened arrays by
default unless the axis keyword is used. That is why I did not use it
for the stats.gmean and stats.hmean patches.
I am also curious why the nanmean is so involved when I would think
that, for some array b and axis, you can just do:
Granted nanstd is more complex and, in both cases, these probably should
be part of numpy.
More information about the Scipy-dev