Jgrapht: 他のヒープ？

私は、本質的に誰かの実装をコピーして貼り付けることを意味する「移植」はあまり好きではありません。 異なるプログラミング言語の場合、もちろんすべての著作権と作者のメモが保持され、ライセンスが尊重されていると仮定すると、それは理にかなっているかもしれません。

jheapsはJavaで記述されているため、Mavenの依存関係を使用してヒープを使用できます。

@ jsichi 、 @ jkinableこれ

• ヒープ用の優れたインターフェースがあります。つまり、ヒープを簡単に交換できます。 これは、アルゴリズムのユーザーが実装を交換できるようにすることもできることを意味します。
• また、 monotoneヒープ（たとえば、ダブルキーの基数ヒープ）が含まれているため、ダイクストラが大幅に高速化されます。

特にオーサーシップを考えると、依存関係を追加しても問題ありません:)これは、 GenericFibonacciHeapを削除し、最終的にはFibonacciHeapを削除できることを意味すると思います。

迅速な返信ありがとうございます！ 私には完全に理にかなっています！

https://github.com/jgrapht/jgrapht/pull/595がマージされる前にこれを実行したいと思い

誰かがPRを送信してjgrapht-coreのpom.xmlに依存関係を追加し、依存関係を行使するためにGenericFibonacciHeapの既存の使用法を少なくとも1つ置き換える必要があります。 新しい依存関係を文書化するために更新する必要のある他のドキュメントファイルとパッケージファイルもいくつかあります。

最大重みの2部マッチングアルゴリズムで実行するか、 @ Toptachamannに＃595で直接実行させます。

この依存関係をjgrapht-corepomに追加し、ペアリングヒープを使用しました。 最大重みの2部マッチングアルゴリズムを変更する必要がありますか？

独自のPRでそれを行うのが最善です。そうすれば、それを単独でマージでき、

@jsichiは本当に必要ですか？ 変更は非常に小さいようで、すでに花のprでテストされています。 その理由を考慮して、依存関係を追加します。

それは本当にfibをペアに置き換えることがどれだけの作業であるかに依存します。 それが多くの仕事であるならば、私は新しいprに反対しています。 そうでなければ確かに

何らかの理由で後でどちらか一方を元に戻す必要がある場合に備えて、依存関係の追加が巨大なPRに巻き込まれないようにする方がクリーンです。

依存関係追加のPRがマージされた後のリベースに問題はありません。特に、最小コストフローアルゴリズムでは、ダイクストラアルゴリズムにフィボナッチヒープを使用しており、ペアリングヒープに置き換えたいためです。

@ d-michailあなたはおそらく依存関係を追加するのに最適な人なので、それを進めてください

@simluこれを今すぐ閉じることができますか？ （＃652がマージされました。）FibonacciHeapの残りの使用には、いくつかのフォローアップ作業が必要です（GenericFbionacciHeapはすべて使用されなくなったため、すでに削除できると思います）。

@jsichiそのために別のチケットを作成しますか？ もしそうなら、これは確実に閉じることができます！

みなさん、お疲れ様でした！

フォローアップのために＃666を開きます。 ：metal ：： smiling_imp：