0

私はそのような機能を持っています

applyDiff(List orders, List ordersToAdd, int[] ordersToRemove) {
}

この関数は、からの注文を追加orderToAddorders、からいくつかの注文を削除する必要があります。削除される注文のインデックスは配列ordersで渡されます。ordersToRemove

問題は次のとおりです。順序fromが位置のどこかにordersToAdd挿入されるたびに、それからのすべてのインデックスは、で増加する必要があります。ordersposorderToRemovepos1

だから私はordersToRemove配列を動的に変更する必要がありますか?

同時に要素を追加-削除する必要があり、削除する要素のインデックスがある場合の一般的な「アルゴリズム」またはコレクションの変更とは何ですか?

注文は非常に重要であり、その中の機能が注文を追加および削除する順序を決定するため、このタスクを2つ(注文の追加、注文の削除)で分割することはできません。

4

1 に答える 1

0

どの位置に正確に挿入するかをどのように決定するか、またそのセマンティクスは何であるかを明示的に指定していませんint[] ordersToRemove(ただし、後者の場合、メモを考慮して削除するオブジェクトのインデックスであると想定しています)。しかし、私はまだ「アルゴリズム」を提案することができ、それに応じてそれを適用します:

メソッドにもう1つの変数を導入しますindexIncrease。に初期化し0ます。ordersToAddこの変数を増やすために追加するたびに。からの値を検討するたびint[] ordersToRemoveに、この値を検討するだけでなく、を検討してordersToRemove[i] + indexIncreaseください。ordersToRemoveしたがって、配列全体を反復処理したり、追加するたびに値を増やしたりすることなく、更新された値を取得できます。

この「アルゴリズム」を適用すると、リストordersが常に現在の状態になりますが、ordersToRemoveはまったく更新されないことに注意してください。うまくいけば、これはあなたのために働くでしょう。

編集コメントと完全に変更された問題の説明に従って:

  • バイナリインデックスツリーordersToRemoveを使用する場合は、のすべての要素のループを回避できます。これにより、すべての変更が複雑になります。ここで、nは存在する注文の総数です。O(log n)
  • インデックスツリーに与える入力制限を考慮すると、既存のブルートフォースソリューションよりもはるかに劣ります。毎回反復する要素の数は無視できるほど少なく、パフォーマンスの欠点は無視でき、インデックスツリーは非常に複雑です。

全体的に見られるように:私はあなたに現在の解決策に固執することを勧めます

于 2012-04-30T07:56:54.130 に答える