deploy

ja/chapter_array_and_linkedlist/summary/index.html

@@ -6,7 +6,7 @@
       <meta charset="utf-8">
       <meta name="viewport" content="width=device-width,initial-scale=1">
       
-        <meta name="description" content="アニメーションで図解、ワンクリック実行のデータ構造とアルゴリズムチュートリアル">
+        <meta name="description" content="アニメーション図解とワンクリック実行コードで学べるデータ構造とアルゴリズムの入門書">
       
       
         <meta name="author" content="krahets">
@@ -117,7 +117,7 @@
         <path
             d="M480 32c0-12.9-7.8-24.6-19.8-29.6s-25.7-2.2-34.9 6.9L381.7 53c-48 48-113.1 75-181 75H192 160 64c-35.3 0-64 28.7-64 64v96c0 35.3 28.7 64 64 64l0 128c0 17.7 14.3 32 32 32h64c17.7 0 32-14.3 32-32V352l8.7 0c67.9 0 133 27 181 75l43.6 43.6c9.2 9.2 22.9 11.9 34.9 6.9s19.8-16.6 19.8-29.6V300.4c18.6-8.8 32-32.5 32-60.4s-13.4-51.6-32-60.4V32zm-64 76.7V240 371.3C357.2 317.8 280.5 288 200.7 288H192V192h8.7c79.8 0 156.5-29.8 215.3-83.3z" />
     </svg>
-    <span>日本語版審閱者を募集しています！詳細は <a href="https://github.com/krahets/hello-algo/blob/main/ja/CONTRIBUTING.md">CONTRIBUTING.md</a> を参照してください。</span>
+    <span>日本語版のレビュアーを募集しています。詳しくは <a href="/ja/chapter_appendix/contribution/">こちら</a> をご覧ください。</span>
 </div>
 
           </div>
@@ -341,7 +341,7 @@
   <span class="md-ellipsis">
     
   
-    序
+    はじめに
   
 
     
@@ -358,7 +358,7 @@
             <span class="md-nav__icon md-icon"></span>
             
   
-    序
+    はじめに
   
 
           </label>
@@ -618,7 +618,7 @@
   <span class="md-ellipsis">
     
   
-    1.1 &nbsp; アルゴリズムはどこにでもある
+    1.1 &nbsp; アルゴリズムは至るところにある
   
 
     
@@ -646,7 +646,7 @@
   <span class="md-ellipsis">
     
   
-    1.2 &nbsp; アルゴリズムとは何か
+    1.2 &nbsp; アルゴリズムとは
   
 
     
@@ -783,7 +783,7 @@
   <span class="md-ellipsis">
     
   
-    2.1 &nbsp; アルゴリズムの効率評価
+    2.1 &nbsp; アルゴリズム効率の評価
   
 
     
@@ -1060,7 +1060,7 @@
   <span class="md-ellipsis">
     
   
-    3.3 &nbsp; 数値の符号化 *
+    3.3 &nbsp; 数値エンコーディング *
   
 
     
@@ -1088,7 +1088,7 @@
   <span class="md-ellipsis">
     
   
-    3.4 &nbsp; 文字の符号化 *
+    3.4 &nbsp; 文字エンコーディング *
   
 
     
@@ -1396,7 +1396,7 @@
   <a href="#1" class="md-nav__link">
     <span class="md-ellipsis">
       
-        1. &nbsp; 重要な復習
+        1. &nbsp; 要点の振り返り
       
     </span>
   </a>
@@ -1663,7 +1663,7 @@
   <span class="md-ellipsis">
     
   
-    第 6 章 &nbsp; ハッシュ表
+    第 6 章 &nbsp; ハッシュテーブル
   
 
     
@@ -1685,7 +1685,7 @@
             <span class="md-nav__icon md-icon"></span>
             
   
-    第 6 章 &nbsp; ハッシュ表
+    第 6 章 &nbsp; ハッシュテーブル
   
 
           </label>
@@ -1707,7 +1707,7 @@
   <span class="md-ellipsis">
     
   
-    6.1 &nbsp; ハッシュ表
+    6.1 &nbsp; ハッシュテーブル
   
 
     
@@ -2014,7 +2014,7 @@
   <span class="md-ellipsis">
     
   
