Hubspot

CheckIO Hubspotの問題和訳
問題ページのうち, 問題の前提となる小話は訳してません.
また各問題ページ下部にある「Precondition」は「前提条件」のため訳しません(数値の範囲などだけなので).

Hubspot amulet

Find the secret combination for the Hubspot amulet.

While exploring the island, Sofia found an interesting Amulet. Along the perimeter of the amulet small points are marked on each degree (for a total 360 degrees.) Three levers extrude from the amulet with varying lengths. The first lever is the shortest, the second lever is in the middle of the three and the last is the longest. These levers can be rotated, but if you rotate one lever the others rotate as well. The levers rotate discretely by degrees, rotating them clockwise gives you a positive angle while counterclockwise is negative.
After some experiments Sophie discovers the levers correlation. If you rotate a lever, the other rotates in the same direction but with different speed.
If you rotate the first, then the second is rotated f2 times faster, the third -- at the f3time faster.
If you rotate the second, then the third is rotated s3 times faster, the first -- at the s1 time faster.
If you rotate the third, then the first is rotated t1 times faster, the second -- at the t2 time faster.
This correlation can be represented as a matrix 3x3 with 1 in the main diagonal.

For example, the rotating correlation is given as the matrix:

This means that:
If you rotate the first, the second is rotated at double the angle while the third rotates at triple.
If you rotate the second, the third is rotated at double the angle, and the first rotates at triple.
If you rotate the third, the first is rotated at double the angle, and the second rotates at triple.
For example: You rotate the first lever at +10 degrees. As a result, the second is rotated at +20 degrees and the third at +30 degrees.
You can rotate the levers from -180 to +180 degrees only (but in interrelated mode it can be rotated more than 360 degrees). You can rotate each lever once in the following order: the first, the second, the third. Sophie used her X-ray vision and found out what position each lever should be in. After completing these rotations, the levers must be at 0, 225, 315.
You are given a rotation matrix as a list of lists with positive integers and the unitary main diagonal. You should return a list of three integers -- the angles for each lever. The start position of the levers is [0, 0, 0].

Input: A rotation matrix as a list of lists.
Output: The angles as a list of integers.

How it is used:

This a funny combinatorial problem that could help you on dangerous journey in remote jungle for an ancient treasure, as we all know, ancient civilizations hide their treasure with tricky puzzles! ;-)

訳

島の探検の間, ソフィアは興味深いアミュレットを見つけた. アミュレットの縁に沿って小さな点が1度ずつ(合計360度)マークされている. 3つの長さの異なるレバーがアミュレットから突き出している. 最初のレバーは最も短い, 2番目のレバーは中サイズで, 3番目のレバーは最も長い. これらのレバーは回すことができるが, 1つのレバーを回すと他のレバーも同様に回る. レバーは角度によって離散的に回り, 回転は時計回りに正の角度となり, 反時計回りに負の角度となる.
何度か回転させた後, ソフィアはレバー同士の相関を発見した. レバーを回転すると, 他のレバーも同じ向きに回転するが, その早さは異なる.
1番目のレバーを回すと, 2番目のレバーはf2倍の角度を, 3番目のレバーはf3倍の角度を回る.
2番目のレバーを回すと, 3番目のレバーはs3倍の角度を, 1番目のレバーはs1倍の角度を回る.
3番目のレバーを回すと, 1番目のレバーはt1倍の角度を, 2番目のレバーはt2倍の角度を回る.
この相関は対角成分が全て1の3x3の行列として表現される.

たとえば, 回転の相関が以下の行列で与えられるとする.

これは以下を意味する.
1番目のレバーを回すと, 2番目のレバーは2倍の角度, 3番目のレバーは3倍の角度を回る.
2番目のレバーを回すと, 3番目のレバーは2倍の角度, 1番目のレバーは3倍の角度を回る.
3番目のレバーを回すと, 1番目のレバーは2倍の角度, 2番目のレバーは3倍の角度を回る.
たとえば, あなたが1番目のレバーを+10度回す. その結果, 2番目のレバーは+20度周り, 3番目のレバーは+30度回る.
あなたはレバーを-180度から180度まで回すことができる(ただし, 相関で回るものは360度以上回る). あなたはそれぞれのレバーを次の順序に従って1度だけ回すことができる. 1番目, 2番目, そして3番目だ. ソフィアはX-rayヴィジョンを使ってそれぞれのレバーがどの位置にあるか知ることができる. 3つの回転が終わったら, レバーは0度, 225度, 315度の場所になければならない.
あなたには回転行列がリストのリストとして与えられる.　回転行列は対角成分が1で, 残りはすべて正の整数である.　あなたはそれぞれのレバーの角度からなるリストを返す. レバーのスタート位置は[0, 0, 0]である.

入力:リストのリストとして回転行列.
出力:整数からなるリストで, レバーの角度.

備考

この楽しい組み合わせ問題はあなたの古代の宝物があるリモートジャングルの中での危険な旅を助けることができる. 私たちは全て知っているように, 古代文明はトリッキーなパズルで宝物を隠す! ;-)

URL Normalization

