アルゴリズムの全てに共通してできる解き方ってなんですか？？あと勉強法を教えてください

Question

アルゴリズムの全てに共通してできる解き方ってなんですか？？あと勉強法を教えてください

Answer 1

そもそも前提が違う。

プログラミングっていうのは、「こう書けばこう動く」じゃないです。

「プログラムは魔法でもなんでもなく、人間が現実世界でやっていることを逐一指示されながら処理しているだけの代物である」です。

そもそも機械が生まれた理由はご存知ですか?

そう、「軍事目的」です。

弾道計算や暗号解読とかのためです。

でも一応暗号解読とかは人間がやろうと思えばできますよね。
たとえばシーザー暗号であれば1字ずらすとかなので。

ですが暗号方式やその時代によってはたかだか「おはよう」程度の4文字程度の内容ですら1カ月とかそういう風に解読するだけでかかる。

現実的じゃないですね。

なので、機械に任せましょう。っていう発想になった。
これが最初だと言われているようです。

しかし、機械は0と1からなる機械語(machine language) しか認識できません。

1101110000000011011110111100000...

的なものです。人間にはきついですね。

なのでこれを人間の言語に近い言語としてアセンブラとかが開発され、
さらにアセンブラとかの問題点を解消するためにC言語とかの構造化プログラミングっていうのが開発された。
さらにC言語とかの問題点を解決するために……とやっていったのです。

よって、「人間が手作業でやっていることを逐一指示されながら処理しているだけの代物である」です。

つまり、言い換えると「現実世界でならどうするか」を考えるのです。

たとえば、

[例題Q]
整数型の配列arr (要素数10) がある。
この中に8 という数字があるか調べるプログラムを組め。

であれば、

[言い換えQ]
中身の見えない箱(例: びっくり箱) がある。
その箱には数字が書かれた商品が入っている。
(イメージ的には「出店での射的の景品」)
そういう箱が横一列にずらーっと並んでいる。
この箱の列から 8という数字が書かれた商品があるか調べよ。

のような依頼かなんかですね。

例題Qでは、「え!!? どうしよっ!!!? わかんなぃぃぃ!!!!」となっても、
言い換えQでは、「フツーにひと箱ずつ見ていけばいいんじゃね?」ってなりますよね。

ひと箱ずつ見ていく:
C言語とかならfor文、フローチャートならループ系のアレ

8かどうか:
C言語とかならif文、フローチャートなら分岐系のアレ

で出来そうですね。

後はこれを組み立てるだけ。

結果が合わないなら修正していけばいいだけだし。

基本的にはこの発想。

そして、基本情報技術者試験とかに出るやつだと、コードなりフローチャートなりを読んで穴埋めするタイプだった気がします。

その場合は、この逆をやる。

コードの場合は、「この行が何をしているか」をコメントとかにする。

int i;
int a = 0;
for( i = 0; i < 10; i++ ){
___a += 10;
}

と言うコードなら、

// if文で使う?
int i;
// 変数a を宣言し、0で初期化
int a = 0;
// i が0から10まで(= 10回) 繰り返す
for( i = 0; i < 10; i++ ){
___// 現在の a に10を追加する(足す)
___a += 10;
}

のようにする。

コメントが書けない場合は頭の中やノートとかに書く。

そして、それを現実世界でやってみる。あるいは脳内でシミュレーションしてみる。

上記のように変数とかが出てくるなら、変数に実際の値を入れてみるとかしてシミュレーションする。

そしてデータの変化や処理(ロジック)を追う。

そうすれば、何をしているかとか、何が足りないのかが見えてくることもある。

ただし、動的計画法やらbit全探索やら幅優先探索・高さ優先探索とかが必要な場合や、特定の分野(化学とか)とかの知識が必要な場合はその手の知識が必要だが。

Answer 2

アルゴリズムってそもそも解くものでは無いような……？
解いたものがアルゴリズムです。
日本語では「解法」って言うくらいですから。

たぶん、必要なのは、読む力と、組み立てる力の方だと思います。
読む力は既存のアルゴリズムを理解するために必要です。

読むのは比較的簡単です。
基本的には頭から順番に、流れのとおりに追いかけてゆけば良いです。(トレース)
その中で、一塊が独立した意味を持っていそうであれば、それを一纏めにして「意味」に転換します。
そうすると、考える必要のある要素が減って、読む速度が上がります。
たいていプログラムは、ネストした多層構造になってるので、
そういった意味のブロック単位で、どんどん1つの意味にまとめて、
処理の次元をより高次な方へと引き上げてゆきます。
そうすると、コード的にはシンプルになりますし、全体の動きも理解しやすくなります。

さらに、これは、次のステップである組み立て方にも応用できます。
アルゴリズムを構築する時には、対象となる問題を、まずは抽象度の高い高次のステップに分解します。
そして、その個々について、一つ一つ処理を分解し、具体化してゆきます。
まさに、さっきの読む力のときに使った意味化、抽象化の逆回しです。
そうやって分解し尽くし、具象化し尽くした所には、コードが自然と現れます。

ここらへんの手順は、全てのプログラミングに共通する手法です。
(プログラミング=アルゴリズムの構築であると思えば当然ですが)

Answer 3

>アルゴリズムの全てに共通してできる解き方

存在しないです

＊＊＊

勉強法ですが、問題文と答えを眺めます

毎日１０～２０程度、数百問を数カ月、あたりがよいです

問題文を１分眺めて答えが浮かばないのであれば、答えを眺めるのがよいです

それを１０００題ほどやると、アルゴリズムができるようになります

Answer 4

アルゴリズムは、解法として、なにかに特化したものだと思っています。
なので、広く汎用的なものはアルゴリズムとは呼ばないかと。

で、アルゴリズムって暗記モノっぽくって、あんま私は興味がないのですが、ソートのアルゴリズムは何種類かあって、勉強にはちょうどよいかもね。

「ソート アルゴリズム」で検索すると、まとめたサイトが出てくるかとおもいますよ。