-    7.5 &nbsp; AVL木 *
+    7.5 &nbsp; AVL 木 *
   
 
     
@@ -2177,7 +2177,7 @@
   <span class="md-ellipsis">
     
   
-    8.2 &nbsp; ヒープ構築操作
+    8.2 &nbsp; ヒープ構築
   
 
     
@@ -2563,7 +2563,7 @@
   <span class="md-ellipsis">
     
   
-    10.2 &nbsp; 二分探索の挿入点
+    10.2 &nbsp; 二分探索の挿入位置
   
 
     
@@ -2619,7 +2619,7 @@
   <span class="md-ellipsis">
     
   
-    10.4 &nbsp; ハッシュ最適化戦略
+    10.4 &nbsp; ハッシュによる最適化戦略
   
 
     
@@ -2647,7 +2647,7 @@
   <span class="md-ellipsis">
     
   
-    10.5 &nbsp; 探索アルゴリズムの再認識
+    10.5 &nbsp; 探索アルゴリズム再考
   
 
     
@@ -3185,7 +3185,7 @@
   <span class="md-ellipsis">
     
   
-    12.1 &nbsp; 分割統治アルゴリズム
+    12.1 &nbsp; 分割統治法
   
 
     
@@ -3241,7 +3241,7 @@
   <span class="md-ellipsis">
     
   
-    12.3 &nbsp; 木の構築問題
+    12.3 &nbsp; 二分木の構築問題
   
 
     
@@ -3269,7 +3269,7 @@
   <span class="md-ellipsis">
     
   
-    12.4 &nbsp; ハノイの塔問題
+    12.4 &nbsp; ハノイの塔の問題
   
 
     
@@ -3462,7 +3462,7 @@
   <span class="md-ellipsis">
     
   
-    13.3 &nbsp; 部分集合和問題
+    13.3 &nbsp; 部分和問題
   
 
     
@@ -3490,7 +3490,7 @@
   <span class="md-ellipsis">
     
   
-    13.4 &nbsp; Nクイーン問題
+    13.4 &nbsp; n クイーン問題
   
 
     
@@ -3631,7 +3631,7 @@
   <span class="md-ellipsis">
     
   
-    14.1 &nbsp; 動的計画法の初歩
+    14.1 &nbsp; 動的計画法入門
   
 
     
@@ -3659,7 +3659,7 @@
   <span class="md-ellipsis">
     
   
-    14.2 &nbsp; DP 問題の特性
+    14.2 &nbsp; 動的計画法の問題特性
   
 
     
@@ -3687,7 +3687,7 @@
   <span class="md-ellipsis">
     
   
-    14.3 &nbsp; DP の解法の考え方
+    14.3 &nbsp; 動的計画法の問題解決の考え方
   
 
     
@@ -3715,7 +3715,7 @@
   <span class="md-ellipsis">
     
   
-    14.4 &nbsp; 0-1ナップサック問題
+    14.4 &nbsp; 0-1 ナップサック問題
   
 
     
@@ -3908,7 +3908,7 @@
   <span class="md-ellipsis">
     
   
-    15.1 &nbsp; 貪欲アルゴリズム
+    15.1 &nbsp; 貪欲法
   
 
     
@@ -4153,7 +4153,7 @@
   <span class="md-ellipsis">
     
   
-    16.2 &nbsp; 一緒に創作に参加する
+    16.2 &nbsp; 一緒に制作に参加しましょう
   
 
     
@@ -4299,7 +4299,7 @@
   <a href="#1" class="md-nav__link">
     <span class="md-ellipsis">
       
-        1. &nbsp; 重要な復習
+        1. &nbsp; 要点の振り返り
       
     </span>
   </a>
@@ -4355,60 +4355,62 @@
 
 <!-- Page content -->
 <h1 id="45">4.5 &nbsp; まとめ<a class="headerlink" href="#45" title="Permanent link">&para;</a></h1>
-<h3 id="1">1. &nbsp; 重要な復習<a class="headerlink" href="#1" title="Permanent link">&para;</a></h3>
+<h3 id="1">1. &nbsp; 要点の振り返り<a class="headerlink" href="#1" title="Permanent link">&para;</a></h3>
 <ul>
