問題タブ [boost-graph]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - Boost adjacency_list で connected_components を実行します。ここで VertexList=listS
プロジェクトで Boost Graph Library を使用しており、次のように宣言されています。
グラフで connected_components を呼び出さなければならないまでは、うまくいっています。
VertexList=listS の場合、頂点のプロパティとして vertex_index がないことが問題のようです。これにより、connected_components で次のようなエラーが発生します。
/usr/local/include/boost-1_39/boost/property_map.hpp: メンバー関数内 'R boost::iterator_property_map::operator[](typename boost::property_traits::key_type) const [with RandomAccessIterator = __gnu_cxx::__normal_iterator 、IndexMap = boost::adj_list_vertex_property_map、boost::detail::error_property_not_found、const boost::detail::error_property_not_found&、boost::vertex_index_t>、T = boost::default_color_type、R = boost::default_color_type&]':
問題は、頂点のプロパティとして vertex_index を追加するにはどうすればよいかということです。
追加すると、add_vertex、remove_vertex などを呼び出すたびに、頂点ごとにこの情報を更新する必要があるということですか?
c++ - グラフVertexList=vecSの場合はremove_vertex
VertexList=vecSのブーストグラフがあります。
次に、頂点を反復処理して、特定のプロパティを持つ頂点を削除します。これどうやってするの?
問題は、remove_vertexを呼び出すたびに、頂点記述子とともにグラフ内の頂点へのイテレータが無効になることです。
graph - 非平面グラフの平面化アルゴリズム
非平面グラフの平面化のための一般的なアルゴリズムはありますか?
現在、無向グラフ用の直交平面レイアウト アルゴリズムを Boost ( Boost Graph Library ) に実装することを計画しています。BGL には、無向グラフ (Boyer-Myrvold Planarity Testing) の平面性をチェックする実装があり、このメソッドによって返される平面埋め込みを使用して直交レイアウトを行う予定です。
しかし、入力グラフが非平面の場合、どうすればよいかわかりません。このようなシナリオで返された Kuratowski サブグラフを使用して、グラフを平面にする必要があります。
「非平面グラフの平面化」を Google 検索すると、複数の研究論文が返されます。どこから始めればよいかわかりません。
c++ - dijkstra_shortest_paths でバンドルされたプロパティをウェイト マップとして使用する
おそらくこれはばかげた質問ですが、BGL を使用しようとしていますdijkstra_shortest_paths
。特に、Edge バンドル プロパティのフィールドをウェイトマップとして使用しようとしています。私の試みは現在、数十ページのコンパイラエラーにつながっているので、誰かが私を助ける方法を知っていることを願っています. これは基本的に私のコードがどのように見えるかです:
問題なくグラフを作成できますが、 を呼び出すと問題dijkstra_shortest_paths
が発生します。length
フィールドを利用したい。具体的には、次のような通話に適合するために必要なブードゥー教のブーストが何であるかを知りたいです。
length
そのような重みマップは、グラフの特定のエッジをプロパティの対応するフィールドに何らかの方法で関連付けます。これを行う簡単な方法があると確信していますが、BGL のドキュメントは非常にわかりにくいものです。この例がドキュメントのどこに記載されているか教えていただければ、私も大変嬉しく思います。
前もって感謝します!
multithreading - BGL同時読み取りアクセスの問題
いくつかのスレッドからBGLadjacency_listの頂点とエッジを反復処理する必要があります。グラフが大きい(mutex ..)場合、これを行うのに効率的な方法はどれですか?
BGLメソッドはリエントラント呼び出しをサポートしていませんか?
c++ - Boostグラフライブラリを使用した幅優先探索中に祖先頂点にアクセスするにはどうすればよいですか?
Boost Graph Libraryに含まれている幅優先探索アルゴリズムを使用して、独自のバージョンの連結成分検出を作成しようとしています。祖先(現在の頂点の検出につながる頂点)頂点にアクセスする必要があります。現在の頂点のコンポーネント番号を設定するための訪問者のdiscover_vertexコールバック。とにかく簡単にできますか?
c++ - BGL を使用したスパニング ツリーの作成
BGL グラフがあり、BGL を使用してスパニング ツリーを作成したいと考えています。
指定された頂点から始めて、この頂点に接続するグラフに最短のエッジを追加したいと考えています。そこから先は、これまでに存在するグラフにつながる最短の辺を常に選びたいと思っています。
そのため、サイクルがないというスパニング ツリーの基準を維持しながら、すべての新しいエッジが既にグラフに接続されている必要があるという制約を追加したいと考えています。
これを手動で行うのはそれほど難しくありません。しかし、私は BGL について何かを学びたいので、どのアルゴリズムが自分の問題に最も適しているかを知りたいと思っています。
c++ - std::vector プロパティの要素のみを BGL アルゴリズムに渡す
複数のエッジの重み付けが保存されているグラフがあります
重み付けはすべてベクトルにプッシュされます。
prim_minimum_spanning_tree()
ここで、ベクトルの最初の要素を重みとして使用して、グラフで関数を呼び出したいと思います。
正しい関数呼び出しを実行するにはどうすればよいですか?
c++ - ブーストグラフを使用して障害物回避のための潜在的なフィールド/深さ優先法を実装できますか?
グラフ内のすべてのノードにポテンシャルを割り当て、このポテンシャルを下げようとする障害物回避アルゴリズムをMatlabに実装しました(パスプランの目標はグローバル最小値にあります)。現在、極小値が表示される可能性があるため、(グローバル)計画にはこれらから抜け出す方法が必要です。私はこの戦略を使用して、すでにアクセスしたノードから到達可能なオープンノードのリストを作成しました。次に可能性が最も低いオープンノードにアクセスします。
これをC++で実装したいのですが、BoostGraphにそのようなアルゴリズムがすでにあるのではないかと思います。そうでない場合-アルゴリズムを自分で作成する必要がある場合、このライブラリを使用する利点はありますか。また、グラフが大きすぎて隣接リスト/エッジリストとしてメモリに保存できないため、独自のグラフクラスを作成する必要があります。
アドバイスをいただければ幸いです。
c++ - Boost::BGLテンプレート<->クラスの循環依存を解決するには?
Boost Graphics Library の adjacency-list の使用に問題があります。循環依存の問題のようです: クラス A を使用するテンプレートの typedef T があります。さらに、A は型 T のオブジェクトへのポインターを格納します。コンパイラは、T が型に名前を付けていないことを教えてくれます。
以下は、より具体的なファイルの抜粋です。
この依存関係/包含順序の問題を解決するにはどうすればよいですか?
別の編集: edge_descriptor の型は int のようなプリミティブ型である可能性があるという考えがありました。Lane の edge_descriptors を単純な int 変数に置き換えることができ、tie.hpp 内の graphdefinitions.hpp のインクルードを削除できたので、これで問題は解決したはずです。残念ながら、私の考えはひどいものでした。別の解決策を見つけなければなりません。Edge_descriptor タイプは理由があるようです...