[SciPy-dev] scipy.stats._chk_asarray
josef.pktd at gmail.com
josef.pktd at gmail.com
Wed Jun 3 09:40:38 EDT 2009
On Wed, Jun 3, 2009 at 2:17 AM, Pierre GM <pgmdevlist at gmail.com> wrote:
>
> On Jun 3, 2009, at 1:09 AM, josef.pktd at gmail.com wrote:
>>
>> Given my experience with views, I would prefer to limit them to very
>> local usage, e.g. views on transposed arrays don't work,
>
> ??
> >>> m = np.matrix([1,2,3])
> >>> m.T
> matrix([[1],
> [2],
> [3]])
> >>> m.T.view(np.ndarray)
> array([[1],
> [2],
> [3]])
>
> What case did you have in mind ?
there was a thread started by Pauli that inplace operations work on
the base and not the view.
I fell over this case and similar cases:
>>> np.ones((5,3)).T.view([('',float)]*3)
array([[(1.0, 1.0, 1.0), (1.0, 1.0, 1.0), (1.0, 1.0, 1.0), (1.0, 1.0, 1.0),
(1.0, 1.0, 1.0)]],
dtype=[('f0', '<f8'), ('f1', '<f8'), ('f2', '<f8')])
>>>
>>> np.ones((5,3)).T.view([('',float)]*5)
Traceback (most recent call last):
ValueError: new type not compatible with array.
>>> np.ones((5,3)).T
array([[ 1., 1., 1., 1., 1.],
[ 1., 1., 1., 1., 1.],
[ 1., 1., 1., 1., 1.]])
So until I figure out what can safely be done with views, I avoid time
if possible.
>
>>>> And what is the best way to check whether an array is a plain
>>>> ndarray
>>>> and not a subclass instance?
>>>
>>> Er, why do you want to do that ?
>>
>> To get fast track for users that deliver already directly usable data,
>> without special type handling. This will be more relevant for
>> stats.models to handle recarrays and masked arrays, and ?
>
> Mmh. We'll see.
>
>>
>> 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.
>
> Try that.
>
> def keepthetype(func):
> def wrapped(*args, **kwargs):
> first = args[0]
> if isinstance(first, np.ndarray):
> output_type = type(first)
> else:
> output_type = np.ndarray
> output = func(*args, **kwargs)
> if isinstance(output, np.ndarray):
> return output.view(output_type)
> return output
> wrapped.__name__ = func.__name__
> wrapped.__dict__ = func.__dict__
> wrapped.__doc__ = func.__doc__
> return wrapped
>
Is there a reason that you prefer view(output_type)
to __array_wrap__
which from the help and reading the numpy source seems to be the
"standard" approach?
Some function have multiple data input (e.g. f_oneway), some functions
have tuple output where some or all tuple elements need to be wrapped
(e.g. np.linalg.svd or stats.describe)
So, a general decorator looks quite complicated, especially if we want
to preserve autocomplete (Paulis comment) and not special case all
different kinds of inputs and outputs, and might need to contain a lot
of magic.
Josef
More information about the SciPy-Dev
mailing list