-<li>配列と連結リストは2つの基本的なデータ構造であり、コンピュータメモリにおける2つの格納方法を表しています：連続空間格納と非連続空間格納です。それらの特性は互いに補完し合います。</li>
-<li>配列はランダムアクセスをサポートし、使用するメモリが少ない一方で、要素の挿入と削除は非効率的で、初期化後の長さが固定されています。</li>
-<li>連結リストは参照（ポインタ）の変更によって効率的なノードの挿入と削除を実装し、長さを柔軟に調整できますが、ノードアクセス効率が低く、より多くのメモリを消費します。</li>
-<li>連結リストの一般的な種類には、単方向連結リスト、循環連結リスト、双方向連結リストがあり、それぞれに独自の応用シナリオがあります。</li>
-<li>リストは要素の順序付けられたコレクションで、追加、削除、変更をサポートし、通常は動的配列に基づいて実装され、配列の利点を保持しながら柔軟な長さ調整を可能にします。</li>
-<li>リストの出現により配列の実用性が大幅に向上しましたが、一部のメモリ空間の無駄につながる可能性があります。</li>
-<li>プログラム実行中、データは主にメモリに格納されます。配列はより高いメモリ空間効率を提供し、連結リストはメモリ使用においてより柔軟です。</li>
-<li>キャッシュは、キャッシュライン、先読み、空間的局所性、時間的局所性などのメカニズムを通じてCPUに高速データアクセスを提供し、プログラム実行効率を大幅に向上させます。</li>
-<li>より高いキャッシュヒット率により、配列は一般的に連結リストよりも効率的です。データ構造を選択する際は、特定のニーズとシナリオに基づいて適切な選択をすべきです。</li>
+<li>配列と連結リストは 2 種類の基本的なデータ構造であり、それぞれコンピュータメモリにおけるデータの 2 つの格納方式、すなわち連続領域への格納と分散領域への格納を表す。両者の特徴は相互補完的である。</li>
+<li>配列はランダムアクセスをサポートし、使用メモリも少ない。一方で、要素の挿入と削除の効率は低く、初期化後に長さを変更できない。</li>
+<li>連結リストは参照（ポインタ）を変更することでノードの挿入と削除を効率的に行え、長さも柔軟に調整できる。一方で、ノードへのアクセス効率は低く、メモリ使用量も多い。一般的な連結リストには単方向連結リスト、循環連結リスト、双方向連結リストがある。</li>
+<li>リストは、追加・削除・検索・更新をサポートする順序付き要素集合であり、通常は動的配列に基づいて実装される。配列の利点を保ちながら、長さを柔軟に調整できる。</li>
+<li>リストの登場により配列の実用性は大幅に高まったが、一部のメモリ領域が無駄になる可能性がある。</li>
+<li>プログラムの実行時、データは主にメモリに格納される。配列はより高いメモリ空間効率を提供でき、連結リストはメモリ利用の面でより柔軟である。</li>
+<li>キャッシュは、キャッシュライン、プリフェッチ機構、空間局所性と時間局所性といったデータ読み込み機構を通じて CPU に高速なデータアクセスを提供し、プログラムの実行効率を大きく向上させる。</li>
+<li>配列はキャッシュヒット率が高いため、通常は連結リストよりも高効率である。データ構造を選択する際は、具体的な要件や場面に応じて適切に選ぶべきである。</li>
 </ul>
 <h3 id="2-q-a">2. &nbsp; Q &amp; A<a class="headerlink" href="#2-q-a" title="Permanent link">&para;</a></h3>
-<p><strong>Q</strong>：配列をスタックに格納するかヒープに格納するかは、時間と空間効率に影響しますか？</p>
-<p>スタックとヒープの両方に格納される配列は連続したメモリ空間に格納され、データ操作効率は本質的に同じです。しかし、スタックとヒープには独自の特性があり、以下の違いが生じます。</p>
+<p><strong>Q</strong>：配列をスタックに格納する場合とヒープに格納する場合では、時間効率と空間効率に影響がありますか？</p>
+<p>スタック上とヒープ上の配列はいずれも連続したメモリ領域に格納されるため、データ操作の効率は基本的に同じである。ただし、スタックとヒープにはそれぞれ特徴があり、以下の違いが生じる。</p>
 <ol>
