今週のまとめ
- ライブラリ整備に始まりABC284に終わる
- 職場でデータサイエンティストという職業の昔話をした
- 週記を書くことにした
恐らく読む価値があるのは1/5のデータサイエンティスト界の昔話位だと思います。
(本文中にABC 041 D, 166 E, 225 A-F, 254 F, 284 A-Fの解法を含む話題が出てくるのでご注意ください。)
1/1(Sun)
実家に戻ってこたつでのんびりテレビを見ながらライブラリの整備。
1年前に競プロを始めてよく使うアルゴリズムやデータ構造はスニペット化していたのですがメンテやverifyの管理がしづらくなってきたのでGithubで管理するようにしました。
動作確認にはLibrary checkerが制約、サンプルともに厳しめなものが多く、問題がある場合はそちらでverifyすることに。
これがなかなか通らず閉路検出だと無向グラフの問題はWA, TLE祭り。修正はあきらめてUnionFindとBFS+最短路復元で書き直し。
有向グラフの閉路検出も落ちる。以前書いたものはFunctional graph(出次数が1のグラフ)でしか正しく動かないことに気づいて修正。
1/2(Mon)
この日は奥さんの実家へ。
昨年から節酒に努めているのですが昼からビールを頂き、お義母さんから「日本酒余っているから」と手土産まで頂く。いやー節酒しているんですけどねぇと言いつつ、去年からつけている飲酒記録によると
- 飲酒日数: 315日
- アルコール総摂取量: 11,801g
なので伸びしろだらけ。帰って熱燗でいただきました。スッキリして飲みやすい。
1/4(Wed)
久しぶりに出社。
休暇明けは出社かぁ…とブルーになるところだが年末に今やっている仕事で良い結果が出てその報告を入れていたのでウキウキで出社。
今の会社には「部下なし管理職」という役職で採用してもらって実態どうなんだろう?と思っていたけど本当に部下なしで、しかも一つのテーマに集中させてもらってます。それを半年続けてようやく良い結果が出たので一安心。
1/5(Thr)
職場で「渋谷駅前で働くデータサイエンティストのブログ」さんの「データサイエンティストという職業の10年間の変遷を振り返る」の内容が話題に。
私が若手~中堅の時には「渋谷駅前で~」ブログ[1]以前は「六本木で~」だった気がしますさんはすでにあったので古参の方かと思っていましたが、「黎明期:地道な「分析屋」の時代」で
この時代のことは、正確に言えば僕自身も最初から居合わせていたわけではないので、全て伝聞に頼った話になります。時期としては2012年第3四半期以前で、まだ「データサイエンティスト」という言葉が日本はおろか世界的に見てもまだまだ知られていなかった頃です。
とあったので、私がデータ分析を仕事にし始めた2008年のことを大きく「組織」「分析環境」「ビジネス」の側面から振り返ってみたいと思います。
組織面
まず組織は「数値」「テキスト」と扱う対象で分かれていました[2]適用する手法が全く異なり要求されるスキル、知識も異なっていたので自然な分け方でした。。当時はデータサイエンスという便利な言葉もなく「情報分析」「情報連携」と今聞くと「?」となりそうなチーム名を名乗っていました。
数値はさらに集計分析やDBマーケティングを行う人と数理統計、機械学習をベースにモデル化を行う人とに分かれていたと思います。
“Fact is fact”で記述統計的に現象を捉えようとする人たちと統計理論を武器に現象の「本質」を抽象的に記述・理解しようとする人たちのイデオロギーの違いみたいなのがすでにあって、その後の機械学習、Deep Learningの発展を経た今でもイデオロギーの違いは続くことになります。
分析環境面
分析環境もマルチコアCPUは出ていましたがソフトウェア側がマルチスレッド処理に対応しておらず、データを分割して並行処理をするのが精一杯でした。当然、オンプレ環境なのでメモリ、ハードディスクが不足しても簡単には拡張できません。予算、決裁スケジュール次第で数か月かかるのもザラでした。
数値系はRかClementine[3]これはお客さんが使っているという理由で買ったもので基本はRを使っていた, テキストはMecab + Ruby[4] … Continue readingが多くPythonは日本語の取り扱いが難しくマイナーでした。
ビジネス面
今と比べて一番の違いは「ビジネス」面でしょう。
数値系は金融のクオンツ業務、生損保のアクチュアリー業務、通信系などでのCRMなどが主なデータ分析と呼ばれる仕事でした。
テキストはさらに狭く官公庁、生損保などの大量のテキストを保有[5]当時だと紙媒体を画像スキャンして保有しているだけでも珍しいかったし検索、比較が必要になるごく一部の業界が顧客でした。前処理として「分かち書き」が必要で業務に特化した「秘伝の辞書」づくりに精を出すお仕事…という感じで、良く言えば参入障壁が高く、悪く言えば初期コストが高くなかなか効果を見出せるテーマが少なかったです。
当時、よく聞いた異動理由が
「前の部署でずーっと10年以上、〇〇の分析業務をやってて飽きた」
というもので、それくらい分析をする人もテーマも少なかったのだと思います。
また組織的にも分析チームはビジネス組織ではなく研究開発(コスト部門)に置かれていたのも「自活」が難しかったのだと思います。上司・先輩が社内営業に駆け回ってようやく取れた案件が「3か月50万円」の案件[6]今だと内容によりますが3か月1000万円~くらいが相場感で、それでもようやく有償の仕事が取れた!とみんなでお祝いをしていたのが懐かしいです。
社内に少ないながらも理解者が現れ始め少しずつ実績を積んでいこう…と思っていた2008年秋に大事件が起きます。そうです、リーマンショックです。金融系の案件はすべてなくなり私がやっていた案件もなくなりました。
ただ、コスト部門は気楽なもので仕事がなくなっても「超円高でも会社の決算、微動だにせずドメスティックやなー」と呑気なことを言っていました。もちろん、会社がそんなヒマ人を見逃すはずもなく炎上案件へとドナドナされ4か月間幽閉された後に戻ると
チームがなくなってる…!
というまさかの展開に。そうです、日本企業はクビにはしないものの会社に貢献しない組織はなくなる運命にあるのです。
キャリア1年目にしての転機でしたが、捨てる神あれば拾う神あり。隣のチームのボスが「ビジネスインテリジェンス」「DWHラボ」というキーワードを隠れ蓑にデータ分析チームを引き取ってくれたのでした。
リーマンショック、ギリシャショックとビジネスは冬の時代に入るのですがHadoopの登場により「ビッグデータ」でにわかに盛り上がるのが2010年前後です。
ただ、仕事を集めていたのは基盤寄り、集計分析寄りの方々[7]SQLで書かれていたものをHive, MapReduceで書きなおす仕事が生まれたで統計寄りの私から見ると「隣の青い芝」でした。この辺りの話はまた機会があれば書きます。
1/6(Fri)
前職の上司が大阪に来ているということでランチへ。辞めても色々と心配してもらっているようでありがたい。
ABC225のバーチャル参加
家に帰って明日の練習がてら久しぶりにABC225のバーチャル参加して5完(94分)でパフォ1540相当。
「A – Exact Price」はX%100=0にX>0が必要。サンプルに助けられる。
「B – String Shifting」は愚直に書いたが解説によると
(S+S).substr(i, N)
でシフト文字列が取れた。確かに!というテク。
「C – Doukasen」は長さを決め打つか、時間を決め打って二分探索しか思いつかなかった。実装が重く時間がかかってしまった。解説を見ると両端からスタートして出会う時刻は片方だけスタートして端に行くまでの時間の半分で出せた。確かに。
「D – Restricted Permutation」はすんなり分かった。トポロジカルソートっぽく次数=0のノードをpriority_queueに入れて貪欲に順列を作ればOK。
「E – Placing Rectangles」は考察に時間がかかった。X,Yが大きいので配置位置を探索するのは厳しいし、二分探索するにもうまい単調性が見えない。長方形が2つ場合を考えると配置のパターンが有限個しかなくてそれを3個の場合にも拡張できた[8]解説動画によると長方形が4つの場合は成立しなくなる。四畳半の畳の置き方みたいなのが最適になるケースがある。。
本番はここまで。「F – Parenthesis Checking」は()を+1/-1に対応させて累積和に言い換えて楽勝!と思ったがWA。
- 見るべき累積値を間違えていた
- 区間加算の範囲を間違えていた
- swap時に累積和のみ修正していてて、元の配列のswapを忘れていた
とボロボロ。考え得るすべてのミスをやらかした気がする。
1/7(Sat)
以前、1時間以上かかった or 解説ACした問題の復習。
ABC_166「E – This Message Will Self-Destruct in 5s」はどう計算量を落とすかで悩んだことだけ思い出して同じ悩みに沈む。変数分離した条件に言い換えるのがポイント。以前解いたメモを見ると謎の変数変換をひねり出して解いたので解き方は良くなった。
ABC_041「D – 徒競走」はトポロジカルソートの数え上げ。漸化式たててBitDPでサクッと実装。これも以前は組合せ数をひねり出してDPで頑張って出していたようだ。
ABC_254「F – Rectangle GCD」はそもそもメモリに乗らないのでうまくAi,Biだけ関係に変形させるのがポイント。と言いつつ式変形をミスって1WA & 40分近くかかった。
ABC284の参加
6完(88分+2ペナ)でパフォーマンス1665で新年1回目から幸先の良いスタート。
Dは難しかったが、Eを10分で通してFも文字列比較をO(1)でできたよなと調べるところからでもなんとか間に合ってよかった。
「A – Sequence of Strings」「B – Multi Test Cases」「C – Count Connected Components」は言われた通りにやればOK。といってもCはUnionFindかDFSが必要で初心者には決して易しくない。かなり解かれててレベル高いなぁと思う。
「D – Happy New Year 2023」は難しかった。Nの最小の素因数rとすると [math]\sqrt[3]{N}[/math] で押さえられるので全探索で求めることができる。
あとはrがp, qのどちらかで場合分け。Nがrで2回割り切れるなら [math]p=r, q=\frac{N}{r^2}[/math]で良い。問題はNがrで1回しか割れない場合で [math]p=\sqrt{N/r}, q=r[/math] になる。sqrtの誤差が良く分からなかったのでpを [math]p^2 \leq N/r[/math] を満たす最大の数として二分探索。
⇒Twitterを見ているとsqrt関数で大丈夫だったようだ。しかもnが平方数なら(ll)sqrt(n)とキャストしても大丈夫らしい。
「E – Count Simple Paths」はサンプルを見ながら考えると訪問済みノードを持ちながらDFSをするだけ。10^6を越えたら打ち切れば良いので十分速い。10^6を越えた後もインクリメントをしている…という凡ミスで1WAを出したのがもったいない。
「F – ABCBAC」は文字列比較をO(1)でやるやつか…と検索することから。Rolling Hashを使えば良さそうということでライブラリをコピペで持ってきて、記事やコードをざっと確認してサンプルで合うことを確認。あとはサンプルでハッシュを取る範囲を注意深く決めていって無事AC。
終わった後にそういえば今年の目標とか特に決めてなかったな…と思うものの完全に趣味の世界なので興味が続く限り続けようと思います。
- ABCは一通り典型が身につきFまで安定して解けるところがゴール。スピードの限界が見えたら卒業かな?
- その次はARCか海外コンか?
- AHCは限界がなさそうなので生活、仕事との両立ができる限りは続けそう
かな…と。
あと統計検定の準備をしていた頃はWEBに情報がなかったのでこのブログで書いてて、自分の頭の整理にもなっていました。
競プロは良質な情報が豊富にあって個別記事を書く必要性はあまりなくて、それよりも将来の自分に向けた考察メモやハマりポイントを週記として残しておこうと思います。
関連記事
- 翌週の週記: 「イルミネーションを見ながらLISの復元に思いをはせる」
脚注
↑1 | 以前は「六本木で~」だった気がします |
---|---|
↑2 | 適用する手法が全く異なり要求されるスキル、知識も異なっていたので自然な分け方でした。 |
↑3 | これはお客さんが使っているという理由で買ったもので基本はRを使っていた |
↑4 | 。当時のテキストチームにいた北内さんという方がRuby推しで色々教えてもらったなぁ今どうされているのかな?と思って調べてみたらFORCASという会社のChief AI Officerをされているらしい。さすが。 |
↑5 | 当時だと紙媒体を画像スキャンして保有しているだけでも珍しいかった |
↑6 | 今だと内容によりますが3か月1000万円~くらいが相場感 |
↑7 | SQLで書かれていたものをHive, MapReduceで書きなおす仕事が生まれた |
↑8 | 解説動画によると長方形が4つの場合は成立しなくなる。四畳半の畳の置き方みたいなのが最適になるケースがある。 |
ピンバック: 週記(23/01/08週):イルミネーションを見ながらLISの復元に思いをはせる | 有意に無意味な話