アルゴリズムについて理解したい。

Question

タイトル通りなのですが、

アルゴリズムを理解したい！

と思っているのですが、どのようにして理解していけばよいのか、また何が分かれば理解したことになるのか といった疑問です。

例えば、基本的なリニアサーチ、バブルソート などのアルゴリズムは、コードを書くことも出来ますし、内容も理解していると思います。

様々なアルゴリズムを暗記していく事が理解した事になるのでしょうか？

何かアドバイス等いただければ幸いです。

Comments

[coco_bauer]

アルゴリズムを理解できたら、何をしたいのですか？　サーチやソートのアルゴリズムに精通したからといって、ディープラーニングが判るようにはなりません。　目標（自分がしたいこと）に向かってゆくのに必要となる機能が何かを調べ上げて、その機能を実現するのに必要なアルゴリズムを勉強していけば、目標は近づいてくるはずです。

[Lhankor_Mhy]

補足願います。

「コードを書くことも出来ますし、内容も理解している」とのこと、それならば「そのアルゴリズムは理解している」と言っていいのではないかと思うのですが、「何か不足があるのではないか？」とお考えなのでしょうか？

それとも個別のアルゴリズムの話ではなくて、全てのアルゴリズムを理解したことになる「アルゴリズムの真髄」みたいなものが存在してそこに至るにはどうしたらよいのか、みたいな話でしょうか？

[hayataka2049]

これまでどんな感じで勉強してきたのでしょうか？　「ちゃんとした教科書を買って読み込んでください」で回答が完結する可能性はそうとう高いと思っています（アルゴリズムのおすすめ書籍は検索すれば出てくるし、過去質問もあったと思うので、実は質問を立てるまでもない）。

[sazi]

アルゴリズムと言われているのが漠然としているんだと思います。
フレームワークなどについて調べると良いのかもしれません。

Answer 1

追記修正依頼や他の回答を見ればわかりますが、ベテランエンジニアたちは「アルゴリズムを理解するには？」という問いに対して「なぜ？」という疑問符を浮かべています。

つまりこれは、エンジニアとして働くためにソートアルゴリズムを学ぶことがそれほど重要でないことを意味します。

プログラミングをするに当たって書かれたソースを読み解くこと、つまり他人がコードとして著したアルゴリズムを理解することは大変重要なことのはずですが、それなのにこのような疑問符が浮かぶのには理由があります。

理由の一つ目は、「車輪の再発明は不要」ということです。

有名なソートアルゴリズムは既に誰かがコード化しています。つまり、これを自分でコード化する必要は無く、何度もテストされ、使用に耐えてきたライブラリ内の信頼のおけるコードを使うのが、実用上最も優れた方法だということです。

理由の二つ目は、それを暗記することがスキルアップに繋がるとは限らないということです。

先ほど述べたように、学習期間が終わった後は、ソートを自分で実装する機会などほぼありません。つまり、ライブラリの開発など特殊な業務でなければ必用のない死にスキルで、よほど本腰を入れて育てなければ仕事の役には立たないということです。

そのため、「なぜ学びたいか」が重要になってきます。

目標があり、その目標を果たすためであれば、あるいはアルゴリズムをコレクションすることも必要になることもあるでしょう。

もし「目標はあるが、なぜアルゴリズムを学びたいか自分でもわからない」ということであれば、このステップはこのくらいにして目標達成の糧となる他のスキルを伸ばすのが良いでしょうし、「趣味だから」と言うのであれば好きにしたらいいと思います。

学習過程でアルゴリズムを学ぶこと自体については「プログラミング特有の考え方に慣れる」「コードを読み解く訓練をする」などの利点がありますが、記憶することの利点は非常に少ないと思います。ググれば出てくるので。

Answer 2

アルゴリズムは、プログラミングの世界では

• プログラミングや言語といった道具を使って
• どういう方法で作業を行うかの手順