URL normalization is the process by which URLs are modified and standardized in a consistent manner. You should normalize a given url.

URL normalization is the process by which URLs are modified and standardized in a consistent manner. The goal of the normalization process is to transform a URL into a normalized or canonical URL so it is possible to determine if two syntactically different URLs may be equivalent.
For our normalization we will use normalizations that preserve semantics. You should normalize a given url using the next rules (only these rules. They are slightly different from RFC).
Normalization Rules:
1. Converting the url to lower case (excepting letters in escape sequences).
HTTP://www.Example.com/ → http://www.example.com/
2. Capitalizing letters in escape sequences. All letters within a percent-encoding triplet (e.g., "%3B") are case-insensitive, and should be capitalized.
http://www.example.com/a%c2%b1b → http://www.example.com/a%C2%B1b
3. Decoding percent-encoded octets of unreserved characters. For consistency, percent-encoded octets in the ranges of ALPHA (%41–%5A and %61–%7A), DIGIT (%30–%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by Uniform Resource Identifiers (URI) producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers. Don't forget about 1st rule after it.
http://www.example.com/%7Eusername/ → http://www.example.com/~username/
4. Removing the default port. The default port (port 80 for the “http” scheme) should be removed from a URL.
http://www.example.com:80/bar.html → http://www.example.com/bar.html
5. Removing dot-segments. The segments “..” and “.” can be removed from a URL according to the algorithm described in RFC 3986 (or a similar algorithm). ".." is a parent directory, "." is the same directory.
http://www.example.com/a/b/../c/./d.html → http://www.example.com/a/c/d.html
Additional links: If you are interested to know more about URL normalization (This is not necessarily for this task), then you can find more information here: Wikipedia, RFC3986

Input: URL, an unicode string.
Output: Normalized URL, a string.

How it is used:

This concept will help you in parsing and analytical processing. URL normalization is required if you need to compare the various URL addresses or you are running a system where letter-casing is sensitive.

訳

URL正規化はURLを一定の方式で変更し, 標準化する処理だ. 正規化処理の目的は正規化または標準的なURLに変換することである. それは2つの文法的に異なるURLが同等かどうかを判定可能にする.
私たちの正規化のために, 意味を保存する正規化を使う. あなたには次のルール(これらのルールだけで, RFCのルールとはわずかに異なる)を使うURLが与えられる.
正規化ルール
1. URLを小文字に変換する(エスケープシーケンス内の文字は除く).
HTTP://www.Example.com/ → http://www.example.com/
2. エスケープシーケンス内の文字を大文字に変換する. パーセントエンコーディングの3つ組("%3B"など)に含まれる全ての文字は大文字小文字を区別しないので, 大文字にすべきだ.
http://www.example.com/a%c2%b1b → http://www.example.com/a%C2%B1b
3. 非予約文字のパーセントエンコーディングされたオクテット(8bit, 16進数で2文字)をデコードする. 一貫性のために, アルファベット(%41～%5Aと%61～%7A), 数字(%30～%39), ハイフン(%2D), ピリオド(%2E), アンダースコア(%5F), チルダ(%7E)の間のパーセントエンコーディングされたオクテットはURIの正規化によって対応する非予約文字をデコードすべきで, URI生成器で生成するべきではない. 最初のルールについて忘れてはいけない.
http://www.example.com/%7Eusername/ → http://www.example.com/~username/
4. デフォルトポートを取り除く. デフォルトポート(httpなら80)はURLから取り除かれるべきである.
http://www.example.com:80/bar.html → http://www.example.com/bar.html
5. ドットセグメントを取り除く. ".."ないし"."はRFC3986に記述されたアルゴリズム(または似たアルゴリズム)に従って, URLから取り除くことが可能である. ".."は親ディレクトリを示し, "."は同ディレクトリを示す.
http://www.example.com/a/b/../c/./d.html → http://www.example.com/a/c/d.html
あなたがURL正規化(このタスクでは必要ない)について知りたければ, WikipediaのRFC3986により詳しく書いてある.

入力:URL, unicode文字列.
出力:正規化されたURL, 文字列.

備考

このコンセプトはあなたに解析と分析処理の手助けをする. URL正規化はあなたが様々なURLアドレスを比較するのに必要だったり, あなたが動かしている過敏なレターケース(?)に必要だ.

Web log sessions

Analyze web logs to learn how people use your sites.

For this task, we have logs from various web sites. These logs contain information about user http and https requests. To analyse this data we need to parse and collect the information contained in these logs.
A log file is a text file, where each request is represented as a string. The strings are separated by a newline "\n". Requests contain a timestamp, username and URL. These fields are separated by ";;".
Timestamps are represented in the following format:
YYYY-MM-DD-hh-mm-ss, where YYYY-MM-DD is the date, hh-mm-ss is the time.
Usernames contain only letters, digits and an underscore.
A URL is given in the normalized form (for example: http://checkio.org).
All fields are case-insensitive and must be converted in the lowercase.
You should collect information about user sessions from the given logs. A session is a sequence of the user requests at the same site (second-level domain), where each request is no more than 30 minutes older than the previous request from that user at the same site. We compare URL by second-level domain name, so admin.checkio.org and www.checkio.org are the same site. The requests are sorted by timestamps.
For example:

[phone];;Name;;http://checkio.org/task
[phone];;name;;http://checkio.org/task2
[phone];;Name;;https://admin.checkio.org
[phone];;Name;;http://www.checkio.org/profile
[phone];;Name;;http://example.com
[phone];;Name;;http://checkio.org/task
[phone];;user2;;http://checkio.org/task

This log contains 4 sessions. The first three requests (1-3) are created by "Name" ("name") at the same site, checkio.org with no more than 30 minutes between "neighbour" requests. The second session contains two requests (4, 6) from "Name" at checkio.org (more than 30 minutes from 01:31:00 request). The next is the request (5) at example.com. The last session is the request (7) from "user2" at checkio.org.
The results should contain information about sessions in the next format:
username;;site;;duration;;quantity_of_requests
where each string is a session.
username is a username from logs.
site is a second-level domain.
duration is a time from first to last requests in seconds. The seconds are calculated inclusively. If there's only one request in the session, then it has 1 second duration. For example: two requests at 00:00:00 and 00:00:02 -- 3 seconds duration.
quantity_of_requests is a quantity of request in the session.
The sessions strings should be separated by newline ("\n") and sorted in the ascending order by next priorities: usernames, sites, durations and quantity_of_requests
The previous log text will be processed in:

+name;;checkio.org;;661;;2
+name;;checkio.org;;1861;;3
+name;;example.com;;1;;1
+user2;;checkio.org;;1;;1

Input: A log text, a multilines string (unicode).
Output: Sessions data, a multilines string.

How it is used:

This concept comes in handy when you need to gather aggregated data from the collected log file. This will help you to get information about user session for the various sites. You can improve your code here for more complex cases.

訳

このタスクのために, 私たちは様々なwebサイトからログを持ってきた. これらのログはユーザーhttpとhttpsリクエストについての情報を含んでいる. このデータを分析するために私たちは構文解析とログに含まれている情報を集める必要がある.
ログファイルはテキストファイルで, それぞれのリクエストは文字列で表現される. その文字列は改行文字"\n"で区切られている. リクエストはタイムスタンプ, ユーザー名, URLを含んでいる. これらの情報は";;"で区切られている.
タイムスタンプは次のフォーマットに従って表現される.
YYYY-MM-DD-hh-mm-ss, ここでYYYY-MM-DDは日付で, hh-mm-ssは時間だ.
ユーザー名は文字, 数字, アンダースコアだけを含む.
URLは正規化されたものが与えられる(たとえば http://checkio.org).
すべての情報は大文字小文字を区別せず, 全て小文字に変換されなければならない.
あなたは与えられたログからユーザーセッションに関する情報を集める. セッションは同じサイト(第2レベルドメイン)の連続したユーザーリクエストであり, それぞれのリクエストは以前のリクエストから30分以内のものである. 私たちは第2レベルドメイン名によってURLを比較するので, admin.checkio.orgとwww.checkio.orgは同じサイトとする. リクエストはタイムスタンプによってソートされる.
たとえば

[phone];;Name;;http://checkio.org/task
[phone];;name;;http://checkio.org/task2
[phone];;Name;;https://admin.checkio.org
[phone];;Name;;http://www.checkio.org/profile
[phone];;Name;;http://example.com
[phone];;Name;;http://checkio.org/task
[phone];;user2;;http://checkio.org/task

このログが4つのセッションを含む. 最初の3つのリクエスト(1から3)は"Name"("name")によって同じサイトで作られており, checkio.orgは前後のリクエストの間が30分以内だ. 次のセッション(4と6)はcheckio.org(01:31:00のリクエストから30分以上過ぎている)で"Name"からの2つのリクエストだ. 次のセッションはexample.comでリクエスト(5)だ. 最後のセッションは, chekcio.orgで"user2"が作成したリクエスト(7)だ.
セッションに関する情報を次のフォーマットにする.
username;;site;;duration;;quantity_of_requests
セッションは文字列.
usernameはログからのユーザー名.
siteは第2レベルドメイン.
durationは最初と最後のリクエストの間の時間を秒にしたものだ. 時間は全てを含んで計算される. セッションにおけるリクエストが1つのとき, それは1秒とする. たとえば, 2つのリクエスト, 00:00:00と00:00:02では, durationは3秒とする.
quantity_of_requestはセッション内のリクエスト数.
セッションは改行("\n")によって区切られ, username, sites, durations, quantity_of_requestの優先順序で昇順にソートされる.
先のログを処理すると以下のようになる.

+name;;checkio.org;;661;;2
+name;;checkio.org;;1861;;3
+name;;example.com;;1;;1
+user2;;checkio.org;;1;;1

入力:ログのテキストファイル, 複数行からなる文字列(unicode).
出力:セッションデータ, 複数行からなる文字列.

備考

このコンセプトは　集められたログファイルから統計を収集するときに必要になる. これは様々なサイトのユーザーセッションに関する情報をあなたが得るのを助ける. あなたはあなたのコードをより複雑なケースに向上させることができる.