347. Top K Frequent Elements by Ryotaro25 · Pull Request #10 · Ryotaro25/leetcode_first60

Ryotaro25 · 2024-06-01T09:41:08Z

問題へのリンク
https://leetcode.com/problems/top-k-frequent-elements/description/
問題文(プレミアムの場合)

備考

次に解く問題の予告
373. Find K Pairs with Smallest Sums

フォルダ構成
LeetCodeの問題ごとにフォルダを作成します。
フォルダ内は、step1.cpp、step2.cpp、step3.cpp、priority_queue.cpp、quick_select.cppとmemo.mdとなります。

memo.md内に各ステップで感じたことを追記します。

thonda28 · 2024-06-01T13:29:17Z

347.TopKFrequentElements/memo.md

+各要素のそれぞれの数を計算する段階では順番は関係ないのでunordered_mapを使う
+コード量は増えるがfirst、secondが何を表すのか明示した方が処理を理解しやすいと思った
+
+## 他の解法


他の解法として、Bucket sort で実装してみるのもありかと思いました。
（C++ の経験がほぼないので、コードへのコメントは他の方にお任せしようと思います）

@thonda28 step7.cppに追加しました🙇

t-ooka · 2024-06-01T13:33:48Z

347.TopKFrequentElements/memo.md

+要素が重複しない場合は入力データの大きさに影響を受ける
+
+## ステップ2
+自分の変数はcountを使っていたがfrequencyを使う方が伝わりやすそう


僕も最初はcountつかってましたが、同じくfrequencyのほうがいいと思いました。

t-ooka · 2024-06-01T13:40:06Z

347.TopKFrequentElements/memo.md

+わかりにくい。kの数までの方が素直と感じた
+
+## Discordや他の人のコードなど
+クイックセレクトも常識として知っておく


~kthな要素を取り出すときはquickselectがあるというのが常識そうです。

https://en.wikipedia.org/wiki/Quickselect

@t-ooka
コメントありがとうございます。
quickselectが使われるときはまさにこういったときなのですね。知りませんでした。ありがとうございます！

t-ooka · 2024-06-01T13:43:20Z

347.TopKFrequentElements/priority_queue.cpp

