データ構造の優れたオンラインコースを探していましたが、Googleはアルゴリズムコースの結果も返すことがわかりました。

このコースでは、分割統治法、グラフアルゴリズム、実用的なデータ構造（ヒープ、ハッシュテーブル、検索ツリー）、ランダム化アルゴリズムなど、アルゴリズム設計のいくつかの基本原則を学び ます。[ソース]

そして

このクラスの終わりまでに、グラフやその他の重要なデータ構造用の新しいアルゴリズムを考案し 、これらのアルゴリズムの効率を評価するために必要な重要な概念を理解できます。[ソース]

そして

このコースでは、計算問題の数学的モデリングについて紹介します。これらの問題を解決するために使用される一般的なアルゴリズム、アルゴリズムパラダイム、およびデータ構造をカバーしています。[ソース]

私の質問は次のとおりです。アルゴリズムとデータ構造は密接にリンクしているので、一緒に理解しなければならないのですか、それとも他のトピックよりも基礎的なトピックですか？

編集：この質問を終了する投票者のために、この質問を改善する理由と方法を教えてください。適切な質問をすることを学ぶことは、教育プロセスの一部です。

あらゆる種類の混合物が存在します。アルゴリズムに関連付けられていないデータ構造、アルゴリズム（実際の）データ構造を必要としないアルゴリズムがありますが、ほとんどの場合、2つは1つのパッケージに入っています。

編集： @Dovalが正しく指摘したように、データ構造自体には操作が関連付けられていません。データ構造とアルゴリズムを組み合わせるという行為は、抽象データ型を形成します。

アルゴリズムのないデータ構造

たとえば、適切に呼び出される2次元座標を格納するためのデータ構造を考えPointます。そこのポイントのために行われるアルゴリズムの面で多くのものは何もありません、それは本当にのためだけのコンテナであるxとy値。もちろん、このデータ構造を与えると、その上にあらゆる種類のアルゴリズム（距離計算、凸包、what-have-you）を追加できるようになります。

多くのデータ構造を考えることができます。これは、個々のデータの単なる蓄積です。これらは実際には頻繁に発生しますが、良い教材にはなりません。なぜなら、そこから学習するものは何もないからです。上記のPoint例の後に、というすばらしいデータ構造を提供するとPoint3D、3次元空間でも同じことができますか？）

（実際の）データ構造のないアルゴリズム

明らかに、すべての興味深いアルゴリズムには整数やブール値などのプリミティブデータ型が必要であり、このコンテキストではそれらをデータ構造と見なしたくないためです。上記と同様に、これらのアルゴリズムは通常、かなり単純なものです。特に、それらは通常、データ構造（次のセクションを参照）に入るため、複雑な状態にはなりません。

そのようなアルゴリズムの例は、2つの数値の最大公約数を計算することです。gcdのEuklidのアルゴリズムは、実際には2つの整数を保持して操作するだけです。

物事がより面白くなり始めると、すぐに抽象データ型の世界に入ります。たとえば、エラトステネスのふるいは配列に基づいています。ここで、配列がまだプリミティブであるかどうかについて議論することができます。実際、整数がまだデータ構造でないかどうかを議論することができます。どちらにしても、孤立した存在を受け入れたとしても、データ構造なしで完全に存在するアルゴリズムはかなり退屈です。

データ構造と組み合わせたアルゴリズム、別名抽象データ型

現在、これらは興味深いものですが、2つの非常に異なる理由があります。通常、これらには2つの方向からアプローチできます。最初にデータ構造、または最初にアルゴリズムです。

抽象データ型は、データ構造+アルゴリズム/操作の組み合わせによって定義されますが、多くの場合、どちらか一方に注目して表示し、もう一方をイネーブラーと見なします。

データ構造、次にアルゴリズム

使用するのはかなり簡単ですが、内部で動作させるために多少複雑なアルゴリズムを使用する抽象データ型に遭遇します。たとえば、a HashMapは簡単に使用できますが、気の利いたハッシュ関数を使用し、内部でのハッシュ衝突を処理します。しかし、ユーザーとしての観点からは、あなたのために何かをするものではなく、あなたのためにデータを保持するものとしてそれを気にします。

以下の最後のグループとは対照的に、これらのデータ構造はユーザーをこれらのアルゴリズムにさらしません。HashMap内部ハッシュ関数を使用できるようにするために、内部ハッシュ関数について知る必要も、気にする必要もありません。（しかし、これを効果的に使用するには、これらのことを知りたいかもしれません;）

アルゴリズム、次にデータ構造

もう一方の方向は、単純に使用できるようにしたいが、意図したとおりに機能させるために内部的にデータ構造を必要とするアルゴリズムがあることを意味します。例としては、バイナリ空間分割（BSP）アルゴリズムがありますPoint。これは、特定のクエリポイントに最も近い大きなポイントセットから2次元を単純に求めることができます。ただし、実際にアルゴリズムを作成するには、内部にツリー構造（および距離計算などの追加のアルゴリズム）が必要です。

一般に、このグループのアルゴリズムは、内部状態の表現に関連するデータ構造を使用していると言えます。私は、このアルゴリズムのグループが最も多様であり、この一般的なスキームに適合する多くの異なるアルゴリズムを見つけると主張します。視点に関しては、これらは私たちのために何か（f.ex.ソートなど）を実行し、データ保持部分についてはあまり気にしないので、これらは興味深いと考えています。

密接に関連するデータ構造とアルゴリズム

最後に、データ構造があります。これは、それらに直接対応するアルゴリズムと非常に密接に関連しています。典型的な例はバイナリツリーです。これを使用すると、意味のある何かをしたいときに、ツリーウォークアルゴリズムのトピックが強制されます（深さ優先、幅優先）。

これらの場合、結果の抽象データ型のビューの焦点を頻繁に変更します。時々、ツリーの構造を気にし、数分後に検索操作を実行できることを気にしてから、ノードを削除したり、構造がその後どのように見えるかをすぐに気にしたりします。これはすべて上記の他のセクションにも当てはまりますが、たとえば、データをに/から保存しMapたり、リンクしたリストを並べ替えたりする場合など、頭の中で最も重要なことではありません。

多くの場合、データ構造はアルゴリズムの詳細に影響します。このため、この2つはしばしば密接に関連しています。

たとえば、芝生を切るためのアルゴリズムを考えてみましょう。芝生の刈り方は、実際の芝生の構造に影響される可能性があります。密集した郊外の小さな家に住んでいて、芝生が面積数メートルの小さな長方形である場合は、トラクター/乗用草刈り機の代わりに押し草刈り機で芝生を切ることをお勧めします。芝生に多くの平地の牧草地が含まれる場合は、プッシュモアではなくライディングモアをお勧めします（ただし、いずれかのモアは最終的に仕事を終えることができます）。芝生に大きな平らな面積の土地があり、いくつかの小さな丘といくつかの樹木がある場合、乗馬芝刈り機とプッシュ芝刈り機、または他の草の両方を含む芝生を切断するためのより興味深いアルゴリズムを開発することができます切削技術。

最終的には、データの構造は、アルゴリズムの開発方法（または使用するアルゴリズム）の決定に大きな影響を与える可能性があります。このため、2つのトピックはしばしば密接に関連しています。

逆もまた同様です。時には、アルゴリズムをサポートするために開発するデータ構造に（少なくともコンピューティングの開始時に）影響を与えるアルゴリズムを使用します。たとえば、配列リストからリンクリストのアイデアに進み、最終的には、迅速な検索を可能にする順序付きリストを格納するためのBSTに進みます。