宇宙の大きさについて

前回はwebユーザーが宇宙のことをどれだけ知らないかを認識して愕然としたので、今回は一般人にも面白い話を目指します。

宇宙の大きさってどれくらいだと思いますか？

137億光年という大きさを聞いたことがある人がいるかもしれません。
でも、実は宇宙の大きさはわかっていません。有限か無限かすらもわかっていません。

137億光年とは、「観測可能な宇宙の大きさ」といわれるものです。
宇宙の年齢も137億年ぐらいなので、光が137億年かけて届く距離よりも遠いところの情報はまだ届いていないのです。

確実に言えるのは、少なくとも137億光年よりも大きいということです。

下の図は、 Wikipedia に掲載されている宇宙の全体像を対数スケールで示した図です。
この円の外側は観測できないのでどうなっているか全く分からないのです。

"Observable universe logarithmic illustration" by Unmismoobjetivo - 投稿者自身による作品. Licensed under CC 表示-継承 3.0 via ウィキメディア・コモンズ - https://commons.wikimedia.org/wiki/File:Observable_universe_logarithmic_illustration.png#/media/File:Observable_universe_logarithmic_illustration.png

(※ちなみに、上の図では地球が中心に描かれていますが、地球が宇宙の中心なわけでもなんでもないので気を付けてください。光が届く範囲が自分を中心とした球状であるというだけであって、その外側まで考慮した場合に中心というものがどこにあるのか、そもそも中心というのが存在するのかすら、知るすべはありません。)



でも、ちょっと待ってください。

太陽系の公転に関する動画の顛末

ちょっと古い話ですが、太陽系の運動に関する動画がいくつかYouTubeに投稿されています。

小惑星の軌道要素の可視化

前回の続きです。

読み込んだ小惑星のデータセットが妥当であるか、またモデルから生成した小惑星がそれらしいかを確かめるため、小惑星の軌道を可視化する簡単なプログラムを書きました。

https://gist.github.com/msakuta/da721b58ca08c3564075

小惑星番号順に最初の1000個までの軌道をプロットしてみます。赤、緑、青の直線はそれぞれx, y, z軸を表し、原点は太陽の位置です。

小惑星のサイズ・軌道要素の分布のモデル化

宇宙シミュレーションゲームの中で、小惑星をランダムに生成したいのですが、そのサイズや軌道要素はできるかぎりリアルにしたい、というのが今回の趣旨です。

NASA作成、パブリックドメイン

太陽系には知られている限り30万個以上の小惑星があり、検出下限を下回るものを含めるとそれをはるかに超える数があると予想されます。軌道要素が確定しているものだけでも、すべてをメモリ上に置いて時間発展をシミュレーションするのはオーバーヘッドが大きく、リアルタイムシミュレーションには向いていません。

そこで、小惑星の分布を確率変数でモデル化し、疑似乱数でランダムに生成することを考えます。こうするとメモリは最低限しか必要としませんし、実際にシミュレートする必要があるのはプレイヤー（カメラ）の近くだけで済みます。しかも体感的に無限の小惑星を置くことができます。

さて、小惑星が火星と木星の間に多く存在し、小惑星帯を形成していることはよく知られていますが、定量的にモデル化するにはどうしたらよいでしょう？

Git subtreeによるライブラリ管理について

前回は Git subtree merge について説明しましたが、今回はそれに深い関係がある Git subtree コマンドについての説明です。

まず基本的なこととして、 Git subtree は Git subtree merge と同じものではありません。 subtree merge はマージ戦略として subtree を指定したマージにすぎませんが、 Git subtree は明確に外部ライブラリの取り込みと submodule の代替を目的として設計された機能です。 Git 1.7.11 以降であれば、 Git subtree を使用するのが望ましいでしょう。

なぜなら、 Git subtree には、 Git subtree merge にはない、下記のような機能があるからです。

• 取り込んだライブラリ側の歴史を"潰し"(squash)てコンパクトな歴史にできる。
• 自分のプロジェクトでライブラリ側に変更を加えた場合、それをライブラリ側（上流）のリポジトリにプッシュしたり、プルリクエストしたりできる。
• ライブラリの取り込みの初期化のためのコマンドが用意されており、3コマンドぐらい要するところを1コマンドで直観的に実施できる。

