Numpy: np.copy (matriz enmascarada) tiene un comportamiento inesperado

Todavía abierto en 1.9-devel

Sin embargo, no estoy seguro de cómo solucionar este problema sin matrices enmascaradas de carcasa especial.

¿Cambiar la lógica de np.copy para incluir subok=True en la llamada a la matriz solucionaría este problema?
Desde:

return array(a, order=order, copy=True)

A:

return array(a, order=order, subok=True, copy=True)

Si es así, ¿subok debería ser un parámetro para np.copy y cuál debería ser el valor predeterminado, Verdadero o Falso? True devolverá el primer resultado preferido, False mantendrá el comportamiento actual, pero permitirá el comportamiento esperado pero agregando un argumento.

No estoy a favor de agregar un parámetro subok a np.copy cuando ya tenemos dos soluciones completamente viables:

• use el método .copy()
• use np.array(a, subok=True) (copia por defecto)

En realidad, yo diría lo contrario, ya que creo que la mayoría de las "copias" dan la impresión de que uno obtendría algo a cambio que es, en realidad, una copia y, por lo tanto, del mismo tipo. También lo veo como una contribución pequeña pero útil para hacer que el conjunto de numpy sea más capaz de lidiar con las subclases de manera más consistente (tal como lo hice antes con np.broadcast_arrays , donde no había un buen sustituto disponible). Sin embargo, dada la necesidad de seguir siendo compatible con versiones anteriores, creo que estamos atascados con un valor predeterminado de subok=False .

De todos modos, @jjhelmus , ¿por qué no hacer un PR rápido y ver lo que piensan los demás?

@shoyer : np.copy probablemente debería estar en su lista de funciones que necesitan
algún tipo de soporte de matriz de pato, sin embargo, para una matriz de pato, creo que np.copy
y np.array probablemente debería hacer cosas diferentes. Tal vez debería simplemente llamar
arr.copia?

El jueves 15 de octubre de 2015 a las 7:00 a. M., Marten van Kerkwijk <
[email protected]> escribió:

De hecho, diría lo contrario, ya que creo que para la mayoría de "copiar"
la impresión de que uno obtendría algo a cambio que es, en realidad, una copia,
y por tanto del mismo tipo. También lo veo como una contribución pequeña pero útil
para hacer que el conjunto de numpy sea más consistente para lidiar con subclases
(tal como hice antes con np.broadcast_arrays, donde no hay un buen sustituto
estaba disponible). Sin embargo, dada la necesidad de seguir siendo compatible con versiones anteriores,
creo que estamos atrapados con un valor predeterminado de subok = False.

De todos modos, @jjhelmus https://github.com/jjhelmus , ¿por qué no hacer un PR rápido?
y ver lo que otros piensan?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/3474#issuecomment -148395201.

Nathaniel J. Smith: http://vorpus.org

Sí, haría +1 en hacer que np.copy intente llamar al método de copia en matrices de pato.

Todavía no hay razón para no admitir subok también. Y, por supuesto, uno puede simplemente llamar __copy__ si existe.

Creado PR # 6509 que agrega un parámetro subok a la función con un valor predeterminado de Falso . Supongo que esto abrirá una discusión sobre el tema. No estoy seguro de si esto suele ocurrir en el RP, el problema o la lista de correo.

La discusión de API debe estar en la lista de correo.
El 18 de octubre de 2015 a las 7:37 p.m., "Jonathan J. Helmus" [email protected]
escribió:

Creado PR # 6509 https://github.com/numpy/numpy/pull/6509 que agrega un
_subok_ parámetro a la función con un valor predeterminado de _False_. soy
adivinar esto abrirá alguna discusión sobre el tema. No estoy seguro si esto
normalmente tiene lugar en las relaciones públicas, el problema o la lista de correo.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/3474#issuecomment -149080511.

Mañana enviaré un correo electrónico a la lista sobre el tema.