[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