  |
はてなキーワード: 整数とは
高校数学まで、「自然数」は正の整数を指すものとされているが、
大学に入ると、フォンノイマンによる自然数の構成法からの流れで、「自然数」は0を含む正の整数として扱われることが多い。
だから、論文で「自然数」という言葉を使うとき（そして、花文字の「N」を使うとき）は、
序文かどこかで、この論文ではどちらの定義で行くのか予め述べておかなくてはいけない。
これって面倒なことだと思う。本文を抜粋していきなり読むと、「自然数」の定義を間違えてけつまずく可能性がある。
そもそも、論理性が大事な数学という学問において、なんでこんな曖昧な単語が残っているのか不思議だ。
なので、境界となる数を含むかどうかで「0を超える」「0以上」と言い分けるように、「自然数」という言葉自体も2つの言葉に分けるべきだと思う。
しかし、「0を超える整数」は「正の数」と呼べばわかるのに対し、「0以上の整数」は「自然数」以外の、それこそ自然な呼び方が思い付かない。
最高次係数が1である多項式のことを「モニック多項式」と呼ぶのだが、
この「モニック」に対応する日本語訳をいまだに見たことがない。いまだに、外来語＋漢字の組合せで呼ばれている。
ちなみに、「最高次係数が1である」場合を特別に扱うのはn次方程式からの流れ。
最高次係数で左辺・右辺を割ってしまえば、方程式では最高次係数が1の場合だけ考えれば十分であるため。
そんな中学生でも理解できる単純な概念なのに、しっくり来る日本語訳が無いのが不思議だ。
でも、係数が1なのは単純化のためだから、「単純」って呼ぼうとすると、その言葉は群論で使われてるし、
何かのゲームでこういう問題があったらしいが、これの答えが「偶数」だと言って譲らない人たちが一定数いる。
結論から述べれば、これは「どちらでもない」が正しい。そもそもすべての素数の積は整数ではないから、偶奇もクソも無いからだ。なお、一部の分かっていない人のために以下を補足しておく。
まず、これは立場や解釈によって答えが変わる問題ではない（少なくとも、一般的な数学の体系を前提とする限り）。つまり、一部の分野ではすべての素数の積を偶数とみなすとか、整数を拡張した概念ではこれが偶数になるわけではないのである。そういう分野も探せばあるのかも知れないが、それは全く一般的ではないし、数学的に有用と認められているわけでもない。それは個人の勝手な脳内定義と変わらない。
また、これに答えるのに高度な数学の知識は必要ない。中学・高校数学の範囲で答えが一意に定まる問題である。これを「偶数」だと答える人は、単純に初等数学が身に付いていない。「2がかかってるから偶数」などと言っているようでは、大学入試ですら点を貰えないだろう。
この問題は、高等数学の教育を受けた人なら、まず間違えないと思われる。というのも、大学教養レベルの数学では、無限を正確に扱うことが非常に重要になるからだ。たとえば、
S[n] = 1 + 1/2 + 1/4 + ... + 1/2^n
を考えると、任意の自然数nに対してS[n]は2未満だが、その極限は2未満ではない。このように、有限に対して成り立つ性質が、無限に対しては成り立たないということは頻繁にあり、大学数学を学んだ人はその区別が重要だと知っている。つまり、上の問題を間違える人は、高等数学の知識に乏しく、そもそも数学を云々するだけの能力が無い可能性が高い。
ここで問題にしたいのは、この問題が解けるかどうかよりも、明らかにある分野の知識や経験に乏しいにもかかわらず、自説が正しいと信じて疑わない人々の精神性だ。この問題の答えが「偶数」だと言う人は、整数や倍数といった基礎的な概念すら理解しておらず、無限の取り扱いにも注意を払えない。つまり、客観的に見て明らかに数学の能力に乏しいのであるが、往々にしてそのような人ほど、自己主張が強いのである。
こういうことは、何も数学に限った話ではない。たとえば、歴史も経済も勉強したことのないネット右翼の連中は、南京大虐殺は無かったとか韓国経済崩などの荒唐無稽な戯言を日夜連呼している。反原発派のほとんどは放射線についてまともな知識を持っていないが、自分たちこそ正しいと信じて過激な政治運動を繰り返している。オーディオオタクは、高額なケーブルなどで音質が向上すると信じ込んでいて、効果が実感できない奴は耳が悪いからと言って自説を曲げようとしない。マイナスイオンとか水素水とか信じてる連中は科学リテラシー皆無だが、自分たちは現代科学の先を行ってると思い込んでいる。他にも挙げればキリがない。
こういう人たちは、専門的なことや抽象的なことを腰を据えて学ぶという習慣がなく、常に物事を自分の都合の良いように捉えて分かった気になっている。議論になっても、結論ありきで、インターネットで聞きかじった知識で自説を補強することしか考えていない。苦しくなると論点や定義をすり替える。そもそも彼らには、正しいことを言ったり、生産的な提案をしたりして、議論に貢献しようと言う気すらない。相手が何を言っていようが、所構わず口喧嘩を吹っ掛けて承認欲求が満たされればそれでいいと考えている。
まず、コンピュータゲームがほとんど巷に存在しない時代にPongが登場すれば、そりゃみんなゲームにワクワクしたはず
アメリカにアーケードゲーム筐体だってそのものがない時代なんだから
だからスティーブ・ウォズニアックだってApple IだのIIだのでPongの実装はやっていたはず
それもスティーブ・ジョブズは売りにしてたはずだ
Pongが動作すると、次はブロック崩し（Breakout）が作れる
プログラミングのコツの一つは他人のプログラムを改変することだ
Pongが動くなら、そこからドットやドットの塊をVRAMに描画することは可能だと気付くだろう
でも、単なる壁打ちや対戦ゲームだったPongのゲーム性を大きく変えることになる
日本のゲーム企業タイトーは、このブロック崩しをインベーダーゲームに「再々」発明した
これも実現可能であることは誰でも分かるが、ゲーム性を大きく変えることはある種の発明だと思う
ちなみに、孫正義はタイムマシン商法が得意で、このインベーダーゲームをアメリカに輸出し大儲けした
相変わらず、左から右、右から左に他人のものを移動して儲けるのが上手い（いや、本心から褒めてるんですよ
インベーダーゲームでは、ブロックは上から段々と降りてくることになる
また、ブロックが左右に動く、UFOは高速に動く、手前のバリケードがありドット単位で破壊される
プログラミングのコツの一つである、他人のコードを改造する、は本当に素晴らしい再発明を起こしてくれる
Pong → ブロック崩し → インベーダーゲーム → ギャラクシアン → ゼビウス → グラディウス → 斑鳩だの東方だの弾幕避けだの何だの
に繋がっていくわけだが、
この矢印での「パラダイムシフト」の段差が高いほど、ゲームに対するワクワク感が増すと自分は考える
つまり、ギャラクシアンのようなグラフィックからゼビウスが登場したときは、
安っぽい言葉で形容するなら一大センセーションというかエポックメイキングという感じだったわけだ
しかし、今の時代、2Dシューターにそんなにワクワクはあるだろうか？
というか、マニアでない奴が口を挟むな、と言うぐらいタコツボ化しているように思うのだが、
寧ろ、様式美とかお約束が守られてることがプレイヤーの安堵感につながる
2Dシューターができれば3Dシューターが作れるのも自明である
ただ、マシンのグラフィクスの能力が低かった時代にはリアルタイムでの3次元CGの実現が難しく、
アメリカではベクタースキャン、つまりオシロスコープやブラウン管テレビの走査線方式が主流だった時期もあったが、
アメリカではワイヤーフレームの3Dゲームが実現していた時代、日本はファミコンに向かっていた
自分にはハードウェアによるスプライトに固執し、束縛され過ぎているかのように今からすると思える
一方、ファミコンのスプライトの数はMSXと比べると段違いであったが、
ファミコンは2Dスプライトベースのゲームだけを前提としていた
つまり、ファミコンでブレゼンハムのアルゴリズムによる直線を引くとか困難だったのではないだろうか
自分はファミコンの開発はよく知らないのだが、ファミコン版のテグザーは酷すぎると思った
MSXの方がファミコンよりもトータルのグラフィック性能が劣るにも関わらず、
こうやってだらだら書き連ねてみると、
つくづくワクワクするのは何だってアーリーアダプターの段階であって、
そのあと結婚だって何だって倦怠期？ワクワクが減少する時期がやってくるのである
何もない状況にパラダイムシフトを起こす何かがやってくるとワクワクするのであるならば、
乳児はこの世界の何もかもにものすごくワクワクしていると思われる
乳児でなくなると、この世界の変化しないものは常識として脳に定着して、つまらないものにさえなる
でも、若ければまだまだ体験していないことはあるわけだ
若ければギャラクシアン → ゼビウスがどれだけスゴかったかなんて知らんし、俺も知らんｗ
でも、ギャラクシアンより先にゼビウス見た世代だけど、凄いなあとは思ったんだよな
だって、自分の場合はギャラクシアンを飛び越えてゼビウスだったんだから
逆にギャラクシアンの方を後から知って、古臭いゲームだなー、レトロだなーと思ったんだから
（ただ、ギャラクシアンの曲線的な軌道はゼビウスなんかより凄い発明に思うんだが。整数演算なんだよね？
ただ、レトロレトロとバカにする人はプログラマーでないとかなんだろうけど、
ゼロからコード書くって、何もないところから作ることを考えさせられるわけで、
それはゲームのプログラムを書くならば、ゲームの基本のPongから考えさせられることになる
例えば、ゲームプログラムを書くときSDLとかSFMLみたいなライブラリは使うかもしれないけど、
自分も何か新しいゲーム開発のライブラリとかフレームワークとか検証するときは、
から始めて、次に倉庫番、簡単なブロック崩し、テトリスを実装するとかやることにしている
そこで開発の大まかな進行とかフレームレートとか、色々分かってくるわけだ
ジョン・カーマックがどこで語ってたのか忘れたけど、最近のFPSは完全にMOD開発になっていて、
そのMOD開発の費用はどんどん膨らんでいっていると言ってた気がする
つまり、レベルエディットとかキャラクターだアイテムだとか、そういうコンテンツの緻密な開発だけが進んでいる気がする
GTAみたいなゲームもFPSとかで培った技術の集大成にすぎない
可視領域をどう区切るか？遠くの建物にLODを使うか？インポスターを使うか？とかそういったゲームエンジンの話は、
マシンパワーの向上やUnityなどのゲームエンジンの登場であまり議論する意味がなくなってきている感がある
もっとも、Unityなり導入すれば簡単に作れるという話ではないと思う
思うが、もうゼロからチマチマCのベクトル計算のコードを書く時代ではなくなっているのは確かだろう
カーマックはその高騰するMOD開発をマインクラフトは意図的に安価にしたと言ってた気がする
つまり、マインクラフトであれば子供でもゲームを改造する体験ができるようになる
それはマインクラフトの開発者であるnotchがそういうゲーム開発に対する思想を持っていたからだ
私はnotchはシンプルなものを積み上げるのが好きなように思っている
ただ、jsdo.itだかに投稿していたソフトウェアレンダリングのコードは北欧のメガデモっぽさがあって、
読もう読もうと思って未だに読んでいないことを今思い出した
文章書き直す気がないまま、だらだら書いてみたが、読み返して自己分析するに、
まず、ゲーム開発でなくてもそうだが、
まず何かがあって、それをコピー改造した何かが生まれる、この連続で物事は進化していく
手塚治虫があって、それを高橋留美子がコピー改造して新しい漫画が生まれ、
次に若い漫画は高橋留美子の漫画をコピー改造して、また新しいものが生まれていく
開発する側も消費者もワクワクするのは、この改造して新しい何かが生まれる、守破離の離のインパクトであろう
黎明期はその離のインパクトが大きいが、どんどんそのインパクトは小さくなっていく
そして、ありふれたものが溢れるようになっていく
これが成熟期と言える
しかし、その成熟期に溢れるものは様式美であり、お約束であり、マンネリズムである
あの時代は3DOが先行したがコケたり、ドリキャスも登場してコケたり、面白い時代だったのである
ただ、今の時代にああいう群雄割拠というか、戦国時代というか、そういう活気がゲーム業界にあるようには思えない
VR元年って毎年言ってない？というツッコミは分からんでもないが、まだまだVRは伸びると思う
物体を触れないなんてのはまだまだVR市場が伸びる余地があるということだと思っている
あと、FPSみたいに走るゲームだと自分も走るのか？ということになるけど、うーん、ルームランナー方式はなあ…
あと、これも自分は専門でも何でもないので、
というか、この文章自体がダニング＝クルーガーなのは認めざるを得ないわけだけど、
敵というかNPCというか、今の時代だったら高度な汎用性のある人工知能をゲームでも実現するべきだと思うわけで、
そうすれば当然、同じセリフを延々と喋るドラクエの村人みたいなのは笑い話にしかならなくなる
ゲーム内に高度な人工知能が実現すれば、それらと会話したり、それらとマルチプレイと同様の感覚の連携プレイが可能になる
今までと同じことを繰り返しててもワクワクしないし、
[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ （写真=AP） 日本経済新聞
平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。
ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。
共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。
公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。
共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、
共通鍵では「平文→ 鍵→暗号文→鍵 →平文」と同じ鍵を使い、
公開鍵では「平文→ 公開鍵→暗号文→秘密鍵 →平文」と二種類の鍵を順に使う。
なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。
共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。
この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-Masuda Ultra Global Root CAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。
暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? HTTPS化しているウェブサービスでも、TLSをロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。
Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。
送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。
上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。
AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである。
では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか? 可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。
或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者が乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。
これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密の暗号鍵用乱数を得ることができる。
原始的なDiffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、
暗号A = XをA乗してYで割った余り、
暗号B = XをB乗してYで割った余り、
鍵AB = 暗号BをA乗してYで割った余り、
である。
なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。
ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。
この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End 暗号化」である。
E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。
ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。
これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若いITキッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。
実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。
https://twitter.com/mathmatsuri
問1
1/p+1/q=r/79
まずは右辺の分母の79が目を引く。通分して分母が79になることなんてあるのか？79は素数だから、pかqが79の倍数じゃないと分母は79にならないだろう。これは簡単に示せる。
両辺を79pq倍すると
79(p+q)=pqr
79は素数なのでp,q,rのいずれかが79の倍数。
r<79なのでp,qのいずれかが79の倍数。
p=79kもしくはq=79kとおきたいけれど、p≦qという制約が邪魔なので一度取り払ってしまう。最後にpとqの大小を比較すれば問題なし。とはいえqの方が大きくなってほしいのでp=79kではなくq=79kとおく(kは正の整数)。
1/p+1/79k=r/79
両辺を79倍すると
79/p+1/k=r …①
ここまでくるとだいぶ景色が変わって見える。左辺を通分することを考えるとこれが整数になる状況はだいぶ限られそう。kとpの関係をわかりやすくしたい。
両辺をp倍すると
79+p/k=rp
右辺は整数なので左辺も整数、よってp=mkとおける(mは正の整数)。代入・整理して
79+m=rmk
79=m(rk-1)
79は素数なのでm=1,79
i)
m=1のときp=kであり①に代入すると80k=rなのでkが80の約数であればいい。p=k=1,2,4,5,8,10,16,20,40,80 それぞれr=80,40,20,16,10,8,5,2,1となるがr<79なので(p,r)=(1,80)は不適。ちなみにq=79k=79pなので、pとqを入れ替えることなく題意のp≦qは満たされている。
ii)
m=79のときp=79kであり①に代入すると1/k+1/k=r
kr=2なので(k,r)=(1,2)(2,1) このときp=79,158。ちなみにq=79k=pなので、pとqを入れ替えることなく題意のp≦qは満たされている。
この2つをまとめてpを小さい順に並べると
p=2,4,5,8,10,16,20,40,79,80,158
よって求める値は25280
-------------------------------------------------------------------------------
扱う式が分数の足し算の形なので、なるべく通分の操作を意識した解答を作ってみました。mod処理で進めればもっと短くなるんでしょうが、「天から降ってきた解答」感がぬぐえなくなってしまうので。
ここでいう「ユークリッド幾何学」とは、座標空間、ベクトル、三角関数、微分積分などの解析的手法を用いないいわゆる総合幾何学のことです(*1)。2020年8月現在の高校数学のカリキュラムでいえば、「数学A」の「図形の性質」に該当する分野です。
ユークリッド幾何学が不要だと思う理由は単純明快で、何の役にも立たないからです。大学に入って、「補助線を引いて、相似な三角形を作って～」とか「コンパスと定規による作図」みたいなパズルゲームをやることは絶対にありません(*2)。これは常識で考えても分かると思います。たとえば工学の研究で、ある物体の弧長や面積などを測定しなければならないとして、ユークリッド幾何学の補助線パズルが適用できる多角形や円などしか測れないのでは話になりません。一方、座標空間、ベクトル、三角関数、微分積分などの手法は一般的な現象を記述する上で必ず必要になります。
もちろん、たとえば三角比を定義するには、「三角形の内角の和は180度である」とか「2角が等しい三角形は相似である」といった初等幾何学の性質が必要になります。そのようなものを全て廃止せよと言っているわけではありません。しかし、高校1年生で習う余弦定理:
を証明してしまえば、原理的にはユークリッド幾何学の問題は解けます。それ以降は、ユークリッド幾何学的な手法や問題設定にこだわる必要はないと思いますし、実際それで問題ありません。
現状、少なくない時間がユークリッド幾何学に費やされています。数学の1単元を占めているだけではなく、その他の単元にもユークリッド幾何学の発想に影響された例や問題が多く登場します。たとえば、複素平面において4点の共円条件や垂直二等分線を求めさせる問題など。そして最も労費されているのは生徒の自習時間です。以前よりマシになったとはいえ、大学入試等には技巧的な図形問題が出題されるため、受験生はその対策に多大な時間を費やしています。
高校数学では以下のような事項が重要だと思います。ユークリッド幾何学を学ばせている時間があったら、このような分野を優先的に修められるようにすべきです。
これらの分野は数学の手法としても非常に強力ですし、大学以降で数学を学ぶ際、現実的な問題を数学や物理の問題として正確に記述する際に必ず必要になります。仮にユークリッド幾何学が何らかの場面で応用されるとしても、微分積分などと同レベルに重要だと真剣に主張する人っていらっしゃるでしょうか？
ユークリッド幾何学を初等教育で教えるべきだとする根拠には、大雑把に言って以下の4つがあると思います。
まず①は明らかにおかしいです。ユークリッド幾何学に限らず、数学のあらゆる命題は証明されるべきものだからです。高校の教科書を読めば、相加平均・相乗平均の不等式、点と平面の距離の公式、三角関数の加法定理、微分のライプニッツ則や部分積分の公式など、どれも証明されています。そもそも、数学の問題はすべて証明問題です。たとえば、関数の極値問題は、単に微分が0になる点を計算するだけではなく、そこが実際に極値であるかそうでないかを定義や既知の性質に基づいて示す必要があります。したがって、ユークリッド幾何学だけが特に証明の考え方を学ぶのに有効だという理由はありません。
②もおかしいです。図形問題を扱うのはユークリッド幾何学だけではないからです。ベクトルや微分積分でも図形問題を扱います。たとえば、三角形の5心の存在や、チェバの定理、メネラウスの定理などはベクトルを用いても容易に示すことができます。また言うまでもなく、曲線の接線は微分で求めることができ、面積や体積は積分で求めることができます。また、ユークリッド幾何学の手法は問題ごとに巧い補助線などを発見しなければいけないのに対し、解析的な手法は一般に方針が立てやすく汎用的です。したがって、図形問題を扱うのにユークリッド幾何学の手法にこだわる理由はありません。
③は単なる個人の思い込みであり、科学的な根拠はありません。そもそも、数学教育の目的は「地頭」などを鍛えることではなく、「大学や実社会において必要な数学の素養を身につけること」のはずです。また、これも上ふたつと同様に「ユークリッド幾何学以外の数学では、『数学的直観』などは鍛えられないのか」という疑問に答えられておらず、ユークリッド幾何学を特別視する理由になっていません。
④もおかしいです。そもそも「歴史的に重要である」ことと「初等教育で教えるべき」という主張には何の関係もありません。歴史的に重要ならば教えるというなら、古代バビロニア、インド、中国などの数学は特に扱わないのはなぜでしょうか。もっと言えば、文字式や＋－×÷などの算術記号が使われ始めたのでさえ、数学史的に見ればごく最近のことですが、昔はそれらを使わなかったからといって、今でもそれらを使わずに数学を記述するべき理由があるでしょうか。
数学で重要なのはその内容であるはずです。ユークリッド幾何学を擁護する論者は、「（表面的に）計算問題に見えるか、証明問題に見えるか」のようなところに価値を置いて、一方が数学教育的に有意疑だと見なしているようですが、そんな分類に意味は無いと思います。
大昔は代数の計算や方程式の解法（に対応するもの）は作図問題に帰着していたようですが、現代でそれと同様の手法を取るべき理由は全くありません。記述する内容が同じであれば、多項式や初等解析のような洗練された方法・重要な結果を導きやすい方法を用いればよいに決まっています（数学史家は別として）。同様に、ユークリッド幾何学も、解析的な手法で解ければそれでよく、技巧的な補助線パズルなどに興じたり、公理的な方法にこだわる必要はありません。
たとえば、放物線は直線と点からの距離が等しい点の軌跡として定義することもできますが、初等教育で重要なのは明らかに2次関数のグラフとして現れるものです。放物線を離心率や円錐の断面などを用いて導入したところで、結局やるのは二次関数の増減問題なのですから、最初から2次関数のグラフとして導入するのは理にかなっています。数学教育の題材は「計算問題か証明問題か」などではなく、このような観点で取捨選択すべきです。
三角比などを学んだあともユークリッド幾何学を教えたり、解析的な手法では煩雑になるがユークリッド幾何学の範疇ではエレガントに解けるような問題を出して受験生を脅したりするのは、意味が無いと思います。それは、「掛ける数」と「掛けられる数」を区別したり、中学で連立方程式を学ぶのに小学生に鶴亀算を教えるのと同様に、無駄なことをしていると思います。
----
(*1)
現代数学では、n次元ベクトル空間R^n = Re_1⊕...⊕Re_nに
(e_i, e_j) = δ_i,j (クロネッカーのデルタ)
で内積が定義される空間上の幾何学はすべてユークリッド幾何学に分類されます。したがって、上にあげた座標空間、ベクトル、微分積分、一次変換なども敢えて分類すればユークリッド幾何学です。しかし、ここではその意味でのユークリッド幾何学が不要と言っているのではありません。飽くまでも、技巧的な補助線問題や、公理的な方法にこだわることが不要だと言っています。
(*2)
数学科の専門課程で学ぶガロア理論では、コンパスと定規による作図可能性が論じられますが、これは「作図問題にガロア理論が応用できる」というだけであり、「ガロア理論を学ぶのに作図の知識が必要」というわけではありません。
ほとんどのプログラミングスクールの何万円もする教材よりも、市販の数千円の参考書や、公式のチュートリアル（無料）の方がはるかに質が高いです。既にプログラミングができる人の参考書としてだけではなく、初学者の入門書としても、後者の方が適切です。
率直に言って、これだけ良質な情報がどこにいても手に入る時代に、独学でプログラミングを習得できない人は、もう諦めた方がいいと思います。プログラミングなんて別に生きる上で必要なスキルじゃないのですから。包丁持ったことすらない人が、何十万も払って料理習いたいと思うのかって話です。
これが最大の理由です。
まず現実的に、ちゃんとプログラミングができる人は、プログラミングスクールの講師になんかなりません。少なくともこの日記を書いている時点では。
レベルが低いというのは、実務上の話をしているのではなく、本当に素人に毛が生えた程度ということです。彼らのほとんどには、コンピュータサイエンスに関する体系的な知識がありませんし、そもそも基礎的な言語仕様すら把握していません。
これは「文字列を整数に変換する関数の名前がToInt()だったかParseInt()だったか覚えていない」などということではありません。そんなものは調べればいいわけです。彼らはもっと基礎的なこと、たとえば「浮動小数点数には誤差がある」とか、そういうレベルのことを理解していないのです。
だから彼らの「講義」は、間違いだらけであるか、言ってること自体は正しくても著しくピントがずれたものばかりです。昨日今日プログラミングを覚えたばかりの人と大して変わらない知識で、動くコードを自己流に解釈しているだけなのですから、当然そうなります。喩えるなら、中学の英語教師が中学英語の知識しかないようなものです。彼らはその範囲で「プログラミングを覚えるコツ」を編み出しています。
ということを教えたあとでも、標準入力に1以上の整数を入力して、1からその数までの和を出力しなさい、という問題が解けるのは全体の2割程度
残りの8割はおそらく、プログラミングができないのではなく、「問題文の日本語が正しく読めない」とか「プリントに書かれた通りにタイプできない」とかそういう病気なんだと思う
ぼく「こんにちは、ベン。ぼくはWashlet2000。便意はどう？」
面「超いい感じだよ。きみは？」
ぼ「ぼくも超いい感じさ」
面「それはよかった。わたしは部署AのToiletエンジニアで3年目なんだ。社内ツールを作ってるよ。Benki関係のツールで、超クールでExcitingなやつなんだ」
ぼ「それはクールだね」
ぼ「うん。ぼくは経験豊富な自宅警備員で…〇〇で貢献して…リーダー経験が……」
面「Cool（たぶん聴いてない）。じゃ、問題に入ろうか。わたしからの問題はね…」
ぼ「あ、はい」
ぼ「Unkの管理…」
面「そう。Unkってさ、知的生命体でしょ？あれを実現するの。『分裂』もあるから注意して」
ぼ「なるほど。えーと、それはHankeyみたいな普通のUnkだよね。えーとえーと」
面「…」
ぼ「えーと、そうだ、Unicodeとか決まってる？」
面「決まってるよ。U+1F4A9」
ぼ「うーん。じゃあUnkって何を保持したらいい？種類、個数？」
面「いい匂いだね。ここでは簡単のため、そうだね、個数だけにしようか」
ぼ「ならUnkの個数を持つ感じかな」
面「多分そうだね」
ぼ「えーと、そして、『分裂』のときに増える個数、『消滅』したかどうかを返すAPIが要る」
面「うん。あと新しいUnkが産声を上げたときも」
ぼ「そうだね。じゃあ内部的には、分裂した時の増殖個数を計算して、unkで現在の個数を管理する感じかな…」
面「それで行けそう？」
ぼ「待って。それで、APIはdivision()、roar()、isDead()でいい？」
面「うん、そうだね。とりあえずAPIはそれで良いよ」
ぼ「OK。あ、division()でもうそれ以上増えれないときには、どうする？」
面「それもいい匂いだ。そうだね、今の個数を返すようにしようか」
ぼ「あと何かあるかな…」
面「…」
ぼ「Unkだと、大腸菌を表示したり、そこからBenkiにジャンプしたりできるけど…」
面「あとで必要になるかもね」
ぼ「だよね。速度は…当然すべてO(1)でやらないといけない」
面「速いほうがいいね」
ぼ「あとは、えーと、Benkiクリアもあとで付けそうだな。まあこれは簡単か」
面「そうだね」
ぼ「まとめると、Unkの個数を整数のIntで持ち、unkで管理する。division()が呼ばれたら、分裂して、isDead()が呼ばれたら、生存の真偽を返す。分裂時にはroar()を呼び出して、Unkoooooooooo!×(増殖個数分)産声をあげる」
面「それで良さそう？」
ぼ「うーん、多分…なにかあるかな…」
面「『消滅』を何度かしたあと、『分裂』をしたらどうなる？」
ぼ「ん？……あ、だめだ！そうか、『消滅』『消滅』『分裂』で過去の個数うんこに増えてしまう！つまり、isDead()が真なら、その時のunkを初期化しないと！」
面「そう！ならどうする？」
ぼ「うーん。変数maxUnkを足せばいいかな。isDead()はmaxUnkより大きな場合は真。そのときはunkを初期化する」
面「なるほど。大丈夫そうだね」
ぼ「あとはOKかな？…よし、じゃあコード書いてみるよ（マーカーを手に取る）」
ぼ「まずクラス外観はこんな感じかな…（カキカキ）」
class Unk: def __init__(self): pass def division(self): pass def roar(self): pass def isDead(self): pass
面「ん？これ何の言語？」
ぼ「pyてょnだよ。ぼくはpyてょn使いなんだ（自己紹介で言ったけど…）」
面「Cool」
ぼ「そして、Unkの個数を整数で持つよ。名前はunkでいいか」
面「OK」
ぼ「それと有効な最大unk数を保持するmaxUnkが要るね」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): pass def roar(self): pass def isDead(self): pass
面「なんでunkを1で初期化したの？」
ぼ「これは『いまの個数』だから。初めは１つのUnkが存在するのを想定してる」
面「なるほど」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): self.unk = self.unk*2 def roar(self): print("Unkoooooooo! ×", self.unk//2) def isDead(self): return self.unk > self.maxUnk
ぼ「division()、roar()、isDead()も書くとこんな感じかな…」
面「増殖の計算は２倍したんだね」
ぼ「そう。ちょっと手動テストしてみるね…。えーとunkが無いときのdivision()、roar()は大丈夫そうかな…。初回のdivision()でunkのサイズが1になって…そのあとroar()したら…isDead()は……」
unk = Unk() while True: if not unk.isDead(): unk.division() unk.roar() else: break --- Unkoooooooo! × 1 Unkoooooooo! × 2 Unkoooooooo! × 4 Unkoooooooo! × 8 Unkoooooooo! × 16 Unkoooooooo! × 32 Unkoooooooo! × 64 Unkoooooooo! × 128 Unkoooooooo! × 256 Unkoooooooo! × 512 Unkoooooooo! × 1024
面「大丈夫そう？」
ぼ「うん…たぶん…」
面「じゃいくつか聞くよ」
