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

ソフトウェアアプリケーション内でのデータの効率的な保存と表現に関する質問。

2
地図データを保存するための理想的なデータ構造ですか?
私はインタビューテストでこれを尋ねられました。私はテストで大丈夫でしたが、この質問に答えるのに十分な知識がありませんでした。データをすばやく照会するために使用できるデータ構造を知りたいです。 基本的には、ある種のデータ構造に格納された道路セクション(ライン、ポイントで構成される)があるという考えです。どの道路セクション(またはポイント)がポイント(半径)から特定の距離内にあるかをすばやく照会する必要があります。

2
安らかなサービスで順序付きリストリソースを設計するにはどうすればよいですか?
私はこの同じ問題に何度も遭遇しましたが、私が本当に最適だと感じた解決策は見つかりませんでした。 アプリで言うと、順序付けられたリストがあり、ユーザーがドラッグアンドドロップなどでその順序を変更できるようにします。順序の変更を保持したい場合。どのようにモデル化しますか? 順序付きリストリソースの安らかなサービスを設計するにはどうすればよいですか? 具体的には、どのように私が設計する必要がありますlistし、item安らかなリソースのモデルを?私が見た最も一般的なデザインは、またはプロパティitemを持つエンティティです。私が聞いた別のアプローチは、アイテムの二重リンクリストです。orderposition データベースへの書き込みが多すぎず、クライアントの更新と読み取りが一般に高速なアプローチとは何ですか?エンドポイントはどのように公開されるべきですか?

3
リンクリストには常にテールポインターが必要ですか?
私の理解... 利点: 最後に挿入すると、O(N)ではなくO(1)になります。 リストが二重リンクリストの場合、末尾から削除することもO(N)ではなくO(1)です。 不利益: わずかな量の4-8バイトの余分なメモリを占有します。 実装者は、テールを追跡する必要があります。 これらの長所と短所を見ると、リンクリストがテールポインターの使用を避ける理由がわかりません。私が欠けているものはありますか?

2
有機化合物を表すためにどのデータ構造を使用しますか?
分子を表すために使用できる優れたデータ構造はありますか? すべての原子を頂点にすることでグラフとして表現できると考えていましたが、有機化合物には多くの炭素と水素が含まれているのが一般的です。どのように番号を付けますか?分子を表現する良い方法はありますが、同時に効率的な.contains()方法がありますか? これの最も基本的な用途の1つは、化合物にカルボニル基、ベンジル水素、またはベンゼン環が含まれているかどうかを確認することです。

2
個別の連鎖にバイナリ検索ツリーを使用してハッシュテーブルを高速化することは可能ですか?
バイナリ検索ツリーを使用してハッシュテーブルを実装し、O(n)(リンクリストを使用)からO(log n)(BSTを使用)への個別チェーンプロセスの検索の複雑さを軽減します。これを行うことはできますか?ソリューションが段階的なロジックの実装であれば、理解しやすくなります。 ハッシュテーブル(個別のチェーンを使用してビルド)の検索時間を短縮したいのですが、同時に挿入時間を増やしたくありません。私のプロジェクトでは、ハッシュ関数を変更して衝突を減らすことはできません。しかし、スケーラビリティのために、衝突が発生しています。私は回避策を見つけようとしていますので、衝突が発生した場合に何らかの方法で最高のアクセスと時間を挿入できるようにしています...つまり、アルゴリズム全体を再構築するよりも物の現在の状態を管理します。パンアウトしない場合は、再構築する必要があります。アイデアはありますか?

