300. Longest Increasing Subsequence #33

TORUS0818 · 2024-10-26T09:14:10Z

https://leetcode.com/problems/longest-increasing-subsequence/description/

oda · 2024-10-26T14:19:58Z

medium/300/answer.md

+```
+思考ログ：
+- この問題に対してoverkillなのは分かっているが、皆さんが結構実装されているのでこの機会にお勉強してみた
+- シンプルなセグ木の理解自体はそんなにかからなかったが、寧ろこの問題での使い方の部分で躓いた（それはセグ木を理解できていな(ry）


うーん、この overkill という表現にとても違和感があります。

「必要よりも高度な道具を使って解決する」くらいの意図だと思うのですが、ここでいう高度とはどういうことでしょうか。
実装の複雑さだったら、C++ の std::map 典型的には赤黒木のほうがはるかに複雑ですよ。Priority Queue さえも複雑じゃないでしょうか。

これは、アルゴリズムやデータ構造が、なんらかの高度さの順に並んでいるという感覚がなければ出てこない表現です。

セグメントツリーは、確かに「使えることに気が付きにくいが、計算量を落とせる場合が極めて稀にあり、短時間で書けるくらい単純である」という意味で、プログラミングコンテストに向いているため、競技プログラミング同好会時代にも出てきていました。

ありがとうございます。
overkillという表現は、ロジックを理解しようとして色々調べていた際に見かけたものを深く考えず引用したものなのですが、少し思考を整理してみました。

今回私が「overkill」と感じたのは、セグ木のような方法を用いずとも、もっと素直で万人が思いつくであろう方法が他にあるだろう、さらにそれを使うことで劇的に計算量が改善されるならまだしも、そうでないならoverkill（やり過ぎ）だろう、という感覚だったのだと思います。

ご指摘のアルゴリズムやデータ構造に順序が入っているのでは、という点に関してはなんとも言えないところがあり、こんなの誰かから聞かないと一生思い付かないな、みたいなアイデアに関しては高度なもの、という感覚は少なからずあります。ただそのようなものを知っていることが偉い、という感覚はない（はず）と思っています。

hayashi-ay · 2024-10-26T14:25:59Z

medium/300/answer.md

+            compressed_num = [num_to_compressed_num[num] for num in nums]
+            return compressed_num
+
+        compressed_num = compress(nums)


compressed_numsとかの方が良いかなと思います

hayashi-ay · 2024-10-26T14:29:26Z

medium/300/answer.md

+        n = len(set(compressed_num))
+        st = SegTree(n)
+        for i, num in enumerate(compressed_num):
+            res = st.query(0, num)


resより良い命名があると思います。ものとしてはnumより小さい値で終わるLISのうち最長のものですね。

hayashi-ay · 2024-10-26T14:30:33Z

medium/300/answer.md

+
+講師役目線でのセルフツッコミポイント：
+- 命名関連の選択肢は再度考えた方がいい
+  - 名前を工夫する


練習なので命名を工夫した版も書くと良いと思います

step3で書いたつもりでした。

fhiyo · 2024-10-27T06:28:23Z

medium/300/answer.md

+        # get parent_index
+        i = (i - 1) // 2
+        while i >= 0:
+            self.tree[i] = max(self.tree[2 * i + 1], self.tree[2 * i + 2])
+            i = (i - 1) // 2


while (i := (i - 1) // 2) >= 0: self.tree[i] = max(self.tree[2 * i + 1], self.tree[2 * i + 2])

一応、こうも書けそうですね。見づらくなるギリギリのラインな気もしますが

fhiyo · 2024-10-27T06:30:47Z

medium/300/answer.md

+        l = self._convert_to_tree_index(l)
+        r = self._convert_to_tree_index(r)
+
+        result = IDENTITY_ELEMENT


IDENTITY_ELEMENT, 定数 (本当は変数ですが) にする必要ありますかね？自分はそのまま result = 0 と書いた方が0で初期化する意図が分かりやすい気がしました。

演算によって単位元が変わるので、こんな形式にしたのですが、このSegTreeクラスは汎用的に設計ができてる訳でもないので、なんだか中途半端なことになっていると思います。

fhiyo · 2024-10-27T06:54:45Z

medium/300/answer.md

+        while l < r:
+            # if l is left child
+            if l % 2 == 0:
+                result = max(result, self.tree[l])
+            # if r-1 is right child
+            if r % 2 == 0:
+                result = max(result, self.tree[r - 1])
+            l = (l - 1) // 2
+            r = (r - 1) // 2


自分がセグメント木をあまり理解していないからでしょうが、何をやっているのか分かりませんでした...
(if l is left child とありますが、lが偶数ならlは右の子のような？)

~~配列の0番目の要素がrootになるようにしているので、奇数が左の子になると思います。~~
嘘つきました。コメントがおかしいかも。。

lが偶数ならlは右の子のような？
右ですね。。

やっていることは、、説明がややこしいですね。。何か具体例を考えるのがいいかもです。

配列の長さが7のケース（葉が4つ）で考えます。
0[1, 2, 3, 4]
1[1, 2] 2[3, 4]
3[1] 4[2], 5[3] 6[4]
のように配列の要素[圧縮した要素の集合]が対応しています。

numsから4（圧縮後）が出てきたとします。
今まで出てきた1 or 2 or 3で終わる最長の部分列の長さが知りたいです（それ+1を6[4]にセットすれば良いので）

この時、3[1] 4[2], 5[3]の各々について確認するのではなく、1[1, 2] , 5[3]だけ確認すれば効率がいいということで、そのような候補の探索を始めるのですが、例えば左端の3[1]をこの候補に入れるかどうかを判定するのに、これが右の子かどうかを確認しています。左の子の場合は親を確認すれば良いのでスキップします。右の子の場合は親に左の子の情報が含まれてしまっているのでこれを採用する必要があります。

区間の右端から考える場合も考え方は同じです（ただ候補に含めるかどうかの判定の左右が逆になります）

親が同じになったら探索を終了します。

圧縮した要素の集合は1-indexedになってますが0-indexedですかね？(じゃないとコードにある木のindexへの変換が上手くいかない気がします)

これって一般にはqueryの引数としてlが0以外も来ることを想定していると思いますが、lが0より大きい場合って変なことになったりしませんか？上の具体例だとたとえば st.query(1,3) (0-indexedで書いています) みたいなやつです。

たとえば下の図に書いたような [1,3)の区間に対するクエリ (st.query(1,3)) を行うと、rが偶数のときr-1の場所を見ながら親を辿るので[0,3)の区間の最大値を返すことになっちゃう気がしています。 (図の赤い斜線部分がクエリの結果参照される範囲)

このコード、n = 4 で r = 4 が来るとどこまでループが回りますかね。l = 2 とでもしましょうか。
はじめに、(5, 7) になります。その後、(2, 3), (0, 1), (-1, 0) で (-1, -1) で停止であってますか。

あ、これ、まずなんで訳が分からなくなるかというと、l, r という整数に2つの情報、つまり、「どこ」から「どこ」までのセグメントであるか、という情報を載せていて、(segment - 1) // 2 という整数の上での操作と、セグメントの上での意味が遠く見えるからです。

さて、segment(l, width=1) で、セグメントの範囲の値が手に入るとしましょう。
ただ、width は l が2で割り切る回数まで倍に広げた場合は効率的に計算できます。

効率を考えないと

result = 0 for i in range(l, r): result = max(result, segment(i, 1))

が求めたいものですね。

ところで、これだと効率が悪いので速くしたいのですよね。
大まかには次のような構造です。

result = 0 width = 1 while l < r: # segment(f(l), width) と segment(g(r), width) で result 更新 # l, r を微修正 width *= 2

次、l と r の不変条件は、なんでしょうか。[l, r) の範囲は未計算ということですね。
つまり、このプログラムは width *= 2 をしなくても大まかには動くものです。

result = 0 while l < r: result = max(result, segment(l, 1)) l += 1 result = max(result, segment(r - 1, 1)) r -= 1 # 最後一回は2回行われることがあるので本当は判定必要だけれども今回は max だからまあいいでしょう。

さて、l が width * 2 で割れるときには、segment の計算を width *= 2 してからしたいわけです。しかし、割れない場合には、その場で計算するしかありませんね。r も同じで r が奇数ならば width を広げたら計算ができなくなるので、計算してから次にいくしかありませんね。

これくらいの情報が陽にあれば、読めるコードになると思います。

@oda
補足説明もありがとうございます！
少し考えてみたいと思います。

以前にも”意図と操作の距離”についてコメントを頂いていました。
面倒くさがって、結果として遠回りになってしまっているのですね。

@fhiyo
以下のコミットで修正しました。
e70ab6a

fhiyo · 2024-10-27T07:22:10Z

medium/300/answer.md

+            if not minimum_last_val_subseq \
+                or minimum_last_val_subseq[-1] < num:
+                minimum_last_val_subseq.append(num)
+
+            i = bisect.bisect_left(minimum_last_val_subseq, num)
+            minimum_last_val_subseq[i] = num


continue忘れですかね？numをappendしてからnumを二分探索してその位置にnumを挿入していて無駄な気がします。

個人的には常に二分探索する方が好みです。

i = bisect_left(minimum_last_val_subseq, num) if i >= len(minimum_last_val_subseq): minimum_last_val_subseq.append(num) else: minimum_last_val_subseq[i] = num

ありがとうございます。
スキップし忘れました。

セグ木のバグを修正

nodchip · 2024-11-02T09:04:30Z

medium/300/answer.md

+        # 長さがindex+1になるような任意の増加部分列を考えた時
+        # それらの最後の要素のうち最小のものを記録するための配列
+        # ex) [4,6], [3,5], [1,2]ならmin(6, 5, 2) = 2が入る
+        minimum_last_val_subseq = []


個人的には length_to_min_last_vals という名前にすると思います。配列の添え字に何を指定すると、どのような値が返ってくるかを表そうとしています。ただ、 length と添え字が 1 ずれている点に注意が必要です。

nodchip · 2024-11-02T09:06:01Z

medium/300/answer.md

+  > min_ends_of_increasing_subsequencesが適切です。この名前は要素が増加部分列の最終要素の最小値であることを明確に示し、長さも扱いやすいです。  
+  > もし簡潔さを重視する場合は、increasing_subseq_min_endsも良い選択です。
+  - なお、質問は以下
+    > 今pythonでコードを書いているのですが、変数名の命名で困っています。


半分余談となりますが、プロンプトの最初に「あなたはプロの○○でうす。」ですとか「あなたは〇〇の専門家です。」という文を入れると、返答の精度が上がるそうです。

プロンプトエンジニアリングですね。
ここら辺の事情もなかなか追えてませんが、面白そうな領域ですよね。

fhiyo · 2024-11-02T15:28:39Z

medium/300/answer.md

+            res = st.query(0, num)
+            st.update(num, res + 1)
+
+        return st.get_maximum_val_of_all_segments()


st.query(0, n) で十分な気がしています。

st.query(0, n)でもう一度計算するのも無駄かなと思い、この処理を加えました。

fhiyo · 2024-11-02T15:30:08Z

medium/300/answer.md

+        assert 0 <= seg_i < self.leaf_n, f'seg_i is out of index. seg_i: {seg_i}'
+
+        tree_i = seg_i + self.leaf_n


下の query にもあるし、別のメソッドに切り出した方が見通しが良い気がしました。

1行で済むような処理なので関数に切り出さない選択をしましたが、このインデックス変換の計算は、何をしているかぱっと見では分かりにくいので、関数として切り出すのも良いなと思いました。

fhiyo · 2024-11-02T15:32:37Z

medium/300/answer.md

+        n = len(set(compressed_num))
+        st = SegTree(n)
+        for i, num in enumerate(compressed_num):
+            res = st.query(0, num)


resとは何でしょうか？

resultの略で横着しました。。

fhiyo · 2024-11-02T15:46:48Z

medium/300/answer.md

+        tree_l = start_seg_i + self.leaf_n
+        tree_r = end_seg_i + self.leaf_n


tree_lやtree_rという変数名を見てindexだとは思えない気がします。

いい名前が思いつきませんでした。。
seg_iに合わせて、start_tree_iとかにするか、tree_i, tree_jとかにしてしまうとかですかね。。

Create answer.md

1ad295b

oda reviewed Oct 26, 2024

View reviewed changes

hayashi-ay reviewed Oct 26, 2024

View reviewed changes

fhiyo reviewed Oct 27, 2024

View reviewed changes

Update answer.md

e70ab6a

セグ木のバグを修正

nodchip reviewed Nov 2, 2024

View reviewed changes

fhiyo reviewed Nov 2, 2024

View reviewed changes

colorbox mentioned this pull request Sep 28, 2025

300. Longest Increasing Subsequence colorbox/leetcode#45

Open

		assert 0 <= seg_i < self.leaf_n, f'seg_i is out of index. seg_i: {seg_i}'

		tree_i = seg_i + self.leaf_n

		tree_l = start_seg_i + self.leaf_n
		tree_r = end_seg_i + self.leaf_n

300. Longest Increasing Subsequence #33

Are you sure you want to change the base?

300. Longest Increasing Subsequence #33

Uh oh!

Conversation

TORUS0818 commented Oct 26, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TORUS0818 Oct 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oda Oct 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

TORUS0818 Oct 27, 2024 •

edited

Loading

oda Oct 28, 2024 •

edited

Loading