あとは、比較的小さな利点ですが、下記の特徴があります。

• Squash したライブラリの歴史には、途中経過のすべては保存していないので、無駄なディスク容量を食わない。（ハッシュだけ記録している）
• Squash の有無に関わらず、 Git subtree を実施したリポジトリは、 Git subtree に対応していないバージョンの Git でも扱える。たとえば Git subtree 担当者以外は、中央リポジトリや、他のプロジェクトメンバーの Git のバージョンが古くても運用できる。（ただ、 Git subtree に関係するコマンドが打てないだけ）

Git subtree の使い方については、 Atlassian Blog の下記エントリがもっともよくまとまっています。

http://japan.blogs.atlassian.com/2014/03/alternatives-to-git-submodule-git-subtree/

しかし、原文が英語の日本語翻訳版なので、あらためて噛み砕いて違った角度から説明してみようと思います。

JISの最近接偶数への丸め(JIS Z8401-1999)について

今日はちょっと専門的な話ですが、数値の丸め処理についての記事です。

数値の丸めといいますと、12.34を小数点以下第1位まで丸めて12.3にするような操作で、四捨五入がおなじみですが、実はJISに規定があり、四捨五入は最善の方法とはされていません。

JISの決まりでは、偶数丸めといわれる、あまりなじみのない丸め方法を使うことになっています。

偶数丸めは、有効桁の一つ下の、丸めたい桁以下が50000…であるときの挙動以外は、四捨五入と同じです。有効桁より下が50000…であった場合は、その上の桁が偶数であれば切り上げられ、奇数であれば切り下げられます。

たとえば、小数点以下を丸める場合、以下のようになります。

1.5 -> 2
2.5 -> 2
3.5 -> 4
4.5 -> 4
5.5 -> 6

JISの規格では、この偶数丸めを「規則A」、おなじみの四捨五入を「規則B」としており、「規則Ａが一般的には望ましい。」としています。なぜなら、「一連の測定値をこの方法で処理すると丸めによる誤差が最小になるという特別な利点がある。」だそうです。

なるほど、と納得しかけますが、何か腑に落ちません。確かに、四捨五入は大きな数値へかたよる方向への丸めですが、偶数に丸めるなどという恣意的な手段が本当に最適なのでしょうか。

Gitでsubtree mergeによるライブラリ管理

※ これから新規に外部ライブラリの管理をする場合は、 Git のバージョンが1.7.11以降である必要がありますが、 Git subtree のほうがお勧めです。

背景

Git では外部ライブラリ（これまた Git で管理されている）を取り込む仕組みとして、 submodule が用意されています。たんなるソースのスナップショットをコピーして置いておくのに比べると、外部ライブラリのバージョンアップに追随できるという利点があります。しかし、 submodule は運用上の問題をいくつか抱えています。

1. git clone した直後に git submodule update をしなくてはならない
　リポジトリをクローンしてすぐにコードをいじり始めたくても、余計なひと手間が必要になります。
　GUI クライアントの中には、この作業を忘れないように通知してくれるものもあります。

2. 外部ライブラリの URL が固定化してしまう
　.gitmodules には submodule の URL が埋め込まれており、ライブラリ側の URL の変更があると追随できなくなります。（正確には、追随するために一つコミットが必要になります。） Web に公開されているオープンソースライブラリの多くは URL を頻繁に変えたりはしませんが、内作のライブラリでは構成変更での取回しの悪さは意外と煩わしいものです。

3. とにかく、なんか仕組みがややこしい
　submodule の目的は外部ライブラリの更新をトレースすることであって、プロジェクト本体のソースをいじる人の多くにとっては関心のないものです。このためにユーザー全員に新しい仕組みの使い方を意識してもらうのはオーバーヘッドが大きすぎる気がします。


ちなみに、 Subversion にも svn:externals プロパティという仕組みがありましたが、 Git submoduleと同じような問題があり、使うのがためらわれました。

他の分散型 VCS もいろいろ探索しましたが、結局のところ、 Git の subtree merge ほど素直にやりたいことができる仕組みはありませんでした。