-<li>割り当てと解放効率：スタックはより小さなメモリブロックで、コンパイラによって自動的に割り当てられます。ヒープメモリは比較的大きく、コードで動的に割り当てることができ、断片化しやすいです。したがって、ヒープでの割り当てと解放操作は一般的にスタックよりも遅くなります。</li>
-<li>サイズ制限：スタックメモリは比較的小さく、ヒープサイズは一般的に利用可能なメモリによって制限されます。したがって、ヒープは大きな配列の格納により適しています。</li>
-<li>柔軟性：スタック上の配列のサイズはコンパイル時に決定される必要がありますが、ヒープ上の配列のサイズは実行時に動的に決定できます。</li>
+<li>確保と解放の効率：スタックは比較的小さなメモリ領域で、確保はコンパイラによって自動的に行われる。一方、ヒープメモリは相対的に大きく、コード内で動的に確保できる反面、断片化しやすい。そのため、ヒープ上での確保と解放は通常スタック上より遅い。</li>
+<li>サイズ制限：スタックメモリは比較的小さく、ヒープのサイズは一般に利用可能メモリに制限される。そのため、ヒープは大きな配列の格納により適している。</li>
+<li>柔軟性：スタック上の配列サイズはコンパイル時に確定している必要があるが、ヒープ上の配列サイズは実行時に動的に決定できる。</li>
 </ol>
-<p><strong>Q</strong>：なぜ配列は同じ型の要素を必要とし、連結リストは同じ型の要素を強調しないのですか？</p>
-<p>連結リストは参照（ポインタ）によって接続されたノードで構成され、各ノードはint、double、string、objectなど、異なる型のデータを格納できます。</p>
-<p>対照的に、配列要素は同じ型である必要があり、これにより対応する要素位置にアクセスするためのオフセットを計算できます。例えば、intとlong型の両方を含む配列で、単一要素がそれぞれ4バイトと8バイトを占有する場合、配列に2つの異なる長さの要素が含まれているため、以下の式を使用してオフセットを計算できません。</p>
-<div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="c1"># 要素メモリアドレス = 配列メモリアドレス + 要素長 * 要素インデックス</span>
+<p><strong>Q</strong>：なぜ配列では同じ型の要素が求められるのに、連結リストでは同じ型であることが強調されないのですか？</p>
+<p>連結リストはノードで構成され、ノード同士は参照（ポインタ）で接続されている。各ノードには <code>int</code>、<code>double</code>、<code>string</code>、<code>object</code> など、異なる型のデータを格納できる。</p>
+<p>これに対して、配列要素は同じ型でなければならない。そうでなければ、オフセットを計算して対応する要素位置を取得できないからである。たとえば、配列に <code>int</code> と <code>long</code> の 2 種類が同時に含まれていて、各要素がそれぞれ 4 バイトと 8 バイトを占める場合、配列内に 2 種類の「要素長」が存在するため、次の式ではオフセットを計算できない。</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="c1"># 要素のメモリアドレス = 配列のメモリアドレス（先頭要素のメモリアドレス） + 要素長 * 要素インデックス</span>
 </code></pre></div>
