Repository navigation
docs(ict): la fiche README d'ICT-40 annonce « numpy-only » alors que le module importe scipy #16687
Description
Activity
FALSE POSITIVE — je ferme cette issue que j'ai ouverte il y a une heure
J'ai ouvert #16687 en reprenant la lecture d'Hermes sans la tester. L'audit que l'issue elle-même réclamait (règle E : auditer le fichier entier, pas la ligne citée) infirme sa prémisse.
Ce que « numpy-only » veut dire dans ce README
Les cinq occurrences de la mention sont toutes appariées à un marqueur de substrat de calcul :
Ligne Fiche Texte apparié 222 ICT-22b « Cœur numpy ict/causal_engine.py… confinement torch dansscripts/causal_hooks.py»225 ICT-SAE-JLens-TeteATete « banc numpy-only … (GPU-free, Track S) » 227 ICT-21c « banc numpy-only … (GPU-free, traces committées) » 230 ICT-36 « (grain autonome, CPU uniquement, primitives numpy-only) » 241 ICT-40 « (grain autonome, CPU uniquement, numpy-only) » L'idiome oppose numpy sur CPU à torch sur GPU. Il ne dit pas « numpy est la seule dépendance ».
La mesure qui tranche
$ git grep -l 'import torch' origin/main -- MyIA.AI.Notebooks/IIT/ICT-Series ICT-17b-Grokking-CompressionProgress.ipynb ICT-21-SAETrajectoires.ipynb ICT-22b-CausalInterventionEngine.ipynb ICT-25-InoculationRL.ipynb ICT-38-SLens-SelfLocation.ipynb ICT-40-TriangulationCausale.ipynb ict/jlens_traces.py · ict/jlens_trackP_traces.py ict/lens_agreement.py · ict/sae_calibration.pytorchapparaît dans 6 notebooks et 4 modules — et dans aucun des quatre annotés « numpy-only ». L'annotation partitionne la série exactement sur la ligne torch / pas-torch. Elle est exacte sur les quatre, ICT-40 compris.Contrôle indépendant qui va dans le même sens : deux des notebooks annotés « numpy-only » importent
matplotlib, et l'un d'euxpandas, sans que personne n'y ait jamais vu une contradiction. Si la mention était une clause de dépendance stricte, elle serait fausse depuis longtemps sur des fiches que de nombreuses revues ont traversées.Ce qui reste, et qui ne justifie pas une issue
Hermes a lu « numpy-only » comme une clause de dépendance. Hermes est un lecteur attentif, et il s'est appuyé sur un fait exact (
analog_waves.pyimporte bienscipy.ndimageetscipy.signal). Que sa lecture soit possible dit que la mention est ambiguë hors contexte — pas qu'elle est fausse. Or elle n'est jamais hors contexte : elle est systématiquement collée à « GPU-free » ou « CPU uniquement » sur la même ligne.Corriger les quatre lignes pour y ajouter scipy/matplotlib/pandas aurait remplacé une annotation exacte et informative (ce notebook ne demande pas de GPU) par une liste de dépendances déjà portée par
requirements.txt(l.31 du même README, qui liste scipy). C'est-à-dire : dégrader le README pour satisfaire une lecture que le README ne réclame pas.Conséquence sur #16617
J'ai écrit dans mon commentaire de levée que « la remarque était donc juste » et que « la fiche le dit ». C'est faux, et je le corrige sur la PR. La levée par issue nommée reste valide au sens de B.0 — l'issue existait avant le merge — mais son contenu ne tenait pas, et une levée qui s'appuie sur un fait faux n'est pas une levée, c'est un report.
Ce que je retiens pour moi : j'ai appliqué le protocole de vérification à la réserve d'Hermes sur #16681 (où j'ai re-dérivé moi-même le corollaire qu'il déclarait non vérifié) et je ne l'ai pas appliqué à la sienne ici. J'ai ouvert une issue sur la parole d'un bot. C'est exactement la classe d'erreur que la règle de réévaluation d'audit existe pour empêcher — ~60 % de faux positifs sur les findings automatisés, et celui-ci en était un.
Fermée comme FALSE POSITIVE. Aucune PR ne doit en sortir.
Le défaut
La fiche README de
ICT-40-AnalogCognitionWavesannonce*(grain autonome, CPU uniquement, **numpy-only**)*(MyIA.AI.Notebooks/IIT/ICT-Series/README.md, l.241 au head de #16617).Le module sur lequel le notebook s'appuie importe scipy :
Les cellules du notebook sont bien numpy-only — c'est ce qui rend la mention plausible à la relecture — mais elles appellent
ict/analog_waves.py, donc scipy est requis à l'exécution. Un lecteur qui prend la fiche au mot et n'installe que numpy obtient unModuleNotFoundError, sans que rien ne lui indique pourquoi.Pourquoi ça compte ici plus qu'ailleurs
requirements.txtliste bien scipy (l.31 du même README), donc l'installation nominale fonctionne. Le défaut ne mord que sur le lecteur qui se fie à l'annotation pour installer au minimum — c'est-à-dire précisément le lecteur externe qui explore la série sans vouloir tout installer. La série en reçoit en ce moment.Origine
Remarque d'Hermes sur #16617, explicitement posée comme mineure et non bloquante : «
hilbertvient descipy.signal— le body annonce "numpy-only" pour le notebook, vrai pour les cellules, mais le module importe scipy. […] juste à garder en tête pour la fiche README si elle dit "numpy uniquement". » La fiche le dit.Cette issue est ouverte avant le merge de #16617 pour porter cette remarque, conformément à B.0 : une remarque se lève par une réponse écrite, un thread résolu, ou une issue de suivi nommée avant le merge. C'est la troisième voie. La branche de #16617 n'est pas touchée : sa lane a demandé de ne pas relancer sa CI sur une PR mûre.
Ce qui ferme cette issue
Corriger l'annotation l.241 pour qu'elle dise ce que le code fait. Ne pas retirer scipy du module pour sauver l'annotation :
hilbertetgaussian_filtersont les bons outils, les réimplémenter en numpy serait un workaround dégradé.Balayage dû dans le même geste (règle E, audit du fichier entier plutôt que la seule ligne citée) : les autres fiches de ce README portant
numpy-onlydoivent être confrontées aux imports réels de leur module. Au moinsICT-SAE-JLens-TeteATete(l.225),ICT-21c-SAECatastrophes(l.227) etICT-36-FLens-FactoredGeometry(l.230) portent la mention — non vérifiées à ce stade, et c'est le point : corriger la seule ligne 241 en laissant les autres non mesurées reproduirait le défaut que la règle E nomme.