タグ付けされた質問 「data-structures」

私はHaskellを学び、演習としてバイナリツリーを作成しています。通常の二分木を作成したので、それを自己均衡化に適応させたいと思います。そう： どちらが最も効率的ですか？ どちらが最も簡単に実装できますか？ 最もよく使用されるのはどれですか？ しかし、決定的に、どちらをお勧めしますか？ これは議論の余地があるため、ここに属していると思います。

18 haskell  functional-programming  data-structures  binary-tree 

この記事では、データクラスは「コード臭」であると主張しています。理由： 新しく作成されたクラスに含まれるパブリックフィールドが少数（そしておそらく少数のゲッター/セッターさえ）である場合、これは通常のことです。しかし、オブジェクトの真の力は、データに動作タイプまたは操作を含めることができることです。 オブジェクトにデータのみが含まれているのはなぜ間違っているのですか？クラスの中心的な責任がデータを表すことである場合、データを操作するメソッドを追加して単一責任原則を破らないでしょうか？

18 data-structures  code-smell 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 昨年は閉店しました。 私は実際のプロジェクトで多態性がどのように使用されているかを理解しようとしていますAnimalが、method を持つ親クラスと、speak()このメソッドをオーバーライドする多くの子クラスを持つ古典的な例（またはそれに似たもの）しか見つけることができません次のように、speak()任意の子オブジェクトでメソッドを呼び出すことができます。 Animal animal; animal = dog; animal.speak(); animal = cat; animal.speak();

17 object-oriented  data-structures  polymorphism 

TL; DR-最適なデータ構造を設計して、測定単位内の単位を定義しようとしています。 A Unit of measureは、本質的ににvalue関連付けられた（または数量）unitです。 SIユニットには7つのベースまたはディメンションがあります。すなわち：長さ、質量、時間、電流、温度、物質の量（モル）、および光度。 これは十分に簡単ですが、多くの派生ユニットと頻繁に使用するレートがあります。結合されたユニットの例はNewton：でkg * m / s^2あり、レートの例はですtons / hr。 暗黙のユニットに大きく依存するアプリケーションがあります。変数または列名に単位を埋め込みます。しかし、異なる単位で測定単位を指定する必要がある場合、これは問題を引き起こします。はい、入力および表示時に値を変換できますが、これにより、独自のクラス内にカプセル化する多くのオーバーヘッドコードが生成されます。 コードプレックスやその他の共同作業環境には多くのソリューションがあります。プロジェクトのライセンスは同意できますが、プロジェクト自体は通常、非常に軽量または重すぎます。「ちょうどいい」というユニコーンを追いかけています。 理想的には、次のようなものを使用して新しい測定単位を定義できます。 UOM myUom1 =新しいUOM（10、ボルト）; UOM myUom2 = new UOM（43.2、Newtons）; もちろん、クライアントのニーズに基づいて、ImperialユニットとSIユニットを組み合わせて使用​​します。 また、このユニットの構造を将来のデータベーステーブルと同期させて、データ内で同じ程度の一貫性を提供する必要があります。 測定単位クラスを作成するために使用する必要がある単位、派生単位、およびレートを定義する最良の方法は何ですか？1つ以上の列挙型を使用していることはわかりましたが、他の開発者にとってはイライラする可能性があります。単一の列挙型は200以上のエントリで巨大になりますが、複数の列挙型はSIと帝国のユニットに基づいて混乱し、ユニット自体の分類に基づいた追加の内訳があります。 私の懸念のいくつかを示す列挙型の例： myUnits.Volt myUnits.Newton myUnits.meter SIUnit.meter ImpUnit.foot DrvdUnit.Newton DrvdUnitSI.Newton DrvdUnitImp.FtLbs 使用中のユニットのセットはかなり明確に定義されており、有限のスペースです。クライアントから需要がある場合、新しい派生ユニットまたはレートを拡張および追加する機能が必要です。このプロジェクトはC＃で作成されていますが、より広範な設計の側面は複数の言語に適用できると思います。 私が調べたライブラリの1つでは、文字列を介したユニットの自由形式の入力が可能です。次に、UOMクラスは文字列を解析し、それに応じてスロットを割り当てました。このアプローチの課題は、正しい文字列形式が何であるかを開発者に考えさせ、記憶させることです。そして、コンストラクターで渡される文字列を検証するためにコード内に追加のチェックを追加しないと、ランタイムエラー/例外のリスクが発生します。 別のライブラリは、開発者が作業しなければならないクラスを本質的に多く作成しました。同等のUOMとともに、DerivedUnitなどRateUnitを提供しました。基本的に、コードは、私たちが解決しようとしている問題に対して非常に複雑でした。そのライブラリは基本的にany：anyの組み合わせ（ユニットの世界では合法です）を許可しますが、可能なすべての組み合わせを許可しないことで問題の範囲を広げることができます（コードを簡素化します）。 他のライブラリはとてつもなくシンプルで、たとえば演算子のオーバーロードも考慮していませんでした。 さらに、誤った変換（たとえば：ボルトからメートル）の試みについても心配していません。この時点でこのレベルでアクセスできるのは開発者だけであり、これらのタイプの間違いから保護する必要は必ずしもありません。