-<p><strong>Q</strong>：ノードを削除した後、<code>P.next</code>を<code>None</code>に設定する必要がありますか？</p>
-<p><code>P.next</code>を変更しなくても問題ありません。連結リストの観点から、ヘッドノードからテールノードまでの巡回で<code>P</code>に遭遇することはもうありません。これは、ノード<code>P</code>がリストから効果的に削除されたことを意味し、<code>P</code>が指す場所はもはやリストに影響しません。</p>
-<p>ガベージコレクションの観点から、Java、Python、Goなどの自動ガベージコレクションメカニズムを持つ言語では、ノード<code>P</code>が収集されるかどうかは、それを指す参照がまだあるかどうかに依存し、<code>P.next</code>の値には依存しません。CやC++などの言語では、ノードのメモリを手動で解放する必要があります。</p>
-<p><strong>Q</strong>：連結リストでは、挿入と削除操作の時間計算量は<code>O(1)</code>です。しかし、挿入や削除前の要素検索には<code>O(n)</code>時間がかかるので、なぜ時間計算量は<code>O(n)</code>ではないのですか？</p>
-<p>要素を最初に検索してから削除する場合、時間計算量は確かに<code>O(n)</code>です。しかし、連結リストの挿入と削除における<code>O(1)</code>の利点は他のアプリケーションで実現できます。例えば、連結リストを使用した両端キューの実装では、常にヘッドとテールノードを指すポインタを維持し、各挿入と削除操作を<code>O(1)</code>にします。</p>
-<p><strong>Q</strong>：「連結リストの定義と格納方法」の図で、薄青色の格納ノードは単一のメモリアドレスを占有しますか、それともノード値と半分を共有しますか？</p>
-<p>図は単なる定性的な表現であり、定量的分析は特定の状況に依存します。</p>
+<p><strong>Q</strong>：ノード <code>P</code> を削除した後、<code>P.next</code> を <code>None</code> に設定する必要はありますか？</p>
+<p><code>P.next</code> を変更しなくてもよい。この連結リストの観点では、先頭ノードから末尾ノードまでたどっても、もはや <code>P</code> に出会うことはない。つまり、ノード <code>P</code> はすでに連結リストから削除されており、この時点で <code>P</code> がどこを指していても、この連結リストには影響しない。</p>
+<p>データ構造とアルゴリズム（問題を解くとき）の観点では、切り離さなくても問題はなく、プログラムのロジックが正しいことを保証すればよい。標準ライブラリの観点では、切り離したほうがより安全で、ロジックも明確である。切り離さない場合、削除されたノードが適切に回収されなかったとすると、後続ノードのメモリ回収に影響する可能性がある。</p>
+<p><strong>Q</strong>：連結リストでの挿入と削除の時間計算量は <span class="arithmatex">\(O(1)\)</span> です。しかし、追加や削除の前には要素を探すのに <span class="arithmatex">\(O(n)\)</span> の時間が必要です。では、なぜ時間計算量は <span class="arithmatex">\(O(n)\)</span> ではないのですか？</p>
+<p>要素を先に探してから削除するのであれば、時間計算量が <span class="arithmatex">\(O(n)\)</span> であるのは確かである。しかし、連結リストの <span class="arithmatex">\(O(1)\)</span> での追加・削除という利点は、ほかの用途で生かせる。たとえば、両端キューは連結リストで実装するのに適しており、先頭ノードと末尾ノードを常に指すポインタ変数を維持すれば、各挿入・削除操作はどれも <span class="arithmatex">\(O(1)\)</span> になる。</p>
+<p><strong>Q</strong>：図「連結リストの定義と格納方式」で、薄青色のノードポインタ部分は 1 つのメモリアドレスを占めているのですか？ それともノード値と半分ずつなのでしょうか？</p>
+<p>この模式図は定性的な表現にすぎず、定量的な表現は具体的な状況に応じて分析する必要がある。</p>
 <ul>
-<li>異なる型のノード値は異なる量の空間を占有します。例えば、int、long、double、オブジェクトインスタンスです。</li>
-<li>ポインタ変数によって占有されるメモリ空間は、使用されるオペレーティングシステムとコンパイル環境に依存し、通常8バイトまたは4バイトです。</li>
+<li>ノード値が占める領域は型によって異なり、たとえば <code>int</code>、<code>long</code>、<code>double</code>、インスタンスオブジェクトなどがある。</li>
+<li>ポインタ変数が占めるメモリ空間の大きさは、使用する OS やコンパイル環境によって異なり、多くは 8 バイトまたは 4 バイトである。</li>
 </ul>