でしかありません。その種類は用途や目的で多数ありますが、あなたの質問は「洗濯のやり方を理解したいと思いますが、手洗いや二層式洗濯機の使い方も含めて暗記した方がいいですか？」というような質問のようなものです。

もちろん、世界中のそうした手順を調査分類するようなお仕事であればそれもアリかもしれませんが、多分違いますよね？ むしろ、「自分が住んでいる家、家族構成や生活パターンに応じた洗濯のやり方を、今有る道具や時間を使ってどうやって行うか」が重要で、世の中の一般的なやり方を把握、暗記したところでおそらくあなたがこの先直面する課題や仕事、趣味の内容にはあまり有益にはならないのではないかとおもいます。アルゴリズムとはそうした作業の手順を明確にして繰り返し実施できる「手順書」のようにまとめたもの。なので「何の、どういう用途のアルゴリズムか」ということを明確にせずに「アルゴリズムを理解したい」というのはナンセンスです。

もちろん、自分が必要とするアルゴリズムを考案したり目的を達成するために世の中に既にある一般的なアルゴリズムがそのまま適用出来ることもあれば、参考になることもあるので暗記が無意味だとは言いませんが、そもそものご質問内容自体があまり意味の無い質問であることを認識された上で、そもそもご自分が「なんでそう思われたのか？」について考えてみられた上で、より具体的な目的や意図を記載されて再度質問されればもう少し具体的で実のあるアドバイスが返ってくるかも知れませんね。

検討してみてください。

Answer 3

アルゴリズムはあくまで先人たちの知恵です。

確かにソートやサーチができますが、それはすでに言語やライブラリが提供しています。
よって、自分で組むことはまれ。

C言語ですら、qsort関数と呼ばれる、ソートする関数が用意されています。
なので自分で実装することはまれ。

ではなぜ学ぶのか。

発想を豊かにするためです。

例えば、配列 arr に 0～10の数字が入っているとして、その中に 8 があるかどうか調べてください。
と言われると、アルゴリズムを知らないと、
かなりマシな部類でもforで最初から最後まで調べる。これがリニアサーチ。
(最悪、丸投げ)
でも、先人たちは「バイナリサーチ」「二分探索木」なるものを考え出しています。

これらの二分探索木は木構造が常に小さい値が右(場合によっては左)に来ることを利用して検索する方法。

バイナリサーチは辞書を引く時のように、目星をつけてそこより後か前かを考えて、ずらしていく方法。

この発想の転換が重要。

アルゴリズムを暗記している・していない ではなく、「先人たちはどのようにして解決していったのか」を学ぶ。

OOPを取り入れている言語でのデザインパターンも大体同じ。(あちらはオブジェクトの運営方法。)

例えば、成功を収めている、ビ〇・ゲ〇ツ氏やスティー〇・ジョ〇ズ氏らの成功体験を聞いて、実際にそれと同じようにできますか?

むしろ、環境が違えば役に立ちません。

例えばすでに金があって人脈もあるが、あとは頭だけ...の場合と、頭はあるが金がない...とかそういう状況で違いますし、
アメリカと日本でも相当違う。

それと一緒です。

実際に使える・使えないでいえば、「使えない」と考えたほうがいいです。

ただ、完全に無駄ではないです。

いろんな話を聞いて、「いろんな人がいるんだなぁ」「この人はこういう風に切り抜けてきたんだぁ」っていう感じでしょうか。

つ 考え?

---

[追記0]

(追記: この部分の追記はどちらかといえばオブジェクト関係ですが、データ構造とアルゴリズムにもかかっているので書きました)

(追記の追記: Zuishinさんからご指摘をいただきました。見当違いなので、打消し線で削除します。)

あ、そうそう。忘れてましたが、「データ構造」はC++以降の言語にはすでに備わっています。
(ライブラリ側だろうけど。)
確かに名称は若干違ったり、PythonとかVBAとかみたいな言語だと、
C言語とかだと配列として扱われるのが「リスト構造」だったり...と差があるようですが、
何かしらのもので提供されています。
C++でいえば、

