Algorithm

アルゴリズム: プログラミングは,函数という名のピースを組み合わせてコンピュータに計算の手順を与える作業であった. ここで,この組み合わせ方をアルゴリズムと呼ぶ. 直角三角形の斜辺の長さの例ならば,与えられた引数aの2乗と,引数bの2乗を足して,その平方根をとると斜辺の長さが求められる,ということである. この組み合わせ方は1通りである. aとbを先に足してから2乗して平方根をとっても,それは斜辺の長さにはならない. aとbをそれぞれ先に2乗してから足しあわせ平方根を取る,この組み合わせの順番であるからこそ,斜辺の長さを求められるのであった. 考えてみれば当然のことと思われるかもしれない. この斜辺を求める計算の,函数の組み合わせ順序,これがアルゴリズムである.

隣辺a,bから,その直角三角形の斜辺の長さを求めるアルゴリズム

aとbをそれぞれ2乗する.

↓

上の結果を足し合わせる.

↓

上の結果の平方根を取る.

↓

それが斜辺の長さ.

上に示したアルゴリズムを"アルゴリズムP"と名付けよう. 隣辺の長さから斜辺の長さを求めたいのならば,アルゴリズムPを使うこととなる. "車輪を再発明する必要はない",すなわち既に存在しているものをわざわざ一からつくり上げても特に意味は無い,という言葉がある通り,すでに計算方法が存在していれば,その方法を流用すれば良いという考え方がアルゴリズムにもある. 斜辺の長さを求めたければアルゴリズムPの順序を真似すれば良い. このように,よく使われる計算手順はアルゴリズムとしてまとめられているのだ. 積分を計算したいならばあのアルゴリズムを,スパムメールを検出したければあのアルゴリズムを,というようにこの手順通りに動作するプログラムをつくるだけでやりたいことを実現することが出来る. しかしそうなると,わざわざアルゴリズムにせず,その処理を実行できるプログラムをつくっておければ良いではないかと考えられる. 確かにその通りである. しかし,プログラミングに用いる"言語"にも様々な種類が存在するのだ. また,この文書を読んでいる今も,新たなプログラミング言語が誕生しようとしている. アルゴリズムとしてではなく,あるひとつのプログラミング言語にて計算手順が実現されていると,他の言語でその計算手順を再現したくなった時,言語間の翻訳作業が必要となってしまう. 移植元と移植先の言語,両方の文法を知らなくてはならなくなる. これでは効率が悪い. そこで,より一般的なアルゴリズムという形にまとめているのだ. プログラミング言語に依存しないように計算手順をまとめたもの. それこそアルゴリズムである.

ただ,よく使う計算手順をある言語にてプログラムしたものが無いわけではない. それらはライブラリと呼ばれ,必要な時に使えるようにまとめられている. 例えば次のようなライブラリを用意しておいたとする.

• f(a, b) = (a + b)
• g(n) = (n * n)
• i(n) = (√n)

ライブラリは函数の集まりである. 上のライブラリを"ライブラリP"と名付けよう. このライブラリを読み込むだけで,ライブラリ内にあるいかなる函数も利用することが出来るようになる. 斜辺の長さを求めたければ,"ライブラリP"を読みこめば,プログラムの作成が容易になる. なぜなら,必要な函数たちが,このライブラリPに既に定義されているからだ. このライブラリの機能が無かったなら,どうなっていただろうか？ 使いたい度に使いたい函数を一から組み上げて行かねばならない. これは無駄な"車輪の再発明"だ. ライブラリのおかげで,車輪を一度発明したら,あとはそれを使ってより高度な製品をつくれるようになるのだ. パズルゲームの例を挙げれば,ライブラリは拡張ピースの集まりとも言えるだろう. ただし当然ながら,ライブラリは書かれたプログラミング言語にしか利用できない. 他の言語で同じ函数を使いたければ,アルゴリズムを見てその函数を一から組み上げてゆく必要がある. 結局,ライブラリがあってもアルゴリズムは必要なのである.

6054237702942082475 https://www.storange.jp/2013/07/algorithm.html https://www.storange.jp/2013/07/algorithm.html Algorithm 2013-07-19T09:30:00+09:00 https://www.storange.jp/2013/07/algorithm.html Hideyuki Tabata Hideyuki Tabata 200 200 72 72