惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Cloudbric
Cloudbric
T
Threat Research - Cisco Blogs
Simon Willison's Weblog
Simon Willison's Weblog
AWS News Blog
AWS News Blog
P
Privacy & Cybersecurity Law Blog
H
Help Net Security
云风的 BLOG
云风的 BLOG
G
GRAHAM CLULEY
Spread Privacy
Spread Privacy
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
A
Arctic Wolf
Project Zero
Project Zero
Engineering at Meta
Engineering at Meta
P
Privacy International News Feed
Blog — PlanetScale
Blog — PlanetScale
Stack Overflow Blog
Stack Overflow Blog
M
MIT News - Artificial intelligence
The Register - Security
The Register - Security
Recorded Future
Recorded Future
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
C
Cisco Blogs
PCI Perspectives
PCI Perspectives
Recent Announcements
Recent Announcements
Martin Fowler
Martin Fowler
A
About on SuperTechFans
W
WeLiveSecurity
GbyAI
GbyAI
V
Vulnerabilities – Threatpost
The GitHub Blog
The GitHub Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
C
Check Point Blog
Y
Y Combinator Blog
月光博客
月光博客
Scott Helme
Scott Helme
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google DeepMind News
Google DeepMind News
F
Fortinet All Blogs
U
Unit 42
G
Google Developers Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Threatpost
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Google Online Security Blog
Google Online Security Blog
Recent Commits to openclaw:main
Recent Commits to openclaw:main
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Cisco Talos Blog
Cisco Talos Blog
博客园 - 三生石上(FineUI控件)
Hugging Face - Blog
Hugging Face - Blog
MongoDB | Blog
MongoDB | Blog
博客园 - 司徒正美

hayato

Chromium's DOM Deep Dive: Understanding Shadow DOM and Tree Structures - hayato Introducing the Task Scheduler in Chromium's Network Stack: A 0.3% Improvement in Loading Speed - hayato 出版のお知らせ 「普通の人が資産運用で99点をとる方法とその考え方」 - hayato Resource loading with Content Addressable Bundles - hayato 普通の人が資産運用で99点をとる方法とその考え方 - hayato Imperative Shadow DOM Distribution API - hayato Google にソフトウェアエンジニアとして入社して 10 年と 10 日がたちました - hayato Web のつくりかた: ソフトウェアエンジニアリングと雰囲気で理解する Web 標準とブラウザのつくりかた - hayato ブラウザのしくみ: データ構造とアルゴリズムと雰囲気で理解する DOM と Shadow DOM - hayato Rust が最強のプログラミング言語である証明 - hayato 六本木ではたらくソフトウェアエンジニアへのよくある質問とその答え (FAQ) (2015 - 2017) - hayato What's New in Shadow DOM v1 (by examples) - hayato Simple timer application for the pomodoro technique - hayato Google の面接試験で出る (はずがない)「海賊と金貨」問題を空気を読まないでプログラムで解いてみる - hayato hayato.io (4topcoder) - hayato SRM432 - hayato SRM405 - hayato SRM386 - hayato SRM385 - hayato SRM384 - ゲーム - hayato SRM369 - hayato SRM368 - hayato SRM366 - typo 2 連発 - hayato Python - generator で素数生成 - hayato New Launguage - 新言語追加の予定? - hayato lxml で HTML スクレーピング - hayato SRM358 - Today is a Bad Day (-50). - hayato SRM349 FizzBuzz 問題が簡単すぎるそんなあなたへ。「赤いマーブル問題」。 - hayato Suffix Array - hayato google-code-prettify を導入してみる - hayato Subset の生成 - hayato 2006 年のまとめ - SRM332 - hayato Google Code Jam 2006 - Championship Round - hayato Blogger Beta に移行 - hayato Google Code Jam 2006 - Round1 に挑戦 - Generics と AutoBoxing - hayato Google Code Jam 2006 - Qualification Round 通過 - hayato Google Code Jam 2006 - Qualification Round に挑戦 - hayato Google Code Jam 2006 - Practice1 - hayato Google Code Jam 2006 - 開催決定 - hayato Stay tuned... Global Google Code Jam 2006 - 秋に開催? - hayato SRM308 - Hard DP - hayato SRM304 - 条件付確率 - hayato JavaWorld に寄稿しました - hayato 2006 TopCoder Open Final Round - hayato IBM Rational Software Development Forum Tokyo で講演します - hayato SRM298 - ひとふで書き - hayato SRM293 - ビンゴ - hayato 2006 TopCoder Open - Round1 撃墜 - hayato 2006 TopCoder Open - Odds 発表 - hayato SRM291 - OutOfMemory - hayato デブサミ 2006 で講演します - hayato SRM287 - 気分は中学生?連立2元方程式 - hayato SRM281 - 2006 年はポイントゼロスタート - hayato SRM280 - Challenge 祭り - hayato SRM277 - 初賞金げっと - hayato マラソン・マッチ - hayato reStructuredText で blogger - hayato 2006 TopCoder Open - NSA がスポンサーに - hayato SRM276 - お買い物は楽しく DP で - hayato SRM273 - bit 演算は int で行われるのね - hayato SRM272 - Division1 - 4 度目の正直 - hayato JavaOne Tokyo で講演します - hayato SRM270 - Integer == Integer - hayato SRM268 - Division2 脱出 - hayato SRM266 - NASA, we have a problem... - hayato SRM265 - Division2 落ち... - hayato SRM262 - 初 Division1 は Typo に終わる - hayato SRM260 - TopCoder への挑戦のはじまり - hayato
2006 TopCoder Open Qualification Round - hayato
2006-03-01 · via hayato

