世界を動かす技術を、日本語で。

月の欠けた11日 (2015)

概要

  • xkcdのカレンダー漫画で「11日」が異常に小さい理由の調査
  • Google Ngramsで「11th」が他の日より少ない現象の確認
  • 原因はタイプミスやOCR誤認識によるものと判明
  • 1860年代以降、タイプライターの普及が誤認識を加速
  • 「nth」などへの誤読も大きな要因

xkcdカレンダーと「11日」の謎

  • 2012年11月28日、Randall Munroeがxkcdで カレンダー漫画 を公開
  • 各日付の大きさは、Google Ngramsでの 言及頻度 に比例
  • 7月4日、12月25日、各月の1日や末日などが大きく描かれる傾向
  • 2月29日などは小さいが、特に「11日」が他の多くの日より 顕著に小さい
  • タイトルテキストでも「9月以外の11日は他の日よりも明らかに少ない」と指摘

データ分析による実態把握

  • 実際にNgramsデータベースで 各日付の出現頻度 を集計
  • 各月の同じ日(例:1月1日、2月1日…)の中央値を算出
  • 1日と15日が目立つが、 11日だけが大きく低い値
  • 1800年から2008年までのデータでも 11日の低さは一貫
  • 1860年代以降、11日の頻度がさらに低下し、20世紀前半には 半分程度

誤認識の実態と原因

  • 11は「1」と「I(大文字アイ)」「l(小文字エル)」「i(小文字アイ)」と 見分けがつきにくい
  • OCR(光学文字認識)やGoogleのアルゴリズムが 誤って認識 してしまう現象
    • 例:March llth、July IIth、May iith などの誤記
    • 9通りの誤認識パターンのうち、5種類以上が実際にデータベースで確認可能
  • これらの誤記を元の11日に 加算すると頻度が回復
  • 1860年代以前は差が消失し、それ以降も差の多くが解消

「nth」への誤認識とその影響

  • 1860年代以降、 11thがnthと誤認識 される現象が多発
  • 「January nth」などの 無意味なフレーズ がデータに多数出現
  • 一部の年では、誤認識された「nth」の数が正しい「11th」より多い場合も
  • 「nth」を加算すると、残りの差もほぼ全て解消

タイプライターとフォントの影響

  • 1860年代、 タイプライターの登場 が誤認識の増加と関連
    • 初期のタイプライターには「1」のキーがなく、小文字「l」で代用
    • フォントも「1」と「l」が ほぼ区別できないデザイン に変化
  • 印刷技術の向上で1970年代以降は減少傾向だが、 完全には解消されず
  • 「nth」への誤認識の理由は不明だが、 機械学習の訓練データやフォント特性 が影響している可能性

結論と今後の課題

  • 「11日」が少ないのは 技術的な誤認識 が主因
  • タイプライターとフォントの歴史的変遷が大きく影響
  • 「nth」誤認識の詳細な原因解明にはGoogleのアルゴリズム解析が必要
  • 分析コードは Githubで公開

Hackerたちの意見

要するに、OCRのエラーだね。

あるいは、そうじゃないこともある。面白いポイントの一つは、小文字の「l」が「1」の代わりに使われていたことだ。「アルゴリズムが10月11日を読んだとき、私たちが思っていたよりもずっと正確だった。」

日付でイベントの名前をつけるのは、長続きしないだろうね。

面白い!2日、3日、22日、23日に何が起こったのかについての2つ目の投稿へのリンクもチェックしてみてね。シンプルだけど、読む価値はあるよ:https://drhagen.com/blog/the-missing-23rd-of-the-month/

だから、私の原則の一つは、外れ値には懐疑的でいることなんだ。多くの場合、それは実際には存在しなくて、真のデータを誤って表現してしまうから。中央値が平均よりも好まれる理由の一つでもあるし、外れ値を除外してみて、物事がどう見えるかを確認するのも大事だよ。

これから学んだのは、どんなデータがどのように取得されたのかを掘り下げることが有用で重要だってこと。

トワイマンの法則に似てるね。「興味深い、または異なるように見える数字は、通常間違っている。」https://en.m.wikipedia.org/wiki/Twyman%27s_law

このアドバイス、ちょっとおかしいよ。特定の状況(センサーが調子悪いときとか、調査の回答者が明らかにランダムに選んでるとき)を除けば、外れ値は単なる外れた値で、分析には残しておくべきだと思う。せいぜいクリップしたりウィンザー化する程度で。科学雑誌に投稿する際、外れ値を取り除いた理由を確認せずに「外れ値を削除しました」って言ったら、即座に拒否されることもあるから、当然だよね。

データの質にどれだけ気を使っていたかがわかるよ。文脈依存のグリフの同等性を見ようとする時間を全く取らなかったからね。文脈に敏感なアルゴリズムは、単に「ここにどんな文字があるかを推測する」ような単純なアルゴリズムとは違って、同じ間違いを犯さないこともある。ALPRシステムではこれがよく起こるんだ。なぜなら、いくつかの印刷物が特定の文字を除外しているから。Oと0が最も一般的な文字の同等性だけど、特定の場所でだけね。データに依存して何かをしようとすると、OCRは実際には複雑なんだ。

前回これがHNに載ったとき、ホスティングプロバイダーがトラフィックについて文句言ってたけど、今はブログをGitHub Pagesに移行したから、今回は問題ないと思う。

こういうの大好き!でも、もしそうなら「1」がつく日付はもっと少ないべきじゃない?なんで22日と23日なの?11日はスキャナーのエラーで説明できるかもね。例えばl2が12に修正されて、llが11に修正されない場合とか。でも、2、3、11、22、23が少ないのは、ランダムに選ばれたように見えない日付を避けようとする人が多いからかもね。

2、3、22、23については、後半を読んでみて:https://drhagen.com/blog/the-missing-23rd-of-the-month/。(要約すると:人々は時々2d、3d、22d、23dと書いてたらしい。)これで12と13がその欠損を示さない理由も説明できるね。

他の序数の1は誤読されてたけど、隣り合った2つの1は他のどんなものよりもずっと誤読されてた。今の私の理論は、最後の段落でちょっと触れたけど、「nth」がOCRの辞書に入ってて、「nth」はピクセル空間で「11th」に近いから、他の序数は辞書の単語にそんなに似てないんだよね。だから「11th」が一番誤読されるんだと思う。

いや、これは意外と楽しかった!