Docs(search,#19297): Search-03b -- blocs de fin canoniques (paire Python + C#)

MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases-CSharp.ipynb

@@ -895,7 +895,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "id": "e5944832",
    "metadata": {},
@@ -948,7 +947,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "code",
    "execution_count": 9,
    "id": "a268f847",
@@ -1034,7 +1032,6 @@
    ]
   },
   {
-   "attachments": {},
    "cell_type": "markdown",
    "id": "94251810",
    "metadata": {},
@@ -1679,6 +1676,56 @@
     "\n",
     "| 🐍 [Version Python](Search-03b-PatternDatabases.ipynb)"
    ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "finition-03b-csharp-a-retenir",
+   "metadata": {},
+   "source": [
+    "## À retenir\n",
+    "\n",
+    "1. **Une PDB échange du calcul contre une table** : 524 160 entrées pour un groupe de 4 tuiles (P(16,4) = 43 680 motifs × 12 positions de la case vide), construites en 2,4 s ; 43 680 pour le groupe de 3. La table n'est pas une estimation : c'est l'optimum d'un problème plus facile, calculé une fois.\n",
+    "2. **L'admissibilité vient du relâchement, la somme de la partition de coûts** : chaque coup ne déplace qu'une tuile, donc ne coûte que dans une seule table — HAdditive = somme des quatre tables reste une borne inférieure, et HMax = 11 ≤ HAdditive = 28 sur l'instance de démonstration.\n",
+    "3. **La PDB additive repousse la frontière du résolvable** : sur I1 (opt 24) elle explore 732 nœuds contre 2 114 pour Manhattan (×2,9) ; sur I2 (opt 45) et I3 (opt 53), Manhattan dépasse 2 M de nœuds sans conclure quand la PDB additive résout à l'optimum (299 773 et 392 168 nœuds).\n",
+    "4. **« speedup NaN » est une réponse, pas un bug** : le facteur n'existe que si les deux heuristiques terminent ; quand Manhattan est hors budget, la comparaison se lit en « résolu / non résolu », pas en rapport de nœuds.\n",
+    "5. **La mécanique ne dépend pas du langage** : tables `byte[]`, encodage de rang injectif (19 975 états abstraits testés, 0 collision), construction des quatre tables en 5,1 s — la même structure qu'en Python, à la vitesse près."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "finition-03b-csharp-verifiez",
+   "metadata": {},
+   "source": [
+    "## Vérifiez votre compréhension\n",
+    "\n",
+    "1. Une table de groupe de 4 tuiles compte 524 160 entrées alors que P(16,4) vaut 43 680. D'où vient le facteur 12, et pourquoi la case vide doit-elle figurer dans l'état abstrait ?\n",
+    "2. Pourquoi HAdditive = somme des quatre tables reste-t-il admissible, alors qu'aucune table ne connaît la position des autres groupes ?\n",
+    "3. Sur I2 et I3, le tableau affiche « speedup NaN ». Que faut-il lire à la place du facteur, et pourquoi le carnet refuse-t-il d'inventer un nombre ?\n",
+    "4. L'encodage de rang est testé sur 19 975 états abstraits avec 0 collision. Quel défaut produirait une collision sur la table, et pourquoi le test est-il placé à la construction plutôt qu'à l'usage ?\n",
+    "\n",
+    "<details><summary>Réponses</summary>\n",
+    "\n",
+    "1. Un motif de 4 tuiles admet P(16,4) = 43 680 placements ; les coups applicables dépendent de la case vide, donc l'état abstrait est (placement du motif, case vide parmi les douze cases restantes) : × 12 = 524 160 — la cellule de lecture du carnet écrit exactement « 524 160 = P(16,4) × 12 ». Sans elle, le parcours rétrograde ne saurait pas quels mouvements existent.\n",
+    "2. Chaque coup déplace exactement une tuile, donc appartient à un seul groupe : le coût total se partage sans recouvrement entre les tables, chacune minore sa part, donc la somme minore le total — c'est la version C# du partage de coûts (section 6b), qui rend HMax ≤ HAdditive toujours vrai (la vérification des sorties rend `True`).\n",
+    "3. On lit « non résolu dans le budget » contre « résolu à l'optimum » : NaN signale que le dénominateur manque — Manhattan n'a pas conclu —, pas une mesure nulle ni une erreur. Inventer un facteur sur une heuristique qui n'a pas terminé serait un chiffre fabriqué ; le carnet préfère une case vide à un nombre faux.\n",
+    "4. Une collision ferait correspondre deux états abstraits distincts à la même entrée : l'un des deux lirait la distance de l'autre, et l'heuristique pourrait surestimer — un IDA* qui rend une solution sous-optimale sans le signaler. Testé à la construction, le défaut est attrapé avant tout usage en recherche (0 collision sur 19 975 états).\n",
+    "\n",
+    "</details>"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "finition-03b-csharp-plus-loin",
+   "metadata": {},
+   "source": [
+    "## Pour aller plus loin\n",
+    "\n",
+    "- **Jumeau Python** : [Search-03b-PatternDatabases](Search-03b-PatternDatabases.ipynb) — la même technique en Python, avec ses propres mesures (×8,4 à ×20,6 sur ses trois instances) et ses sections sur les quotients (information mutuelle, dette Ruzsa).\n",
+    "- **Carnet voisin** : [Search-03c-LimitedDiscrepancySearch-CSharp](Search-03c-LimitedDiscrepancySearch-CSharp.ipynb) — borner l'exploration par la structure du problème plutôt que par une meilleure estimation.\n",
+    "- **Dans la même série** : [Search-03-Informed-CSharp](Search-03-Informed-CSharp.ipynb) — la dominance des heuristiques, dont HAdditive ≥ HMax est une instance mesurée ici.\n",
+    "- **Exercices du carnet** : exercice 1 (partition 6-6-3), exercice 2 (PDB symétrique, Felner et al. 2004), exercice 3 (généralisation au 24-puzzle).\n",
+    "- **Lectures** : Korf & Felner (2002), *Disjoint Pattern Database Heuristics* — la partition 4-4-4-3 et la combinaison additive viennent de là."
+   ]
   }
  ],
  "metadata": {

MyIA.AI.Notebooks/Search/Part1-Foundations/Search-03b-PatternDatabases.ipynb

@@ -2454,6 +2454,62 @@
     "| ↑ [Search (racine)](../README.md) | [Partie 4 — Métaheuristiques →](../Part4-Metaheuristics/README.md)\n",
     "\n"
    ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "cec27659",
+   "metadata": {
+    "id": "finition-03b-a-retenir"
+   },
+   "source": [
+    "## À retenir\n",
+    "\n",
+    "1. **Une PDB échange du calcul contre une table** : un parcours rétrograde depuis le but abstrait calcule la distance optimale de chaque motif une fois pour toutes — 524 160 états pour un groupe de 4 tuiles (P(16,4) = 43 680 motifs × 12 positions de la case vide), construits en 12,1 s, et 43 680 pour le groupe de 3.\n",
+    "2. **L'admissibilité vient du relâchement** : le problème abstrait est plus permissif (les tuiles jokerisées bougent librement), donc sa distance minore la vraie. La table n'est jamais une estimation : c'est l'optimum d'un problème plus facile.\n",
+    "3. **La somme de groupes disjoints reste admissible, et paie** : la partition 4-4-4-3 donne h_additive = 36 contre h_max = 12 sur l'instance de démonstration (§6b, h_saturated = 36 au cap per_group = 15) ; chaque coup ne déplace qu'une tuile, donc ne coûte que dans une seule table.\n",
+    "4. **Le gain croît avec la difficulté** : ×8,4 (I1, opt 26), ×10,4 (I2, opt 40), au moins ×20,6 (I3, opt 52, Manhattan coupé au budget de 20 M de nœuds) — l'écart avec Manhattan se creuse à mesure que l'instance s'éloigne du but.\n",
+    "5. **La PDB repousse la frontière du résolvable** : sur I3, Manhattan plafonne à 20 000 000 de nœuds sans conclure (234,8 s) quand la PDB additive résout à l'optimum (972 772 nœuds, 52,1 s)."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "89c0ff16",
+   "metadata": {
+    "id": "finition-03b-verifiez"
+   },
+   "source": [
+    "## Vérifiez votre compréhension\n",
+    "\n",
+    "1. Une table de groupe de 4 tuiles compte 524 160 entrées alors que P(16,4) vaut 43 680. D'où vient le facteur 12, et pourquoi la case vide doit-elle figurer dans l'état abstrait ?\n",
+    "2. Pourquoi h_additive = h₁ + h₂ + h₃ + h₄ reste-t-elle admissible, alors qu'aucune des quatre tables ne connaît la position des autres groupes ?\n",
+    "3. Sur I3, Manhattan atteint la limite de 20 000 000 de nœuds sans conclure et la PDB additive résout. Le gain vient-il de la vitesse du calcul ou de la qualité de l'estimation ?\n",
+    "4. Dans la section 12, I(X_A ; X_B) vaut 2,070 389 bits alors que I(X_A ; X_B | S_B) vaut 0. Que montre ce témoin sur ce qu'un quotient « voit » ?\n",
+    "\n",
+    "<details><summary>Réponses</summary>\n",
+    "\n",
+    "1. Un motif de 4 tuiles admet P(16,4) = 43 680 placements, mais les coups applicables dépendent de l'emplacement libre : l'état abstrait est (placement du motif, case vide parmi les douze cases restantes), soit × 12 = 524 160. C'est ce que la cellule de construction affiche (« 524 160 états »), et le jumeau C# l'écrit explicitement : P(16,4) × 12.\n",
+    "2. Chaque coup du 15-puzzle déplace exactement une tuile, donc appartient à exactement un groupe : le coût total se partage sans recouvrement entre les tables, chacune minore sa part, donc la somme minore le total. C'est le partage de coûts de la section 6b — et c'est pour cela que h_max (maximum des tables) est ≤ h_additive.\n",
+    "3. De la qualité de l'estimation : h_additive = 36 contre h_max = 12 sur l'instance de démonstration. Une borne trois fois plus serrée élague les branches avant qu'elles ne s'ouvrent — l'arbre d'I3 tombe de 20 M de nœuds (plafond atteint) à 972 772, et le temps par nœud reste comparable.\n",
+    "4. Qu'une fois conditionné par le quotient commun S_B (les cellules occupées par le groupe B), il ne reste aucune information mutuelle entre les groupes : l'interaction marginale de 2,07 bits est entièrement expliquée par l'exclusion spatiale, que ce quotient capture. Le contre-témoin du quotient trop grossier Q' laisse 1,58 bit résiduel — le quotient doit être choisi exactement (et la commutation S_B est contingente : 80/84 fibres, contre 81/81 pour le groupe Z₉).\n",
+    "\n",
+    "</details>\n"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "id": "788f176b",
+   "metadata": {
+    "id": "finition-03b-plus-loin"
+   },
+   "source": [
+    "## Pour aller plus loin\n",
+    "\n",
+    "- **Jumeau .NET** : [Search-03b-PatternDatabases-CSharp](Search-03b-PatternDatabases-CSharp.ipynb) — la même technique en C#, avec ses propres mesures (×2,9 sur l'instance facile, puis Manhattan hors budget à 2 M de nœuds sur les deux instances difficiles).\n",
+    "- **Carnet voisin** : [Search-03c-LimitedDiscrepancySearch](Search-03c-LimitedDiscrepancySearch.ipynb) — borner l'exploration par la structure du problème plutôt que par une meilleure estimation.\n",
+    "- **Dans la même série** : [Search-03-Informed](Search-03-Informed.ipynb) — la dominance des heuristiques, dont h_additive ≥ h_max est une instance mesurée ici.\n",
+    "- **Exercices du carnet** : les exercices 4 à 7 généralisent la section 12 (information mutuelle conditionnelle générique, prix du quotient, commutation de la PDB complète, gain de la symétrie dans IDA*).\n",
+    "- **Lectures** : Korf & Felner (2002), *Disjoint Pattern Database Heuristics* — la partition 4-4-4-3 et la combinaison additive viennent de là ; Felner et al. (2004) pour les PDB symétriques.\n"
+   ]
   }
  ],
  "metadata": {
@@ -2489,4 +2545,4 @@
  },
  "nbformat": 4,
  "nbformat_minor": 5
-}
+}

scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0018-2026-10-31-myia-po-2024-CoursIA.yaml

@@ -0,0 +1,6 @@
+date: '2026-10-31'
+by: myia-po-2024:CoursIA
+python_sha: 54191142c7136137139f8b8eed5496edb3034aa4
+csharp_sha: cf26ee6006cf4855b8d327fbb2dec2ea9ed57be9
+content_python_sha: 617a47412252fccd7cf53501a65515c3e79c191d9ceda13bfb77d5990d714511
+content_csharp_sha: b7271010684cfd8c3312294e39a367a900a0fc7dc9a70cf061d15288e7b2b8f1

scripts/notebook_tools/twin_pairs.d/search-12-pattern-databases/0019-2026-10-31-myia-po-2024-CoursIA.yaml

@@ -0,0 +1,6 @@
+date: '2026-10-31'
+by: myia-po-2024:CoursIA
+python_sha: d5599c3350186c8f5e202c54853d2b57ee8e2d0b
+csharp_sha: cf26ee6006cf4855b8d327fbb2dec2ea9ed57be9
+content_python_sha: 85baba9aaff430a68afae618d76faf95f0542ae6419833ed829a2340e5f0add1
+content_csharp_sha: b7271010684cfd8c3312294e39a367a900a0fc7dc9a70cf061d15288e7b2b8f1