-<p><strong>Q</strong>：リストの末尾への要素追加は常に<code>O(1)</code>ですか？</p>
-<p>要素を追加することでリスト長を超える場合、リストは最初に拡張される必要があります。システムは新しいメモリブロックを要求し、元のリストのすべての要素を移動するため、この場合の時間計算量は<code>O(n)</code>になります。</p>
-<p><strong>Q</strong>：「リストの出現により配列の実用性が大幅に向上しましたが、一部のメモリ空間の無駄につながる可能性があります」という文は、容量、長さ、拡張係数などの追加変数によって占有されるメモリを指していますか？</p>
-<p>ここでの空間の無駄は主に2つの側面を指します：一方で、リストは初期長で設定されますが、常に必要とは限りません。他方で、頻繁な拡張を防ぐため、拡張は通常<span class="arithmatex">\(\times 1.5\)</span>などの係数で乗算されます。これにより多くの空きスロットが生まれ、通常は完全に埋めることができません。</p>
-<p><strong>Q</strong>：Pythonで<code>n = [1, 2, 3]</code>を初期化した後、これら3つの要素のアドレスは連続していますが、<code>m = [2, 1, 3]</code>を初期化すると、各要素の<code>id</code>は連続していないが<code>n</code>のものと同一です。これらの要素のアドレスが連続していない場合、<code>m</code>はまだ配列ですか？</p>
-<p>リスト要素を連結リストノード<code>n = [n1, n2, n3, n4, n5]</code>に置き換える場合、これら5つのノードオブジェクトも通常メモリ全体に分散しています。しかし、リストインデックスが与えられれば、<code>O(1)</code>時間でノードのメモリアドレスにアクセスでき、対応するノードにアクセスできます。これは、配列がノード自体ではなく、ノードへの参照を格納するためです。</p>
-<p>多くの言語とは異なり、Pythonでは数値もオブジェクトとしてラップされ、リストは数値自体ではなく、これらの数値への参照を格納します。したがって、2つの配列の同じ数値が同じ<code>id</code>を持ち、これらの数値のメモリアドレスは連続である必要がないことがわかります。</p>
-<p><strong>Q</strong>：C++ STLの<code>std::list</code>はすでに双方向連結リストを実装していますが、一部のアルゴリズム書籍では直接使用していないようです。何か制限がありますか？</p>
-<p>一方で、アルゴリズムを実装する際は配列を使用することを好み、必要な場合のみ連結リストを使用します。主に2つの理由があります。</p>
+<p><strong>Q</strong>：リストの末尾への要素追加は常に <span class="arithmatex">\(O(1)\)</span> ですか？</p>
+<p>要素を追加する際にリスト長を超える場合は、先にリストを拡張してから追加する必要がある。システムは新しいメモリ領域を確保し、元のリストの全要素をそこへ移動するため、このとき時間計算量は <span class="arithmatex">\(O(n)\)</span> になる。</p>
+<p><strong>Q</strong>：「リストの登場により配列の実用性は大きく向上したが、一部のメモリ空間が無駄になる可能性がある」というのは、容量、長さ、拡張倍率のような追加変数が占めるメモリのことですか？</p>
+<p>ここでいう空間の無駄には主に 2 つの意味がある。一方では、リストには初期長が設定されるが、必ずしもそれだけ必要とは限らない。もう一方では、頻繁な拡張を防ぐため、拡張時には通常ある係数、たとえば <span class="arithmatex">\(\times 1.5\)</span> を掛ける。このため、多くの空きスロットが生じ、通常それらを完全に埋めることはできない。</p>
+<p><strong>Q</strong>：Python で <code>n = [1, 2, 3]</code> を初期化した後、この 3 つの要素のアドレスは連続しています。しかし <code>m = [2, 1, 3]</code> を初期化すると、各要素の id は連続しておらず、それぞれ <code>n</code> 内の同じ値と一致していることがわかります。これらの要素のアドレスが連続していないなら、<code>m</code> も配列なのですか？</p>
+<p>仮にリスト要素を連結リストのノード <code>n = [n1, n2, n3, n4, n5]</code> に置き換えたとしても、通常この 5 つのノードオブジェクトもメモリ上の各所に分散して格納される。それでも、与えられたリストインデックスに対して、私たちは依然として <span class="arithmatex">\(O(1)\)</span> 時間でノードのメモリアドレスを取得し、対応するノードにアクセスできる。これは、配列に格納されているのがノードそのものではなく、ノードへの参照だからである。</p>
+<p>多くの言語と異なり、Python では数値もオブジェクトとしてラップされており、リストに格納されているのは数値そのものではなく、数値への参照である。そのため、2 つの配列内の同じ数値が同一の id を持つことがあり、しかもそれらの数値のメモリアドレスは連続している必要がない。</p>
+<p><strong>Q</strong>：C++ STL の <code>std::list</code> はすでに双方向連結リストを実装していますが、アルゴリズム本ではあまり直接使われないようです。何か制約があるのでしょうか？</p>
+<p>一方では、私たちは多くの場合、アルゴリズムの実装に配列を好み、必要なときにだけ連結リストを使う。その主な理由は 2 つある。</p>
 <ul>