17 c#  design  naming  data-structures 

純粋に関数型またはほぼ純粋に関数型の言語は、不変であり、関数型プログラミングのステートレススタイルによく適合するため、永続的なデータ構造の恩恵を受けます。 ただし、Javaのような（状態ベース、OOP）言語の永続データ構造のライブラリが時々見られます。永続的なデータ構造を支持してよく聞かれる主張は、不変であるためスレッドセーフであるということです。 ただし、永続データ構造がスレッドセーフである理由は、1つのスレッドが永続コレクションに要素を「追加」すると、操作は元の要素に要素が追加された新しいコレクションを返すためです。したがって、他のスレッドは元のコレクションを参照します。もちろん、2つのコレクションは多くの内部状態を共有しています。そのため、これらの永続的な構造は効率的です。 しかし、スレッドごとにデータの状態が異なるため、永続データ構造だけでは、あるスレッドが他のスレッドに見える変更を行うシナリオを処理するのに十分ではないように思われます。このためには、アトム、リファレンス、ソフトウェアトランザクションメモリ、またはクラシックロックや同期メカニズムなどのデバイスを使用する必要があるようです。 それでは、なぜPDSの不変性が「スレッドセーフ」にとって有益であると宣伝されているのでしょうか。PDSが同期、または並行性の問題の解決に役立つ実際の例はありますか？または、PDSは、関数型プログラミングスタイルをサポートするオブジェクトへのステートレスインターフェイスを提供する単なる方法ですか？

17 functional-programming  data-structures  multithreading  concurrency 

スキップリストやブルームフィルターなどの確率的データ構造が非常に有用であると聞いたことがありますが、一般的にそれらについて詳しく知りたいと思います。Cormen et al。のレベルの主題に関する標準的な参照はありますか？

17 data-structures 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Javaの2番目のコースを受講しています。データ構造に入ります。リンクされたリストで割り当てを行い、スタックになりました。リンクリストで苦労しました。スタックは少しトラブルを引き起こしましたが、はるかに簡単でした。 これらのアルゴリズムとデータ構造で苦労することを心配する必要がありますか？本当に把握していないように感じます。

17 algorithms  data-structures 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 ラルフウィリアムゴスパーJrによる次のような引用があります。 データ構造は単なる愚かなプログラミング言語です。 これはどういう意味ですか？残念ながら、Googleで見つけることができるのは、文脈のない引用自体の容赦ないコピー/貼り付けだけです。

16 data-structures  quotations 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 この質問の発端は、私が業界のいくつかの仲間の開発者と行った議論から生まれました。 多くの場所で、プロジェクトマネージャーは複雑なデータ構造について警戒しており、通常は標準ライブラリ/パッケージからすぐに使用できるものをすべて主張しています。一般的な考え方は、パフォーマンスが大幅に妨げられない限り、すでに利用可能なものを組み合わせて使用​​するようなものです。これにより、コードベースをシンプルに保つことができます。これは、外交官にとっては、「私たちは高い離職率を持ち、採用する新しいものはそれほど良くない」ことを意味します。 したがって、CSジャンキー向けのブルームフィルターやスキップリスト、スプレイツリーはありません。そこで質問があります（もう一度）：あなたがオフィスで使用したり使用したりした最も複雑なデータ構造は何ですか？ 現実世界のソフトウェアがどれほど優れているか/洗練されているかの感覚をつかむのに役立ちます。