~~ベクター: std::vector
リスト構造: std::list
スタック構造: std::stack
~~
~~という具合に。
だから不要といえば不要。
でも、「データ構造とアルゴリズム」を学ぶことで使い分けがわかるようになりますよ。
例えば、初心者に多いだろうと思うものが、
「std::vectorとstd::listの違いって何? 同じように使えるけど?」
という感じでしょうか。
でもデータ構造とアルゴリズムがわかっているなら、
~~

ベクター: 動的配列。最後尾に追加していくのは得意だが、途中( (N-1)≦i≧0 ) に追加したり削除したりするのは不得意。できなくもないが、さらに別のベクターを用意して...みたいな無駄が出てくる。
また、ランダムアクセスが得意。
リスト: リスト構造。C言語で言えば自身のポインタを持った構造体でつなげていく方式。
よって、途中( (N-1)≦i≧0 )の追加や削除が得意。ただし、ランダムアクセスが苦手。

というのが解れば、自分がやりたい処理から考えることができる。
もしランダムアクセスが不要だけど途中追加や削除を頻繁に行うならリスト構造( C++でいうならstd::list ) 、途中追加とかは不要だけどランダムアクセスをすることがあるならベクター( C++でいうならstd::vector )...
という風に使い分けができる。
そういう、「弱みや強みを理解し、使い分けができる」っていう利点もあるっちゃあるね。

Comments

[Zuishin]

追記部分で書かれているのはデータ構造ではなくオブジェクトですね。

[BeatStar]

あ、そうです。
一応、ただ、データ構造とアルゴリズムにあるので、書きました。
(勘違いされそうなので、修正しますね...)

[Zuishin]

データ構造自体は C++ で始まったものではありません。

「アルゴリズム＋データ構造＝プログラム」がこの追記の根底にあるんだと思いますが、オブジェクト指向では「データ構造を隠蔽」し、「ポリモーフィズムによってアルゴリズムすら隠蔽」しています。また「インターフェース」というアルゴリズムともデータ構造とも無関係な新しい概念も導入されており、「アルゴリズムとデータ構造」だけでは語れなくなってきました。

C++ はご存知の通りオブジェクト指向を取り入れており、ここで例示されているのはオブジェクトなので、データ構造の例としてはいささか不適切と言えると思います。

[BeatStar]

あー、なるほど...
わかりました。削除しておきます。(追記の部分)

[Zuishin]

いえ、私の二つ目のコメントは BeatStar さんのコメントを読む前に書いた物で、「C++ 以降」というところから何か誤解があるのではないかという確認で、削除するほど不適切というわけでは……言葉足らずですみません。

[BeatStar]

あー、そうなんですね...
まっ、いいか。

Answer 4

... 様々なアルゴリズムを暗記していく事が理解した事になるのでしょうか？ ...

暗記は重要ではありません。
すでにある手法はそれを探して,実際のコードにおそ仕込めば済みます。
グラフィック関係では アルゴリズム集の本もあります。
ps://www.amazon.co.jp/dp/B003Z9K11Q Graphics Gems

アルゴリズムよりデザインパターンを勉強したほうが良いかもしれません。
https://www.amazon.co.jp/dp/B015R0M8W0/Game Programming Patterns ソフトウェア開発の問題解決メニュー
https://www.amazon.co.jp/dp/B0126HZGP8
Amazon Web Servicesクラウドデザインパターン設計ガイド

落とし込んだコードの質を評価するための知識も必要です。
確率、離散数学,情報理論...

Answer 5

名前と用途・特性だけ知っていれば(実装できなくても)十分かと思います.

Answer 6

なにをしたいのかよーわかりませんが、とりあえずは暗記していけばいいんじゃないでしょうか。
それでなにかいいことがあるかはわかりませんが。。