第2部 拡張モジュール：実践力強化トレーニング

モジュール1：分野別・生きた例文集（Real-world Examples）

〜教科書の中の Provided that と Unless 〜

数学の専門書を開いたとき、これらの接続詞がどのような文脈で、どのような「意図」を持って使われているか。解析学、代数学、位相幾何学の現場から実例を引いて解剖する。

1. 解析学：収束と定義域の安全弁

Example 1: “The series ${\sum }_{n=0}^{\infty }{r}^n$ converges to $\frac{1}{1-r}$, provided that $|r|<1$.”

【解剖】 ここでは “provided that” が、**「公式の有効期限」**を示している。 無限等比級数の公式 $\frac{1}{1-r}$ 自体は、$r=2$ でも計算できてしまう（値は -1 になる）。しかし、級数の収束という意味では無意味だ。 著者はここで If を使わず Provided that を選んだ。「この式を使っていいよ。ただし、この条件（$|r|<1$）という契約を守れるならね」という、公式使用のライセンス条件としてのニュアンスが強い。

Example 2: “The limit ${\lim }_{x\to 0}\frac{\sin x}{x}=1$ holds, unless the angle is measured in degrees.”

【解剖】 これは少しジョークめいた、しかし重要な警告だ。数学における三角関数の微積分は、角度がラジアンであることを大前提としている。度数法（degrees）を使うと、極限値は $\pi /180$ になってしまう。 “Unless” を使うことで、「数学の世界ではラジアンがデフォルト（標準）であり、度数法などというものは例外的な異物である」という著者の数学的価値観（規範）が表現されている。

2. 代数学：構造と除外の美学

Example 3: “Let $G$ be a finite group. Then $G$ is cyclic if and only if it has a unique subgroup of order $d$ for every divisor $d$ of $|G|$.”

【解剖】 これは群論の美しい定理だが、もしここに「自明な例外」があったらどう書くか？ 例えば、仮に $n=1$ の時だけ成り立たないとしたら： “…is cyclic unless $|G|=1$.” このように文末に付け足すことで、定理の美しい本体（Main statement）を傷つけずに、コーナーケースを処理できる。Unless は「美観を損ねないためのゴミ箱」としても機能する。

3. 位相幾何学：特異点と “Almost all”

Example 4: “The Euler characteristic $\chi (M)$ is an integer for every compact manifold $M$.” （ここで、境界がある場合どうするか？） “…provided that $M$ has no boundary.”

【解剖】 幾何学の定理は、多様体（Manifold）が「閉じていて（Closed）、境界がない（Without boundary）」などの良い性質を持っていることを前提にすることが多い。 冒頭で “Let $M$ be a closed manifold” と宣言してもいいが、定理の後ろに “provided that…” とつけることで、「この定理が適用できる限界（境界線）」を明示する効果がある。

---

モジュール2：誤用ケーススタディ（Common Mistakes）

〜その英語、数学者にはこう聞こえています〜

学生や非ネイティブの研究者が犯しやすいミスを、添削形式で紹介する。

Case 1: “Assume” と “Presume” の混同

Bad: “Presume that $x$ is rational.” Correction: “Assume that $x$ is rational.”

【なぜダメなのか】 日常英語の “Presume”（推定する）には、「証拠はないけど、たぶんそうだと思う」という確率的な推測のニュアンスが含まれる（“Dr. Livingstone, I presume?“）。 数学の証明において、背理法などで「$x$ が有理数だ」と置くのは、推測ではなく**「仮定という名の断定」**である。論理の世界に「たぶん」を持ち込んではいけない。

Case 2: “Except” の脱落

Bad: “The function is continuous without $x=0$.” Correction: “The function is continuous everywhere except at $x=0$.”

【なぜダメなのか】 “Without $x=0$” は「$x=0$ を持たずに」という意味になり、「$x=0$ という点を含まない定義域の上で」と言いたい意図はわかるが、文法的に不自然だ。 集合から点を除く操作は、英語では明確に “Except at…” あるいは “Expect for…” を使うのが定型句（Idiom）である。

Case 3: 循環する “Let”

Bad: “Let $n=2k$ be an even integer.” Correction: “Let $n$ be an even integer. Then we can write $n=2k$ for some integer $k$.”

【なぜダメなのか】 最初の文は、「$n$ を定義しているのか」「$k$ を定義しているのか」「$n=2k$ という関係式を仮定しているのか」が曖昧だ。 数学的定義の順序（Order of definition）を守ろう。

1. まず $n$ という偶数が存在する（Let $n$ be even）。
2. その偶数の定義から、$k$ という整数が存在して $n=2k$ と書ける（Then $n=2k$）。 このステップを飛ばして一つの “Let” に詰め込むと、論理の順序が崩れる。

---

モジュール3：「否定」の論理パズル

〜 “Unless” の否定を作れますか？ 〜

数学的思考力を鍛える最高のトレーニングは、複雑な条件文の**「否定命題（Negation）」**を作ることだ。

Level 1: Unless の否定

命題 P: “I will go to the party unless it rains.” （雨が降らない限り、パーティーに行く）

【思考プロセス】 この命題は $\neg (\text{Rain})⟹\text{Go}$ と同値である。 含意 $A⟹B$ の否定は $A\wedge \neg B$ である。 つまり、「雨が降らない（条件クリア）」かつ「パーティーに行かない（約束を破る）」状態が否定だ。

否定 $\neg P$: “It does not rain, and yet I do not go to the party.” （雨は降っていないのに、パーティーに行かない）

多くの人が間違えて「雨が降ったらパーティーに行かない（If rain, not go）」としてしまうが、それは元の命題の裏であって、否定ではない。

Level 2: “For all … except” の否定

命題 Q: “For all real numbers $x$, $f(x)>0$ except at $x=0$.” （$x=0$ を除くすべての実数で、$f(x)$ は正である）

【思考プロセス】 この命題は二つの主張を含んでいる。

1. $x\ne 0⟹f(x)>0$
2. （暗黙に）$x=0$ については何も言っていない、あるいは $x=0$ は除外されている。

この命題が「嘘（False）」であるとはどういうことか？ 「例外以外の場所（$x\ne 0$）なのに、正しくない（$f(x)\le 0$）やつがいる」ということだ。

否定 $\neg Q$: “There exists a real number $x$ such that $x\ne 0$ and $f(x)\le 0$.” （0ではないのに、値が正でないような $x$ が少なくとも一つ存在する）

「$x=0$ で $f(x)>0$ になること」は、否定とは関係ない（Except は除外しているので）。

---

モジュール4：コラム・プログラミング言語との比較

〜 Python と数学語のバイリンガルになろう 〜

現代の学習者にとって、論理をコードに例えることは非常に有効な理解手段だ。

数学英語	プログラミング（Python/C++）	解説
Provided that $P$	assert P	事前条件チェック。$P$ が False ならプログラム（議論）はクラッシュする。
Unless $Q$	if not Q: または try ... except Q:	$Q$ が発生しない正常系（Normal path）の記述。$Q$ は例外処理。
Let $x$ be…	x = ... (Declaration)	変数宣言。スコープ（有効範囲）が発生する。
Suppose $P$	(Unit Test における) Mocking	「もし DB がこう返してきたら」という仮想環境でのテスト実行。
In case	switch / case	排他的な条件分岐。網羅性が求められる。
Otherwise	else / default	上記の条件に当てはまらなかった全てのケース。

【洞察：コンパイラとしての数学者】 数学者が論文を読む時、彼らの脳内では厳格なコンパイラが動いている。 “Let $x$…” と来たらメモリを確保し、“Provided that…” と来たらアサーションをかける。 文章が論理的に破綻している（定義されていない変数を使うなど）と、脳内コンパイラは “Compilation Error” を吐き出し、読むのをやめてしまう。 数学的に正しい文章を書くとは、この「脳内コンパイラ」をエラーなく通過させるコードを書くことと同義なのだ。

---

以上の4つの観点によって、第2部は単なる用語解説を超え、読者が自らの手で論理を組み立て、推敲し、デバッグするための実践的ガイドブックとなる。