16 data-structures 

ブルームフィルターは、Intが一定の時間で99％の確実性でセットに含まれているかどうかを判断できると考えると、本当に見栄えがします。ただし、ハッシュも同様です。ただし、ハッシュでは、ほとんどの場合、メモリに1回しかアクセスしません。ブルームフィルターでは、完全に離れた場所でリクエストごとに約7回アクセスする必要があるため、リクエストごとに複数のキャッシュミスが発生します。 何か不足していますか？

16 data-structures 

現在、多くの（おそらくほとんどの）データベースアプリケーションは、Bツリーとバリエーションを使用してデータを格納しています。これは、このデータ構造がハードディスクの読み取り、書き込み、およびシーク操作を最適化するためです（これらの操作は、全体的な効率において重要な役割を果たしますデータベース）。 ただし、ソリッドステートドライブ（SSD）は従来のハードディスク（HDD）を完全に置き換える必要がありますが、Bツリーとバリエーションは時代遅れになり、ダイレクトアクセスメモリでより効率的に動作するデータ構造の余地ができます。もしそうなら、それらの構造は何になりますか？（例：ハッシュテーブル、AVLツリー）

15 database  data-structures 

スケーラブルブルームフィルターを読んでいて、構成ブルームフィルターがいっぱいになるたびに、より大きなサイズの新しいブルームフィルターが追加される方法を理解できませんでした。 最初に作成されたフィルターの設定ビットに寄与した要素は、存在を検索できません。おそらく私はこれを理解していないのでしょうか？ 基本的なブルームフィルターは理解できます。ただし、動的ブルームフィルターに頭を包むことはできません。

15 data-structures  hashing 

宿題の割り当てでは、スキップリストの仕組みを理解する必要があります。 私はもう2年以上プログラミングをしています（実際にはそれほど長くないことを知っています）。スキップリストを聞いたことがありません。 私が見つけることができるすべてのガイドを見てきましたが、それらがどのように機能するのかまだほとんど理解していません。実装例をコードレビューで検索しても、レビューは1つしか見つかりませんでした。そして、それは完全な実装でさえありません。コースが提供するサンプル実装を確認しましたが、それは絶対にひどいものです。適切なメソッドの欠如と1文字の変数名の間で、どのように機能するのか見当がつきません。 スキップリストはどのように機能しますか？より高度なデータ構造を理解するにはスキップリストの知識が必要ですか？

14 data-structures 

インライン、テキストのメタデータを保存する必要があるアプリケーションを開発しています。つまり、長いテキストがあり、特定の単語またはテキストの文に関連するメタデータを保存するとします。 この情報を保存する最良の方法は何でしょうか？ 私が最初に考えたのは、テキストを検索するときに解析されるMarkdown構文を含めることでした。次のようなもの： Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam __nonummy nibh__[@note this sounds really funny latin] euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. これにより、私が考えることができる2つの問題が発生します。 比較的小さいのは、前述の構文が偶然にも前述のテキストにあった場合、構文解析を混乱させる可能性があるということです。 最も重要なのは、このメタデータがテキスト自体とは別に維持されないことです。 クエリ、統計、並べ替えなどの個別の方法でそれらを使用できるように、これらのメタデータが格納されている異なるDBテーブルなど、このデータを保持する個別のデータ構造が必要です。 編集：回答者が答えを削除したので、この最初の概念を拡張した実用的な提案だったので、ここに彼の提案を追加するのが良いと思います。ポスターは似た構文を使用するが、これにメタデータをリンクすることが示唆PRIMARY KEYのmetadataデータベーステーブル。 このように見えるもの： Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam __nonummy nibh__[15432] euismod tincidunt …

14 data-structures  concepts  separation-of-concerns  markup 

私は通常、グラフを二重リンクリストとして実装しますが、これは私の経験ではかなりスペース効率が悪いです.k個の隣人にk個のポインタ/参照が必要なので、無向グラフの場合、数学が正しければリスト内に〜2k個の隣人リンクがあります。スペースを節約するより良い方法はありますか？グラフが方向付けられている場合、いくつかのリンクが特異になる可能性があることを知っていますが、これをもっとうまくやる方法はありますか？

14 data-structures