Numpy: BUG: la promotion timedelta et float fonctionne parfois

On dirait qu'au moins np.multiply prend en charge cela.

import numpy as np
print(np.multiply(np.timedelta64(1), 1.2))

Je pense que ce qui précède devrait également être considéré comme un bogue.

Je pense que la question est qu'il est toujours vrai que pour les ufuncs "les règles de conversion sont implémentées par la question de savoir quand un type de données peut être converti" en toute sécurité "vers un autre type de données" comme décrit dans la documentation. On dirait qu'il y a des exceptions comme ci-dessus où le casting n'est pas sûr mais nous avons fait fonctionner l'ufunc. Je suppose que dans ce cas, les modify_types devraient toujours indiquer la promotion de type invalide (pour les deux np.promote_types ("float32", "m8") et np.promote_types ("m8", "float32")). La question de savoir si nous devons continuer à permettre à ufunc de fonctionner peut être décidée au cas par cas?

Oui, nous devons clairement distinguer que np.promote_types doit être une règle générique qui est toujours raisonnable. C'est pourquoi j'aime le terme "dtype commun". C'est par exemple le dtype qui peut être utilisé avec np.concatenate .

Chaque ufunc individuellement peut décider d'implémenter une opération spécifique en utilisant le "dtype commun" ou une autre logique. Nous le faisons spécifiquement pour plusieurs et timedelta64, c'est donc un problème distinct.

Je suppose que nous n'utilisons pas réellement cette logique dans de nombreux endroits, car les ufuncs reposent principalement sur np.can_cast(..., ...) comme vous le notez. Et bien que cela soit généralement aligné sur la promotion de type, ce n'est pas ici.

Compte tenu de la discussion ci-dessus, je suis allé de l'avant et j'ai ajouté le correctif pour modify_types.