2019-02-28 Sprint scikit-learn
J'ai vécu mon premier sprint scikit-learn. J'avais posté au préalable une issue Faster PolynomialFeatures à laquelle j'ai proposé une solution Fixes #13173, implements faster polynomial features for dense matrices. Je recommande l'aventure à tous ceux qui souhaitent comprendre comment on construit une librairie de machine learning qui plaise au plus grande nombre. J'y ai croisé des chercheurs venus de tous horizons, des contributeurs de scikit-learn, venus pour réfléchir sur les prochains grands défis de la librairie que je résumérais par : Comment répondre à de nouveaux usages tout en conservant la simplicité du design actuel ?.
Un des sujets abordés était la possibilité de nommer les variables (ou features) tout au long d'un pipeline. Aujourd'hui, un modèle de scikit-learn accepte une entrée (une matrice) et retourne une matrice numpy. On peut représenter un pipeline en image comme ceci Column Transformer with Mixed Types. La sémantique actuelle de scikit--learn ne permet pas de tout représenter dans un pipeline unique. C'est pourtant souhaitable car plus lisible et plus facile à maintenir. Il n'existe pas une solution unique pour ce problème et prend part à cette réflexion est enrichissant.
scikit-learn a évolué pour gérer les multiples contributions et cela a abouti à un ensemble de pratiques qui permettent de gérer ce traffic sans diminuer la fiabilité de la librairie. Je vous encourage à lire quelques pull request qui illustrent ce dialogue permanent. Ma pull request n'a pas encore été acceptée, il est possible qu'elle soit rejetée. Elle propose un gain de performance sur un algorithme pas aussi populaire que d'autres tout en accroissant la complexité du code. J'ai passé quelques heures à exécuter des benchmarks pour comparer les différentes implémentations : Benchmark - PR13290 - Faster Polynomial Feature.
Cette pull request me renvoie également à la façon dont je gère les revues de code sur les projets dont je suis un des auteurs. Je ne prête pas beaucoup d'attention au style. J'écris souvent for n in range... mais on préfère parfois for n_obs in range.... Je lis tellement de code d'étudiants que je me rends compte que le style m'importe peu. Il ne me gêne pas dans la compréhension. Je fais surtout attention à l'efficacité de ce qui est écrit. Je fais donc rarement de commentaires sur le styles et beaucoup plus sur l'algo. Le design et donc un peu le style est pourtant ce qui a fait le succès de la librairie scikit-learn. Mes premières revues de code datent de 2007 époque où je rejoignais Yahoo. J'avoue qu'elles furent difficiles car moi qui avait toujours codé un peu seul ou entouré de codeurs qui se souciaient peu du style, lire les commentaires sur les espaces en trop me laissaient complètement dubitatif voire intrusif. Je ne m'étais jamais soucié du style avant, un espace devant une parenthèse était aussi invisible que la neige à Bordeaux. Le code marchait, je ne voyais que cela. Heureusement qu'il y a des outils pour corriger le style sinon je ne coderais plus. Imaginez qu'un prof passe l'essentiel du temps à commenter les fautes d'orthographes sans parler du contenu. Non pas que je ne sois pas capable d'apprendre un style mais plutôt que pour des autodidactes en programmation comme moi, le style parfait n'existe pas. J'ai vu de nombreux élèves se repérer dans des milliers de ligne bien à eux avec une aisance incroyable. Certains développeurs refusent de lire le code d'un autre s'il ne respecte pas un certain style. Je sais que je ne peux pas bosser avec eux. Ils me rendent fous. C'est aussi un moyen de me ralentir, il m'est arrivé d'écrire quelques milliers de lignes de code par semaine. Les relire prend du temps. Je ne sais pas pourquoi je vous raconte tout ça. Chaque projet open source a sa propre culture. Sur scikit-Learn, le style est géré automatiquement sur un test unitaire. Il impose pep8. Pour les curieux, il ne gère que les modifications et pas l'ensemble du code qui ne suit pas le même style partout. Les discussions ont donc trait au contenu, sur l'efficacité et la meilleure façon d'exprimer une idée abstraite. Les décisions sont prises de façons démocratiques et prennent en compte l'intérêt ou la difficulté pour tous les utilisateurs y compris ceux qui font leurs premiers pas en python.
Je vous laisse. J'ai une idée pour les arbres de décision.
| <-- --> |
Xavier Dupré
|