2
選択的に非表示にできるノードとエッジ間に許可された複数のエッジを持つグラフを表現する方法
理想的で仮想化されたネットワークの使用をモデル化するためにどのようなデータ構造を使用するかを考えています。 私のシナリオでは、互いに敵対的な多数のユーザーが、潜在的な接続がすべてわかっているコンピューターのネットワークを形成しようとしています。ただし、あるユーザーが接続する必要があるコンピューターは、別のユーザーが接続する必要があるコンピューターとは異なる場合があります。ユーザー1はコンピューターA、B、Dを接続する必要があり、ユーザー2はコンピューターB、C、Eを接続する必要がある場合があります。 NCTM Graph Creatorの助けを借りて生成された画像 このコアは、ノードがコンピューターを表し、エッジがイーサネットケーブルを表す、無向の循環グラフになると思います。ただし、シナリオの性質上、隣接リストと隣接行列を除外するいくつかの珍しい機能があります(少なくとも、重要な変更はありません)。 エッジは使用が制限される場合があります。つまり、あるユーザーが特定のネットワーク接続を取得した場合、他のユーザーはその接続を使用できません この例では、緑のユーザーはコンピューターAに接続できない可能性がありますが、赤のユーザーはBをEに接続していますが、それらの間に直接リンクはありません 場合によっては、ノードの特定のペアが複数のエッジで接続されます この例では、DからEまでの2本の独立したケーブルがあるため、緑と青のユーザーは両方ともこれらのマシンを直接接続できました。ただし、赤はそのような接続を確立できなくなりました 2台のコンピューターが複数のケーブルで接続されている場合、各ユーザーが所有するケーブルは1本のみです このグラフでは、次のようないくつかの操作を行う必要があります。 特定のユーザーに対して特定のコンピューターのペアが接続されているかどうかを判断する 特定のユーザーがターゲットコンピューターに接続するための最適なパスを特定する 特定のユーザーの最大遅延コンピューター接続(つまり、分岐のない最長パス)を識別する 最初に考えたのは、単純にすべてのエッジのコレクションを作成することでしたが、検索にはひどいものです。今考えられる最善の方法は、隣接リストを変更して、リスト内の各アイテムにエッジの長さだけでなく、コストと現在の所有者も含まれるようにすることです。これは賢明なアプローチですか?スペースが問題にならない場合、単一のグラフではなく、グラフの複数のコピー(ユーザーごとに1つ)を作成するのが妥当でしょうか?

2
Pythonがハッシュテーブルを使用してdictを実装しますが、Red-Black Treeは使用しないのはなぜですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 Pythonがハッシュテーブルを使用してdictを実装しますが、Red-Black Treeは使用しないのはなぜですか? キーは何ですか?パフォーマンス?

3
アーキテクチャ的に言えば、MicrosoftのEntity Frameworkなどのデータベース抽象化レイヤーは、別のデータアクセスレイヤーの必要性を無効にしますか?
そうだった 長年にわたって、ソフトウェアソリューションを次のように整理してきました。 データにアクセスするビジネスを抽象化するデータアクセス層(DAL) ビジネスルールをデータセットに適用したり、認証を処理したりするためのビジネスロジックレイヤー(BLL) ユーティリティ(Util)は、私が長年にわたって構築してきた一般的なユーティリティメソッドの単なるライブラリです。 もちろん、Web、デスクトップ、モバイルなど何でもよいプレゼンテーション層。 今のやり方 過去4年ほどの間、私はMicrosoftのEntity Framework(私は主に.NET開発者です)を使用しており、Entity Frameworkが既に行っているという事実のために、DALがクリーンよりも厄介になっていることに気付きました私のDALが使っていた仕事:データベースに対してCRUDを実行するビジネスを抽象化します。 したがって、通常、次のようなメソッドのコレクションを持つDALになります。 public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 次に、BLLでは、このメソッドは次のように使用されます。 public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } BLLには通常、さらに数行のロジックが適用されるため、これはもちろん簡単な例ですが、そのような限られた範囲でDALを維持するのは少し過剰に思えます。 DALを放棄して、単にBLLメソッドを次のように記述する方が良いと思いませんか。 public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

5
関数型プログラミングのデータ構造
私は現在LISP(特にSchemeとClojure)で遊んでいますが、関数型プログラミング言語で典型的なデータ構造がどのように扱われるのか疑問に思っています。 たとえば、グラフパス検索アルゴリズムを使用して問題を解決したいとします。そのグラフを関数型プログラミング言語(主にLISPに適用できる純粋な関数型に興味がある)で表現するにはどうすればよいでしょうか?グラフを完全に忘れて、他の方法で問題を解決できますか?

5
このキャッシュ戦略に使用するデータ構造は何ですか?
私は.NET 4.0アプリケーションに取り組んでいます。これは、doubleを返す2つのdoubleに対してかなり高価な計算を実行します。この計算は、数千のアイテムのそれぞれに対して実行されます。これらの計算はTask、スレッドプールスレッドで実行されます。 いくつかの予備テストでは、同じ計算が繰り返し実行されることが示されているため、n個の結果をキャッシュしたいと思います。キャッシュがいっぱいになったら、最近使用したアイテムのうち、最も使用頻度の低いアイテムを破棄したいと思います。(編集:キャッシュがいっぱいになったときので、私は少なくとも、しばしばを実現することは、意味がないと私は1つが最も頻繁に使用されると、すぐに新しい結果が計算され、次回に置き換えられるであろうと、新たに計算されたものと結果を置き換えますキャッシュに追加されました) これを実装するために、私はDictionary<Input, double>(Input2つの入力double値を格納するミニクラスになる)を使用して、入力とキャッシュされた結果を格納することを考えていました。ただし、最後に結果がいつ使用されたかを追跡する必要もあります。このためには、キャッシュがいっぱいになったときに辞書から結果を削除するために必要な情報を格納する2番目のコレクションが必要だと思います。このリストを常にソートしておくと、パフォーマンスに悪影響が出るのではないかと心配しています。 これを行うためのより良い(つまりよりパフォーマンスの高い)方法、または私が知らない一般的なデータ構造さえありますか?ソリューションの最適性を判断するには、どのようなことをプロファイリング/測定する必要がありますか?

4
なぜMS Data Accessのストーリーがそんなに壊れているのですか?データアクセスの性質ですか、それともMSですか?
このStackOverflowの質問では、「Microsoft.Data.Objectsはどこで入手できますか」と尋ねられます。 答えは、おそらくEntity Framework 4のCTP4(コードファースト)リリースであることが判明しましたが、そこには多くの推測があります。含む System.Data エンティティフレームワーク Microsoft.ApplicationBlocks.Data Microsoft.Practices.EnterpriseLibrary.Data 10年前に誰かがDAO、RDO、ADOを入手した可能性があるために同様の質問をした場合。 これは単なる獣の性質なのか、それともMSなのか。 このパターンは他のベンダーでも発生しますか?基本データアクセス戦略はどこでラップまたは変更されますか?

2
不変データを持つ言語で二重にリンクされたデータ構造または循環データ構造に操作を実装するための回避策
Haskellでグラフを作成してローカル操作を行う方法を学びたいのですが、問題はHaskellに固有のものではなく、グラフの代わりに二重リンクリストを検討することもできます。 質問: 主に不変のデータ構造(Haskell、Clojureなど)をサポートおよび推奨する言語で、二重リンクリスト(または他の二重リンクまたは循環データ構造)とその操作を実装する慣用的または推奨される方法は何ですか? ?特に、言語で正式に禁止されているインプレース更新の使用方法は? 二重にリンクされたリストでローカル操作を実行した場合(アイテムが挿入された場合など)、言語の遅延により、リスト全体をすぐにコピーする必要がない場合があることは容易に想像できます。ただし、リストは二重にリンクされているため、1か所で変更された場合、リストの新しいバージョンで古いノードを使用することはできず、何らかの方法でマーク、コピー、ガベージコレクションを行う必要があります。 。リストの更新されたコピーのみを使用する場合、これらは明らかに冗長な操作ですが、リストのサイズに比例した「オーバーヘッド」が追加されます。 これは、そのようなタスクでは不変データが単に不適切であり、可変データを「ネイティブ」でサポートしていない関数型宣言言語は、命令型言語ほど優れていないことを意味しますか?または、トリッキーな回避策はありますか? PS私はインターネットでこの主題に関するいくつかの記事やプレゼンテーションを見つけましたが、それらをフォローするのに苦労しましたが、この質問への答えは1段落以上、そしておそらく図を取るべきではないと思います...つまり、もしあればこの問題に対する「機能的な」解決策はありません。答えは「Cを使用する」でしょう。ある場合、それはどれほど複雑になる可能性がありますか? 関連する質問 「関数型プログラミングのデータ構造」。非効率的な代替手段の代わりにインプレース更新を使用することについての私の特定の質問はそこでは議論されていません。 「永続的データ構造の内部変異」。ここでは、不特定の言語での低レベルの実装に重点が置かれているようですが、私の質問は、言語(関数型またはその他)の正しい選択と、関数型言語で可能な慣用的な解決策についてです。 関連する引用 純粋に関数型のプログラミング言語では、多くのアルゴリズムを非常に簡潔に表現できますが、その場で更新可能な状態が重要な役割を果たすと思われるアルゴリズムがいくつかあります。これらのアルゴリズムの場合、更新可能な状態がない純粋に関数型の言語は本質的に非効率的であるように見えます([Ponder、McGeer and Ng、1988])。 -John LaunchburyおよびSimon Peyton Jones、レイジー機能状態スレッド(1994)、John LaunchburyおよびSimon Peyton Jones、Haskell州(1995)。これらの論文STでは、Haskellのモナディック型コンストラクタを紹介しています。

