-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First Unique Character in a String #18
base: main
Are you sure you want to change the base?
Conversation
|
||
-1をreturnするのは行儀が良くないが、LeetCodeの制約がなければ返り値としてerrを返すのが一番良いと思う。該当する要素が存在しないことは正常な挙動の範疇なのでlog.Fatalはするべきではないし、ログに記録するほどのものでもないと思う。 | ||
|
||
また、「サロゲートペアや合成文字等、char の値を複数用いないと表現出来ない文字が来ないことを想定」している。(https://github.com/seal-azarashi/leetcode/pull/15#discussion_r1704423277) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
文字コードは魔境であるという認識は大事でしょう。すべてを知っている人はいないと言っていいと思います。
あとは、LinkedHashMap 相当のものを実装してみるのは一つかもしれません。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
良いと思います!
ちなみにStep2ではcapacityを指定してmapを作成したところ、実行時間は20~25msとなった。 | ||
*/ | ||
func firstUniqCharStep2(s string) int { | ||
frequency := make(map[rune]int, len(s)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sにユニークな文字が少ないとき、余分にメモリを確保することになるのでトレードオフの議論は必要そうかなと思いました。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
キャパシティはlen(s)ではなく、26ではないでしょうか?
あと配列とmapのパフォーマンスの違いの原因については、TLBヒット率が変わってくることも原因としてありそうだと思った |
配列とmapのパフォーマンスの差の見積もり↓ |
First Unique Character in a Stringを解きました。レビューをお願い致します。
問題:https://leetcode.com/problems/first-unique-character-in-a-string/
言語:Go
すでに解いた方々:
hayashi-ay/leetcode#28
sakupan102/arai60-practice#16
goto-untrapped/Arai60#17
Exzrgs/LeetCode#9
SuperHotDogCat/coding-interview#22
su33331/practice#2
fhiyo/leetcode#18
TORUS0818/leetcode#17
Ryotaro25/leetcode_first60#16
nittoco/leetcode#20
kazukiii/leetcode#16
Mike0121/LeetCode#32
Yoshiki-Iwasa/Arai60#14
seal-azarashi/leetcode#15
サロゲートペア・結合文字・合字
#5 (comment) の説明を参照。結論としては、文字列にサロゲートペア・結合文字・合字などが含まれる場合であっても、グラフィムクラスタを使えば"≠”のようなリガチャを除けば文字列を前から順に走査するのであれば問題なく文字数をカウントできそう(文字列の途中から走査する場合は旗シーケンスの文字列の場合は文字の境界が判定できないため、結局は文字列の先頭から走査する必要が生じる)。Goの場合、https://pkg.go.dev/golang.org/x/text/unicode/norm を使えばできそう(グラフィムクラスターをGo言語で扱う)。
Goのエラー処理
#8 (comment)
mapの内部実装について
https://rihib.gitbook.io/computer-science/algorithmicfoundations/hashtable#gonomap