Why bridges and not an optimizer
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
- 技術スタック
- julia
調査の方向性
まず、既存の相補性制約の再定式化と MOI.optimize! のフローを読み、その設計を MultiObjectiveAlgorithms.jl および MathOptLazy.jl と比較します。キャッシュされた相補性制約と τ を減少させる warm start がどのように機能すべきかを明確にし、合意されたアーキテクチャと実装計画を完了とみなします。
索引モデルが issue の本文から書いたものです。
説明
I'm not convinced about the bridge approach. I know we discussed it and I was interested to see what happened, but after looking at the code I have some reservations.
In particular, many of the reformulations are not exact with the idea that you solve a sequence of problems for decreasing $\tau \rightarrow 0$, warm-starting each solve from the prior solution. The bridge approach doesn't allow that.
I was more thinking along the lines of https://github.com/jump-dev/MultiObjectiveAlgorithms.jl and https://github.com/jump-dev/MathOptLazy.jl, where we cache some part of the model (here, complementarity constraints), and then move all of the complexity into the MOI.optimize! routine.
- 主要言語
- Julia
- スター
- 12
- フォーク
- 1
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
jump-dev/MathOptComplements.jl のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
jump-dev/MathOptComplements.jl#20 · コメント 3 件 ·
jump-dev/MathOptComplements.jl の issue をすべて見る
似ている issue
-
CI: two jobs fail on the new ubuntu-latest (Ubuntu 26.04) runner image対応中かも @bjarthur が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 63/100
mojaie/MolecularGraph.jl#151 ·
-
Julia runner test IDs cause false oracle regressions対応中かも @yu-depend が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信