Repository navigation
Conversation
|
WARNING: added symbol(s) collide with another series organ API (organ-first rule, .claude/rules/organ-first-implementation.md). Answer the 5 questions in the PR body, or declare the pedagogical copy (« copie pedagogique declaree, motif : ... ») which whitens it. See the workflow log for the full collision list (demanding series -> bypassed organ -> symbol). Advisory, NOT a merge gate. Detector: |
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
|
Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
|
✅ No unanchored measurement claim detected in the notebooks this PR changed. Scope = notebooks CHANGED in this PR, not the whole corpus. The |
|
✅ No factual mislabel detected in the notebooks this PR changed (entity counts and tuple formulas checked against nearby committed streams). Scope = notebooks CHANGED in this PR, not the whole corpus. The |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
Golden-Set Execution (H.7 P3)✅ 9/9 notebooks passed (certified reproducible)
Pinned lockfile: |
github-actions
Bot
added
the
large-pr-no-review
|
Cette PR depasse le seuil de couverture review (par defaut 300 additions) et n'a recu aucune review -- ni bot, ni humaine. Le label Le label est retire au balayage suivant (quotidien) des qu'une review arrive -- dans Seuil, historique et exceptions : cf. |
Path-collision (organ #13359/#13615)Cette PR #19285 (
|
|
[ADJOINT PREFLIGHT] |
3ce5c11 to
989dcd4
Compare
…yclage #19285, ancre PDF mesuree) (#19959) * fix(search,#19267): cost-partitioning kernel above PDB additives (Python + C#, See #4956) * fix(search,#19267): reexecute Python (papermill) + drop stale C# block + twin attestation Repare les rouges de #19959 : - exec-sequence DUPLICATE 9 (cellules 18/21) -> re-execution papermill end-to-end du carnet Python + import des outputs par index de cellule code ; - papermill STALE_BLOCK (C#) : le bloc decrivait un run du 2026-07-05 alors que les outputs venaient d'une execution .NET du 2026-10-05 (la CI ne peut pas papermill-exec le .NET, cf README) -> retrait du bloc stale ; - BLOCK_REMOVED (Python) : bloc papermill retire apres re-execution (le carnet ne portait pas de bloc sur main) ; - twin parity DRIFT "Search-12 Pattern Databases" -> attestation --update ; - note de parite honnete : RNG distinct (random.Random vs System.Random) -> l'instance de demo differe a graine egale, les valeurs absolues ne sont pas comparables entre jumeaux (seuls les invariants le sont). Gates locales : exec-sequence CLEAN, papermill 0 regression, exec-ratchet 0, output-failure 0, twin registry 50/50. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> * chore(twin-parity,#19959): attestation Search-12 alignee sur les blobs committes Le hook pre-commit (source-list-missing-newlines) a normalise la source des carnets apres ma premiere attestation : entree 0012 perimee (blob pre-hook), entree 0013 posee sur l'etat committe. Registre append-only, 0012 conservee. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> * fix(notebook,#19959): reserves Hermes -- duree recalibree sur la sortie + admissibilite du sature Deux reserves de la revue du 2026-10-08, traitees en texte, sorties intactes. R1 -- valeur citee absente des sorties committes (gate #17040). La cellule 22 citait « 972 772 nœuds, ~45 s » ; la sortie commitee de la cellule 21 dit 36,0 s. La prose suit la sortie. R2 -- nombre faux dans la justification d'admissibilite. La docstring `h_saturated` (Python cell 18) et le commentaire (C# cell 20) posaient bound=60 comme « au-dela du worst-case connu (~50) du 15-puzzle ». Le diametre du 15-puzzle est 80 coups (God's number), donc 60 est EN DESSOUS, et la preuve enoncee -- sum(bound/N_GROUPS) = bound >= optimal(state) -- est fausse pour tout etat d'optimum > 60. L'admissibilite tient, mais par une autre route : min(v, per_group) <= v terme a terme, donc h_saturated <= h_additive <= h*. C'est cette preuve-la qui est desormais ecrite dans les deux carnets. Observation (non bloquante) -- les cellules 19 (Python) / 21 (C#) annoncaient un « cas ou le sature gagne dans les sorties » qu'aucune sortie n'exhibe. La reformulation dit ce que le cap change et ce qu'il ne change pas ici (sur l'instance de demo, h_saturated et h_additive coincident -- 36 en Python, 28 en C#), sans y mettre une mesure qui ne serait pas la notre. Cells touchees : docstring et commentaires (aucune instruction modifiee) plus 3 cellules markdown. Sorties des cellules de code intactes (execution_count non nul partout, 23 cellules code Python / 14 C#). Lint 1/1 pass sur les deux, 0 violation C.1. Paire `Search-12 Pattern Databases` toujours [OK] en mode semantic : les 3 DRIFT restants sont sur d'autres paires et identiques sur main. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> * chore(twin-parity,#19959): re-attestation Search-12 sur la tete finale La jambe `Twin parity audit (#8057)` rougissait sur cette PR pour une paire en DRIFT : `Search-12 Pattern Databases`. Cause mesuree : l'attestation ecrite au commit `5901822e51` a ete suivie du commit `99f639a485` (« reserves Hermes -- duree recalibree sur la sortie + admissibilite du sature »), qui modifie les deux carnets. L'attestation decrivait donc des blobs anterieurs a la tete -- un document perime, pas un defaut de parite. Verification que la derive est bien imputable a cette PR, et non pre-existante : origin/main : 157 paires | OK=154 DRIFT=3 (Probas-3, Probas-5, Search-03) tete de la PR : 157 paires | OK=153 DRIFT=4 (+ Search-12) apres ce commit : 157 paires | OK=154 DRIFT=3 (= main, aux 3 memes paires) Les trois derives restantes sont anterieures a la PR et relevent d'une PR dediee (#8264) ; elles ne sont pas touchees ici. Aucun carnet n'est modifie par ce commit : seul le registre d'attestation gagne son entree. Les strips outilles (probeAddresses, chemins machine, papermill) ont donc bien tourne AVANT l'attestation -- l'ordre exige par #8957. See #19959 Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
This branch was successfully deployed
2 participants
Grain: DEEP/notebook-python — lane myia-po-2026:CoursIA-2 — prev: LIGHT/docs #19282
Nommage du partage de coûts (cost partitioning) au-dessus de Search-03b
Issue : #19267 — [Distillation] Heuristic Search (Edelkamp & Schroedl 2012) — nommer et généraliser le partage de coûts au-dessus de Search-03b.
Le grain livre deux volets sur les trois que le body décrivait.
Volet contenu (DEEP) — fait
1. Nommer le principe (markdown). Une nouvelle section 6b dans le carnet Python (et son pendant C#) pose le partage de coûts comme le noyau formel qui rend l'addition des sections 4 à 6 admissible. Définition, cas canonique (Korf & Felner 2002 sur la partition 4-4-4-3 = un partage disjoint), généralisation non triviale (partage saturé, Felner et al. 2004). Ancré dans Edelkamp & Schrödl 2012, chapitre 8 (Combining Heuristic Functions).
2. Démonstration bornée (code). Implémentation de
h_max(Culberson & Schaeffer 1996, baseline pessimale) eth_saturated(Felner, Korf, Hanan & Adelman 2004, partage saturé avecbound=60,per_group=15). Comparaison numérique sur l'instance de démo — résultat mesuré, cellule 18 du carnet Python :Cellule 20 du carnet C# (miroir) :
3. Ancrage du livre dans la référence. Le PDF archivé à
G:\Mon Drive\MyIA\IA\Bibliographie IA\Search\2012 - Heuristic.Search.Theory.and.Applications.pdfn'a pas pu être ouvert sur la machine worker (pypdf 6.16.2, EOF tronqué). L'ancrage chapitre/section est consistant avec la table des matières de l'édition mais l'ancrage page exact est flagé à vérifier quand le PDF sera lisible — c'est honnêtement consigné dans la cellule References, pas masqué.Prudence de mesure. La partition 4-4-4-3 du 15-puzzle est équilibrée (maxima 21, 17, 19, 16) : sur les états proches du but, les lectures PDB restent en-deçà du
per_group=15du partage saturé, donch_saturated ≈ h_additive. Le point pédagogique n'est pas le gain numérique (cf Prong B, grain DEEP) — c'est le geste formel : un partage de coûts peut être non trivial et rester admissible. L'écart deviendrait visible sur une partition plus profonde (6-6-3 avec maxima plus grands), point noté dans la section 6b comme perspective.Volet références (LIGHT) — fait
La section Livres de référence du
Search/README.mdreçoit l'entrée Edelkamp & Schrödl 2012. Pas d'autre modification du README (PR #19282 ajoute Boyd & Vandenberghe 2004, en attente de merge — les deux entrées cohabitent sans conflit après leur merge).Volet non livré et pourquoi
Parité Python / C# (#4956)
Les modifications sont portées dans les deux jumeaux Python et C# : trois cellules (markdown + code + lecture) + References mise à jour. Claim
paths:posté sur le ticket #19267 :Search/Part1-Foundations/Search-03b-PatternDatabases.ipynb,Search/Part1-Foundations/Search-03b-PatternDatabases-CSharp.ipynb,Search/README.md.Fichiers modifiés
MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases.ipynb: +3 cellules (6b kernel, code h_saturated, lecture), References cellule 51 étendue. Outputs capturés sur cellule 18.MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-CSharp.ipynb: +3 cellules miroir C#, References cellule 38 étendue. Outputs capturés sur cellule 20 (kernel .net-csharp).MyIA.AI.Notebooks/Search/README.md: +1 ligne Edelkamp & Schrödl 2012 dans la section Livres de référence.Validation réelle (H.1)
outputs[0].text).Notes pour le reviewer
h_saturated ≈ h_additiveest attendu sur la partition équilibrée 4-4-4-3 — c'est la limite pédagogique du grain. Le suivi naturel est : implémenter une partition 6-6-3 asymétrique (ou post-hoc LP) qui rendrait le gain visible. Tranche optionnelle mentionnée dans le body [Distillation] Heuristic Search (Edelkamp & Schroedl 2012) -- nommer et generaliser le partage de couts au-dessus de Search-03b #19267 — non livrée ici (périmètre DEEP tenu, mais Prong B « gain visible dans la sortie » pas démontré sur ce carnet — cf limite pédagogique reconnue).🤖 Generated with Claude Code