Repository navigation
ICT-24 Gate 24 : le tirage du generateur utilise hash(s) (non reproductible) -- frere non corrige de #19222 #19967
Description
Activity
- added a commit that references this issue
on Oct 8, 2026 Grain: DEEP/notebook-python — lane myia-po-2026:CoursIA-2 — prev: MED/notebook-lean #19891
[CLAIMED] lane myia-po-2026:CoursIA-2 —
hash(s)→ amorce stable (indice dans SETS), alignement sur la forme de Gate 23 déjà corrigée par #19222, puis re-exécution du carnet et vérification de reproductibilité sur deux tirages.paths: MyIA.AI.Notebooks/**/ICT-24-WorkspaceIgnition-Python.ipynb
Livré — PR #19991, tête
b207f77176Les trois gestes de l'issue
geste état 1. hash(s)→SETS.index(s)dans la cellule de mesure du Gate 24fait — 1 ligne, plus le commentaire qui la documente dans la forme exacte du Gate 23 2. ré-exécuter le carnet (le correctif change les nombres publiés) fait — SUCCESSen 535 s, carnet committé avec ses sorties (24 cellules, 9 de code,execution_count1→9)3. vérifier qu'aucune autre cellule n'a gardé la même amorce fait — hash(ne subsiste que dans les deux commentaires (Gate 23 l.14, Gate 24 l.30), jamais en code exécutableLa reproductibilité n'est pas affirmée, elle est falsifiée
Deux processus distincts rejouent l'appareil dans chaque forme :
forme processus 1 processus 2 après ( SETS.index)intact −0.353595,ws_clamp −0.049194identiques avant ( hash(s))intact +0.175031, amorces[2939903590, …]intact +0.041427, amorces[1518751022, …]Sans le correctif, deux exécutions du même carnet ne publient pas les mêmes chiffres — la mesure le montre, elle ne l'infère pas.
Les nombres publiés changent, comme la réserve de #19968 l'annonçait
Panneau fixe, à la tête committée :
intact−0,4578 (7 crédités sur 36),ws_clamp−0,0871 (13 sur 74),rp_clampidentique àintact. Les valeurs d'avant étaient−0,4195 / 4et−0,5296 / 14.La lecture n'est pas touchée (et l'issue est explicite : ce n'est pas son objet) — clamper le workspace continue de ne pas effondrer les gains crédités, et le contrôle apparié reste inerte. Les six chiffres frais et le détail des remplacements sont postés sur #19968, dont la lecture numérique les publie : c'est là qu'ils doivent atterrir, pas ici.
Reste ouvert, et à qui
Le point 2 demande aussi de ré-aligner « la prose du Gate 24 et la lecture associée » sur les sorties fraîches. Cette prose n'existe pas sur
main— elle est introduite par #19968, ouverte. La ré-aligner dans #19991 voudrait dire écrire une seconde cellule de lecture en double d'une PR en vol. J'ai donc fourni les chiffres à son auteur plutôt que de dupliquer son travail ; l'ordre recommandé (#19991, puis #19968 rebasée) est exposé dans les deux PR.C'est pourquoi #19991 écrit
See #19967et non une formule de clôture.- added a commit that references this issue
on Oct 8, 2026
Part of #5635. Découvert en alignant le statut épistémique d'
ICT-24-WorkspaceIgnition-Python.ipynbsur le Gate 24 exécuté (phase 2).Le défaut
La fonction de mesure du Gate 24 (cellule 15 de
ICT-24-WorkspaceIgnition-Python.ipynb) amorce son générateur parhash(s):En Python 3,
hash()d'une chaîne est salé par processus (PYTHONHASHSEED). Le tirage des permutations change donc à chaque exécution : les chiffres publiés par le Gate 24 (contraste moyen,#events,#credites,#etats) ne sont pas reproductibles d'un run à l'autre.Ce qui le rend anormal plutôt que cosmétique
C'est exactement le défaut qui a été retiré du Gate 23 dans #19222, et le carnet porte les deux formes côte à côte :
rng = np.random.default_rng((seed_base + SETS.index(s)) % (2**32))— avec le commentaire « #19222 : la graine par jeu est l'indice dans SETS (stable), pas hash(s) (sale par processus) »rng = np.random.default_rng((seed_base + hash(s)) % (2**32))— non corrigéLe Gate 24 a été écrit après le correctif du Gate 23 sans en hériter la leçon. La cellule voisine documente donc le bon geste et la cellule de mesure ne l'applique pas.
Impact mesuré
Les quatre chiffres du tableau du Gate 24 (
intact −0,4195 / 36 / 4 / 200,ws_clamp −0,5296 / 74 / 14 / 77,rp_clampidentique àintact) sont ceux d'une exécution committée. La lecture qu'ils portent (pas d'effondrement sélectif → branche24KO) est robuste : elle repose sur l'écartws_clampvsintact, qui est un effet de panneau, pas de tirage. Mais un lecteur qui re-exécute le carnet ne retrouvera pas ces nombres, et un futur ajustement den_shuffles(#19335) ou dewindowse mesurerait contre une base non stable.Geste attendu
hash(s)parSETS.index(s)dans la cellule de mesure du Gate 24 — le correctif canonique déjà appliqué au Gate 23.grepsurhash(s)).Le point 2 est ce qui justifie une passe dédiée plutôt qu'un correctif glissé dans une PR de documentation : il change des sorties publiées, et exige une ré-exécution complète.
Non-objectif
Ne pas toucher au verdict du Gate 24. Ce ticket ne dit pas que la mesure est fausse — il dit que son tirage n'est pas stable, ce que la lecture publiée doit déclarer.