2006 TopCoder Open - Algorithm Competition

  • の予選 (Qualification Round)に挑戦です. いよいよ,始まりました. TopCoder Open は TopCoder の "Crown of Jewels" .一番,盛り上がるイベント・お祭りだそうです.

予選を通過できるのは 750 名.普段のレーティングが上位の 100 名は,自動的に予選を免除されますので,残された 650 の椅子を巡る戦いです.

  • 予選 (Qualification Round): 750 名通過
  • Round1: 750 名 -> 400 名
  • Round2: 400 名 -> 200 名
  • Round3: 200 名 -> 100 名
  • Round4: 100 名 -> 48 名

見事,Round4 を勝ち抜いた 48 名は,ラスベガスにご招待され,オンサイトで決勝です.

通常の SRM と異なり,予選はちょっと形式が異なります.

  • 問題は 2 問,制限時間は 1 時間
  • 開始時間は決まっていない.24 時間以内ならいつ挑戦をはじめてもよい
  • チャレンジ・フェーズはなし

問題セットは,5 種類用意され,そのうちどれか 1 種類が自動的にアサインされます.各問題セットから,上位 (650/5 =) 130 名が予選を通過できます.早速,アリーナに参加してみると

2006 qr

Set14 にアサインされました.問題 1 種類につき,Room が 3 つ用意されていますね.計 15Room です.

2006 qr

各 Room ごとに,およそ 170 名ほど割り振られていました.ということは,参加者の総数は 170 x 15 = 2550 名ほどか.

予選通過のためには各 Room 内で,130 /3 = 43 位くらいに入るのが目安になるか.自分が挑戦した時間が終了近かったので,もうすでに終わっている人のスコアをあらかじめみることができました.自分がアサインされた Room14 では,こんな様子でした.

2006 qr

なるほど,ボーダーラインの 43 位に入るためには,2 問とも確実に,その上ある程度スピードも要求されそうです.まだシステムテストは終わっていないから,ボーダーはこれより下がるでしょうが,思っていたより,レベルが高そう..それとも問題が簡単なのか?..

と思いつつ,自分もスタート.

250 点問題.問題の意味をつかむのに,一苦労.

結局,Brute Force で全パターンを調べました.この時点で,18 分ほど時間をとられました.まずい.

750 点問題.

数字が与えられます.

k = "12XX355"

X のところは判明しない桁です.この数字 k が(num)で割り切れるとした場合,このような数字 k は何通りありますか?という問題です.たとえば,

k = "1X",num=3

ならば,"12", "15", "18" の 3 通りです.

k = "23X34XX24XX34X", num=17

ならば,58823 通りです.

DP でいけると思い,方針じたいは結構早めに決まったのですが,実装にとまどる,とまどる.あせっていたのか..結局,30 分ほどかかり,Submit.

2 問あわせてスコアは 536.71. Room14 内で,65 位ほどでした..これはだめか..

2006 qr

結果

最終的なシステムテストの結果です.( Room Statistics )

Room7/9/14 は同じ問題セットだったそうです.その Room7/9/14 をあわせた中での順位は,

2006 qr

85 位.130 位以内なので,予選通過ですよね?まだ正式連絡はきていないけれど.

  • Room14 だけ,なぜかハイスコアの人が多かったこと
  • 750 点問題に落ちた人が,相当多かった

ということで,85 位に入り込めたっぽいですね.

750 点問題で落ちた人は,可能な数字をすべて生成してから,それらを num で割り切れるかどうかをチェックしている人が多かったようです. k の最大の長さの条件は 18 ですので,k = "XXXXXXXXXXXXXXXXXX" の場合,必要な数字は 10^18 通りになってしまいます.これを全て調べるのは,絶対無理ですね..

今日の教訓

  • もっと正確かつ早い実装力が必要..