実際の状況で使用した最も複雑なデータ構造は何ですか？[閉まっている]

この質問の発端は、私が業界のいくつかの仲間の開発者と行った議論から生まれました。

多くの場所で、プロジェクトマネージャーは複雑なデータ構造について警戒しており、通常は標準ライブラリ/パッケージからすぐに使用できるものをすべて主張しています。一般的な考え方は、パフォーマンスが大幅に妨げられない限り、すでに利用可能なものを組み合わせて使用​​するようなものです。これにより、コードベースをシンプルに保つことができます。これは、外交官にとっては、「私たちは高い離職率を持ち、採用する新しいものはそれほど良くない」ことを意味します。

したがって、CSジャンキー向けのブルームフィルターやスキップリスト、スプレイツリーはありません。そこで質問があります（もう一度）：あなたがオフィスで使用したり使用したりした最も複雑なデータ構造は何ですか？

現実世界のソフトウェアがどれほど優れているか/洗練されているかの感覚をつかむのに役立ちます。

ルックアップにスキップリストを使用しました。私が働いている場所には標準的な実装があり、誰もがそれを使用することが奨励されています。IPアドレスを効率的に保存および取得するために、パトリシアの試みを使用しました。繰り返しますが、実装はすでに存在していました。

私はJava開発者です。Java Collection Frameworkは私の90％のデータ構造の問題を解決でき、他の10％は努力が必要です。専門家によって書かれた洗練された標準ライブラリを本当に理解すれば、ほとんどの場合に役立つと思います。

現実の世界では、複雑なデータ構造を維持することは困難です。コードの混乱を避けるため、トラブルをいくつかの小さなコードに分けます。それぞれの小さな問題は、Java Collection Frameworkによって解決できます。おそらく、このソリューションは最もスマートではありません（より多くのメモリと低速が必要です）が、機能し、保守が容易です。それはトレードオフです。

複雑なデータ構造を記述する必要がある場合は、教科書を取り上げます:)

私が仕事で使用した最も複雑なデータ構造はトライでした。しかし、それは20年前です。

産業用ソフトウェア開発の問題は、ほとんどの産業用プログラマーがコンピューターサイエンス（CompSci）卒業生ではないことです。したがって、CompSciの平均的な卒業生が当たり前のことと考えている手法は、パンとバターのプログラマーが維持するのが難しすぎると考えられています。

業界におけるCompSciの一般的な知識の欠如は深刻な問題です。たとえば、！（a！= 5 && b！= 3）やa == 5 ||などの表現を理解していない、会ったソフトウェア開発者の数を失いました。b == 3は論理的に同等です。デモルガンの定理を適用する方法を知っている人は誰でも、これらの式が論理的に同等であることを認識することができます。CompSci以外の卒業生のほとんどは、DeMorganの定理を聞いたことがない。実質的なコードベースを調査すると、負の論理部分式を否定する式の多くの出現が見つかります。否定された負の論理部分式を含むコードの可読性は、ほとんどの場合、これらの式を非否定形式に変換することにより改善されます。

私はかつて、イベントベースのシミュレーション用にカレンダーキュー（O（1）優先度キュー）を作成しました。プロファイリングでは、既存のヒープがボトルネックであることが示されました。

また、約80000状態の有限状態マシンを含む製品をリリースしました。それを生成するためのコードは、控えめに言っても少々面倒でした。

ずっと前、銀河系で...アセンブラーのRTOSでKnuthの「バディバッファー」を使用するチームで働いていました。

また、1024 x 1024の世界で256世代のConwayのGame of Life。

特別なものはあまり使用していません。最初から二重にリンクされたリストになります。

あまりエキサイティングではありませんが、他の構造を使用しました。しかし、あなたの質問は最初から言った。

財務データの一般的なリストを含むハッシュテーブルのツリー-質問すらしません。時々私はカウボーイだったらいいのにと思う。ああ、星空の下でのシンプルな生活...

数独ソルバーのダンシングリンクアルゴリズムのために、循環二重リンクリスト構造を最初から記述する必要がありました。ルービックキューブを設計するように感じました。構造全体は基本的にリストのリストであり、各ノードは他の4つのノードを指しています。

かつて、特殊なキャッシュに重み付きパス長ツリーを使用しました。それは楽しかった。また、malloc()交換用に独自のヒープ管理ルーチンを作成しましたが、多くの人がそれを行っています。

それを考えて、私が最初から行った最も「複雑な」データ構造は、二重にリンクされたリストに基づいた要素のネットワークをモデル化することです。しかし、私がシステムレベルのプログラミングを行っていたのは、何年も前のことです。

最近では、空想的なデータ構造はほとんど作成していません。そのほとんどは、テーブルに何を入れるかを決定するデータベースで発生します。おそらく、事前に計算された値、または関連するレコードのIDで、不要な検索を避けるための迅速な検索が可能です。

個人的には、目の前のタスクが手段を定義しているということです。使用しないのに、なぜいくつかのエキゾチックなデータ構造を利用しようと努力するのですか？そして、私が実際の応用プログラミングのほとんどで言うことができるなら、おそらく車輪を再発明する必要はないでしょう。

優先キューはカウントされますか？これは、私が書いたほぼすべてのリアルタイムアプリケーションで発生します。最近になって標準Javaライブラリの一部になりました（Java 1.5）。

それ以外は、私が本当に望んでいた、ライブラリから引き出すことができなかった複雑なものは考えられません。私はそれを止めさせませんが、なぜライブラリを含めるにはあまりにもエキゾチックなデータ構造が必要なのか疑問に思うでしょう。自分で作成する前に、トライまたはブルームフィルター、またはスキップリストの既存のオープンソース実装を間違いなく探します。

一般に、ライブラリバージョンが存在しないほど難解なカスタムデータ構造の構築と保守のコストは、そこから得られるパフォーマンス上の利点を上回る可能性が高いことをマネージャーに同意します。プロファイリングを通じて、単純なライブラリ構造がパフォーマンスの大幅な低下を引き起こしていることを示してから、先に進んでそれらを空想的なもので最適化してもらいたいと思います。原則として、エンジニアリングサイクルよりもプロセッササイクルを購入する方が安価だからです。