Salut Gabriel, je vais essayer ça ce week-end

Avoir ceci lié quelque part serait bien, mais je pense que c'est trop de niche pour être inclus dans numpy. nous ne voulons que des versions nan* des fonctions les plus couramment utilisées, et ptp n'en fait pas partie.

En regardant les fonctions nan* existantes, il semble que la plupart des fonctions de base aient des analogues nan. Je suis d'accord que ptp n'est pas la fonction la plus couramment utilisée, mais je l'utilise pas mal sur des problèmes de traitement du signal, et j'ai l'impression qu'elle manque compte tenu des autres fonctions de nanfunctions.py . J'ai fini d'implémenter une version de base, je la récupérerai sur mon compte une fois qu'elle sera nettoyée et testée.

Si nous décidons d'aller de l'avant avec celui-ci, je viens d'ouvrir un PR avec l'implémentation de la fonction et les tests correspondants.

13220

Nous en avons discuté lors de la réunion de triage. La plupart des gens étaient contents de rejeter cette demande de fonctionnalité. @charris s'est abstenu, @seberg a dit qu'il pouvait imaginer un espace de noms séparé.

La raison principale ici est que nous ne voulons pas plus de fonctions nan en général ; nous avons les plus couramment utilisés, et remplir l'espace de noms principal avec plus de fonctions nan n'est pas justifié (il y a un coût important pour ajouter quoi que ce soit à l'espace de noms à ce stade.

En particulier pour celui-ci : ptp est déjà une niche, et c'était sans doute une erreur d'ajouter à numpy. Donc nanptp n'est pas souhaité.

Un package séparé comme bottleneck est plus logique pour plus de fonctions nan.

Merci d'avoir suggéré ce @Gabriel-p, et pour le PR @yliapis

Merci pour l'explication détaillée @rgommers