-<li>空間オーバーヘッド：各要素に2つの追加ポインタ（前の要素用と次の要素用）が必要なため、<code>std::list</code>は通常<code>std::vector</code>よりも多くの空間を占有します。</li>
-<li>キャッシュ非友好的：データが連続して格納されていないため、<code>std::list</code>はキャッシュ利用率が低くなります。一般的に、<code>std::vector</code>の方がパフォーマンスが優れています。</li>
+<li>空間オーバーヘッド：各要素には 2 つの追加ポインタ（前の要素用と次の要素用）が必要なため、<code>std::list</code> は通常 <code>std::vector</code> より多くの空間を消費する。</li>
+<li>キャッシュ非効率：データが連続して格納されていないため、<code>std::list</code> はキャッシュの利用効率が低い。一般には、<code>std::vector</code> のほうが性能がよい。</li>
 </ul>
-<p>他方で、連結リストは主に二分木とグラフに必要です。スタックとキューは、連結リストではなく、プログラミング言語の<code>stack</code>と<code>queue</code>クラスを使用して実装されることが多いです。</p>
-<p><strong>Q</strong>：リスト<code>res = [0] * self.size()</code>を初期化すると、<code>res</code>の各要素は同じアドレスを参照しますか？</p>
-<p>いいえ。しかし、この問題は二次元配列で発生します。例えば、二次元リスト<code>res = [[0]] * self.size()</code>を初期化すると、同じリスト<code>[0]</code>を複数回参照することになります。</p>
-<p><strong>Q</strong>：ノードを削除する際、その後続ノードへの参照を断つ必要がありますか？</p>
-<p>データ構造とアルゴリズム（問題解決）の観点から、プログラムのロジックが正しい限り、リンクを断たなくても問題ありません。標準ライブラリの観点から、リンクを断つ方が安全で論理的に明確です。リンクを断たず、削除されたノードが適切にリサイクルされない場合、後続ノードのメモリのリサイクルに影響を与える可能性があります。</p>
+<p>もう一方では、連結リストを使う必要がある代表的な場面は主に二分木とグラフである。スタックやキューについては、連結リストではなく、たいてい言語が提供する <code>stack</code> と <code>queue</code> を使う。</p>
+<p><strong>Q</strong>：<code>res = [[0]] * n</code> という操作で 2 次元リストを生成した場合、それぞれの <code>[0]</code> は独立していますか？</p>
+<p>独立していない。この 2 次元リストでは、すべての <code>[0]</code> は実際には同一オブジェクトへの参照である。そのうちの 1 つを変更すると、対応するすべての要素が一緒に変化することがわかる。</p>
+<p>2 次元リスト内の各 <code>[0]</code> を独立させたい場合は、<code>res = [[0] for _ in range(n)]</code> を使って実現できる。この方式の原理は、独立した <code>[0]</code> リストオブジェクトを <span class="arithmatex">\(n\)</span> 個初期化していることにある。</p>
+<p><strong>Q</strong>：<code>res = [0] * n</code> という操作で生成されたリストでは、それぞれの整数 0 は独立していますか？</p>
+<p>このリストでは、すべての整数 0 が同一オブジェクトへの参照である。これは、Python が小さな整数（通常は -5 から 256）に対してキャッシュプール機構を採用し、オブジェクトの再利用を最大化して性能を向上させているためである。</p>
+<p>それらは同じオブジェクトを指しているが、それでもリスト内の各要素は独立して変更できる。これは、Python の整数が「イミュータブルオブジェクト」だからである。ある要素を変更するとき、実際には別のオブジェクトへの参照に切り替わるのであって、元のオブジェクトそのものを変更しているわけではない。</p>
+<p>しかし、リスト要素が「ミュータブルオブジェクト」（たとえばリスト、辞書、クラスインスタンスなど）である場合は、ある要素を変更するとそのオブジェクト自体が直接変更され、そのオブジェクトを参照しているすべての要素に同じ変化が生じる。</p>
 
 <!-- Source file information -->