1
「この一連の材料でどのレシピを作成できるか」に答えるためのアルゴリズム/データ構造
正式には、s(U、Q)= { V | V ∈ UとV ⊆ Q } U、Q、およびVがすべてのセットを表し、Uは、より具体的には、セットの集合を表します。例として、Uはクックブックのさまざまなレシピに必要な材料のセット(セット)であり、Qは材料のセットを表し、Vはそれらの材料で作成できるレシピを表します。クエリs(U、Q)「これらの成分で何が作れるのか」という質問に対応します 私が探しているインデックスというデータ表現であるU、それはの効率的なクエリをサポートするような方法で、Sを(U、Qは)ここで、QとのすべてのメンバーUは、一般的に、すべてのメンバーの組合に比べて小さくなりますU。さらに、Uを効率的に更新できるようにしたい(たとえば、レシピの追加または削除)。 私はこの問題をよく理解する必要があると思わずにはいられませんが、名前やリファレンスを見つけることができませんでした。これを効率的に解決するための戦略、または私がそれについてもっと読むことができる場所を誰かが知っていますか? 解決策について考える限り、私が持っていたのは、集合Uの決定木を構築することでした。ツリーの各ノードで、「成分リストにxが含まれていますか?」という質問 回答によって排除されるUのメンバーの数を最大化するためにxを選択して尋ねられます。Uが更新され、この決定木は、正しい結果を見つけるために必要な質問の数を最小限にするために再バランスする必要があります。もう1つの考えは、n次元のブール「オクトリー」(nは一意の成分の数)のようなものでUを表すことです。 「これらの成分でどんなレシピが作れるの?」クックブック内の(必要な成分のセット)レシピのデカルト積を、ある成分のパワーセットで取得し、両方の要素が等しいペアの結果として順序付けられたペアをフィルタリングすることで応答できますが、これは効率的な解決策、そして私が求めているのは、この種の操作を最適化する方法です。効率的になるようにSQLでこれをどのように構成し、これを効率的にするためにSQLで何ができるのでしょうか。 私はレシピと食材のセットのクックブックのイラストを使用していますが、「レシピ」の数と「食材」の数は非常に多くなると予想します(それぞれ数十万まで)。ただし、食材の数は特定のレシピでは、特定の材料セットの材料の数は比較的少なくなります(通常、「レシピ」の場合は約10-50、一般的な「材料セット」の場合は約100)。さらに、最も一般的な操作はクエリs(U、Q)であるため、最も最適なはずです。これはまた、すべてのレシピをチェックしたり、すべての材料を操作したりする必要があるブルートフォースアルゴリズムは、それだけでは望ましくないほど遅くなることを意味します。巧妙なキャッシングで、


3
ハッシュの聖書とは何ですか?
ハッシュとハッシュに関するコーメンのような参照はありますか?この特定の構造は、何らかの理由で私のCS教育ではほとんど注目されていませんが、どこにでもあるように見えるので、もっと学びたいと思います。私はコーメンがそれをカバーしていることを知っていますが、もっと専門的で詳細なものを探しています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.