+class Solution {
+public:
+    vector<int> topKFrequent(vector<int>& nums, int k) {
+        unordered_map<int,int>nums_frequency;


変数名のnums_frequencyですが、整数に対して頻度なので、num_to_freqencyとかのほうが分かりやすいかと思いました。

@t-ooka step5.cppに修正版を追加しました。

t-ooka · 2024-06-01T14:01:51Z

347.TopKFrequentElements/priority_queue.cpp

+            nums_frequency[num]++;
+        }
+
+        priority_queue<pair<int,int>>descending_numbers;


max heapを初期化しているとおもうのですが、降順という意味合いよりもそのままmax_heap_numbersとかでもいいのかなと思いました。

@t-ooka
ありがとうございます。
他の指摘事項を踏まえてstep5.cppに修正版を追加しました。

fhiyo · 2024-06-01T15:30:01Z

347.TopKFrequentElements/step1.cpp

+        }
+
+        vector<pair<int, int>> descending_numbers;
+        for (auto num : nums_counts) {


for (const auto [num, count] : nums_counts) {

こういう風にも書けますね
https://en.cppreference.com/w/cpp/language/range-for

range-declaration may be a structured binding declaration:

@fhiyo こちらの書き方失念しておりました。きちんと覚えておきます。

fhiyo · 2024-06-01T15:48:57Z

347.TopKFrequentElements/step1.cpp

+        for (auto num : nums_counts) {
+            descending_numbers.push_back({num.second, num.first});
+        }
+        sort(descending_numbers.rbegin(), descending_numbers.rend());


sort(descending_numbers.begin(), descending_numbers.end(), greater<pair<int, int>>());

これの方が素直なのかな、という気がします

@fhiyo レビューありがとうございます。rbegin()とrend()はあまり使わないのでしょうか？🙇

そんなことはないと思うのですが、sortで降順に並べたかったらまず第3引数を指定するかな、という感覚が自分にはあったのでコメントしました。
たとえば逆順にiterateしたいときに for (auto it = foo.rbegin(); it != foo.rend(); it++) と書くのは自然な気がします。
ただ、そんなにC++経験ないので自信はないです 🙇

@fhiyo
今回のように降順と明示している場合には第三引数で記述するように致します。
自分はLeetCode以外で触ったことないので助かります🙇コメントありがとうございました。

fhiyo · 2024-06-01T15:58:11Z

347.TopKFrequentElements/memo.md

+c++には相当するものがなさそうだけどmapにを使えば実装はできる(実際にstep1で使った方法)
+https://github.com/t-ooka/leetcode/pull/3/files#diff-e14e39d01f77a7c369b1f688b2e0c521b4640ce25ca0db0a4a17e789cac614f3
+
+各要素のそれぞれの数を計算する段階では順番は関係ないのでunordered_mapを使う


https://discord.com/channels/1084280443945353267/1206101582861697046/1240515165582135336

unordered_map は実は遅いという話があります。

https://chromium.googlesource.com/chromium/src/+/master/base/containers/README.md#Map-and-set-selection

Do not default to using std::unordered_set and std::unordered_map. In the common case, query performance is unlikely to be sufficiently higher than std::map to make a difference, insert performance is slightly worse, and the memory overhead is high. This makes sense mostly for large tables where you expect a lot of lookups.

この辺の話があるので、単純に順番が関係ないからunordered_map, という考えだとむしろ遅くなるケースもありそうです。

@fhiyo コメントありがとうございます。unordered_mapは必ずしもmapに比べて早いというわけでは無いのですね。知りませんでした🙇ありがとうございます。

fhiyo · 2024-06-01T16:11:35Z

347.TopKFrequentElements/priority_queue.cpp

+            nums_frequency[num]++;
+        }
+
+        priority_queue<pair<int,int>>descending_numbers;


Min Heapを使ってサイズがkより大きくなったら最小をpopするを繰り返す、という方法もありそうです。

@fhiyo
step8.cppに追加いたしました。

fhiyo · 2024-06-01T16:27:05Z

347.TopKFrequentElements/quick_select.cpp

+        return sorted_i;
+    }
+
+    void quickselect(vector<pair<int, int>>& counts, int left, int right, int kth_smallest) {


クラス内部でしか使わなさそうに見えるので、privateにして露出を防いでも良さそうです
(partition()も同様)

@fhiyo この辺りこれまで意識していなかったので以降気をつけます。

fhiyo · 2024-06-01T16:32:28Z

347.TopKFrequentElements/quick_select.cpp

+            unordered_map<int, int> frequency_numbers;
+            for (int num : nums) {
+                frequency_numbers[num]++;
+            }
+
+            vector<pair<int, int>> counts_numbers(frequency_numbers.begin(), frequency_numbers.end());


frequency_numbersとcounts_numbersという名前は微妙な気がします。
この部分を関数化して、中でmapを作ってからvectorに変換して返すようにするのはどうでしょうか。

@fhiyo 関数化してみました。step9.cppに修正版をアップしました。

fhiyo · 2024-06-01T16:47:34Z

347.TopKFrequentElements/quick_select.cpp

+        if (kth_smallest == pivot_index) {
+            return;
+        } else if (kth_smallest < pivot_index) {
+            quickselect(counts, left, pivot_index - 1, kth_smallest);


あえて再帰しなくても、leftとrightを更新するだけなのでループで十分な気がしました。

@fhiyo step9.cppに修正版をアップしました。

fhiyo · 2024-06-01T16:49:10Z

347.TopKFrequentElements/quick_select.cpp

+
+            vector<int> top_k_numbers;
+            for (int i = number_count - k; i < number_count; ++i) {
+                int element = counts[i].first;


countsという変数はこのスコープにないと思います

@fhiyo 誤ったものあげておりました。失礼しました。step9.cppに修正版をアップしました。

TORUS0818 · 2024-06-01T23:32:34Z

みなさんがしっかりコメント付けてくださったので、追加コメントは特にないのですが、強いて言うなら、それぞれの解法のプロコン比較のようなものもあると良いのかなと思いました（私もあんまりできてないのですけど、、）

今回の例で言えば、深さkで止めたMinHeapやquickselect使えば時間空間計算量はどうなるか（実際の速度はどうか）、アルゴリズムとしてわかりやすいものになるのか、それらを踏まえて今回のケースではどれが適切なのかの言及まであると、色々議論が盛り上がると思いました。

Ryotaro25 · 2024-06-03T13:36:20Z

@thonda28 @t-ooka @fhiyo @TORUS0818
皆様レビューありがとうございました。理解と修正に時間がかかり申し訳ございません。
今ほどPushしました。

Ryotaro25 · 2024-06-03T13:42:02Z

@TORUS0818 いったん計測のところまでまとめました。どれが適しているのか調べきれておりませんので後ほど追加します。

syoshida20 · 2025-05-20T00:08:05Z

347.TopKFrequentElements/memo.md

+##　各実装の比較
+計測値はleetcodeを使用
+**priority_queue(step5.cpp)**
+時間計算量:O(n)


Priority QueueのPush, Pop時には、logNの時間計算量が必要なので、
Push時は、N回 logNの操作を行うので、O(n log n)だと思います。

finish

7c75cad

thonda28 reviewed Jun 1, 2024

View reviewed changes

t-ooka reviewed Jun 1, 2024

View reviewed changes

fhiyo reviewed Jun 1, 2024

View reviewed changes

finish

f77faf7

colorbox mentioned this pull request Jul 16, 2024

Create 242. Valid Anagram kzhra/Grind41#8

Open

rihib mentioned this pull request Aug 17, 2024

Top K Frequent Elements rihib/leetcode#20

Closed

add step10

7b67ad8

Ryotaro25 merged commit 9f46b58 into main Nov 9, 2024

syoshida20 reviewed May 20, 2025

View reviewed changes

Conversation

Ryotaro25 commented Jun 1, 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!

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!

TORUS0818 commented Jun 1, 2024

Uh oh!

Ryotaro25 commented Jun 3, 2024

Uh oh!

Ryotaro25 commented Jun 3, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants