hirax.net::Keywords::「スキー」のブログ

■「私と好みが似てる人」 その2　

ログ解析の6ヶ月点検

　本サイトが公に公開されるようになってから6ヶ月経った。新車でも購入してから半年経てば、6ヶ月点検があるのだから、本サイトについても6ヶ月点検を行ってみたい。

　まずは、週別のアクセス量変動を挙げてみる。

1998/12/13-1999/4/24の週別アクセス量

Overall Accesses

　アクセス数は割に順調に伸びているようである。1999/02下旬辺りにネットワーク不調とログ解析失敗などによるデータ欠損が見られるが、それ以外ではほぼ線形に増加している。1999/4上旬に増加の傾きが変化しているのはinfoseekにページを登録したことによるものと考えられる。

　次に、時間別アクセス量である。以下に示すのは、1999/4/18-24の時間別アクセス量である。
　これを見ると、深夜3時位にアクセス数がぐんと減ることがわかる。深夜3時位に眠りにつく人が多いのだろうか。
　そして、早朝5時過ぎからアクセス数が増えていくことがわかる。5時過ぎくらいから活動を始める人も多いようだ。そして、昼の12時辺りにひとつピークがある。これは、企業の昼休み時間にアクセスしている人達によるものだろう。次に15時位に大きなピークがある。これは、何だろうか？まさか、おやつの時間ではあるまい。企業ユーザーが一服しているのだろうか？小さい18時辺りのピークも、企業ユーザーの就業時間の終わりを示すものと思われる。
　そもそも、こういった昼間の時間別アクセス数から見えてくるユーザーというものは、時間に縛られる企業ユーザーになってしまうのだろう。

1999/4/18-24の時間別アクセス量

　さて、次はアクセス数のサイトランキングである。ただし、ここでのサイト=IPアドレスであり、ドメイン解析は行っていない。したがって、同じドメインからアクセスがあっても、IPアドレスが異なれば違うサイトとして計算している。そのため、proxyを使っているような所が、ランクインしやすいということになる。もちろん、proxyを使っていれば、実際よりアクセス数は少なくなるわけだが、今回の比較においては、明らかに同じサイトと判断される分有利なのである。
　それでは、最近4週間分のトップ10を示してみる。

1999/3/28-4/24のアクセス量における週別サイトランキング

Rank	4/18-24	4/11-17	4/4-10	3/28-4/3
1	KyotoPneT	MeshNet厚木	阪大レーザー核融合研	KyotoPneT
2	東大情報システム工学研	キヤノン裾野	Hewlett Packerd	キヤノン裾野
3	セイコーインスツルメンツ	オーイーシー	キヤノン裾野	千葉大情報数理
4	Fermi-lab	岡山理科大 電子工学	ホンダエンジニアリング	PSINet
5	OCN	北大 電子科学研究所	ベッコアメ福岡	シチズン
6	アスキー	NTT PC-Com 諏訪	鹿児島大 情報工学	東北大加齢医学研
7	明治大学総合情報ネットワーク	ワコー	デジタルアーツ	生協インターネット大阪
8	RICOH	IIJ4U	藤沢インターネット	九州大学医 耳鼻咽喉科
9	WEB静岡	龍谷大情報NetworkSystem	通商産業省	InfoPepper府中
10	KansaiMultimediaService	OCN千葉館山	アレスネット	DTI熊本

　トップ1に4回中2回も位置しているのはKyotoPneTである。このサイトは京都周りのネットワーク総合体のようだ。色々集まっている分、アクセス数が多いのだろう。
　それでは、週別にコメントをつけてみたい。
3/28-4/3 医学関係が2つランクインしている。おや、九州大学医学部耳鼻咽喉科と言えば、私の一番大好きな「今日の必ずトクする一言」で有名な「バーチャル耳鼻咽喉科」と同じサブドメインである。
4/4-10 通商産業省は公益機関のランクインが少ない中でなかなか健闘している。阪大レーザー核融合研究所はこの2週後のFermi研究所と関係あるのだろうか？
4/11-17 MeshNetの厚木からアクセスされている方が一位である。個人のアクセスというのは非常に嬉しい。この週は個人の方が多い。喜ばしいことだ。
4/18-24 常連だったキヤノン裾野が消え、RICOHがランクインしている。このあと、WEBページは会社の顔色- WEBページのカラーを考える 2 - (1999.04.26) でRICOHのWEBのデザインに苦言を呈しただけに、反応が気にかかるところである。おやおや、ASCIIもランクインしている。

　それでは、3ヶ月前に「私と好みが似てる人」 - analog Windows版用のサブドメイン解析ソフトを作る- (1999.01.24) の時に調べたドメインランキングとの比較をしてみる(こちらは、ドメインランキングであって、今回のサイトランキングとは異なる。今回の場合、同じ人がアクセスしても、IPアドレスが異なれば、違う人としてカウントしていることになる)。

1: canon.co.jp (キヤノン)
2: sony.co.jp (SONY)
3: atr.co.jp (株式会社国際電気通信基礎技術研究所)
4: infocom.co.jp (日商岩井)
5: waco.co.jp (ワコービジネス)
6: odn.ad.jp (オープンデータネットワーク)
7: nttpc.ne.jp (ISP事業者向けネットワーク提供サービス)
8: att.ne.jp (日本AT&T株式会社)
9: saitama-u.ac.jp (埼玉大学)
10: kokushikan.ac.jp (国士舘大学)

　今回と共通してトップ10入りしているのはキヤノンとワコーである。前回も今回も技術系のサイトばかりである。私が技術マニアであるからしょうがないか。それこそ、「私と好みが似てる人」達なのだろう。

次は「できるかな」内の人気ランキングである。こうしてみると、

• 本人が便利なものは、他人も便利(ex./dekirukana/server/)
• 本人はいまいちだが、読まれている(ex./dekirukana/java/)。
• 本人は気に入っているのに、人気がない(ex./dekirukana/harddisk/)。

など、面白いものである。/dekirukana/java/を読んでいるのは「踊る大捜査線」をキーワードにして辿りついた方だろう。/dekirukana/snif/が人気があるのは、セキュリティー意識が高いせいか、あるいは好奇心が高いせいか、どちらだろうか？。

#reqs: %bytes:      last date: file-----: ------: --------------: ---- 4185: 18.07%: 99/05/15 07:49: /   13:  0.04%: 99/05/12 13:51:   /? 1855:  2.18%: 99/05/15 02:33: /dekirukana/java/ 1093:  1.24%: 99/05/15 07:38: /dekirukana/server/  839:  1.74%: 99/05/15 07:08: /dekirukana/snif/  789:  0.68%: 99/05/15 04:01: /dekirukana/dorae/  762:  0.58%: 99/05/15 02:36: /dekirukana/screensave/  633:  0.83%: 99/05/15 05:32: /dekirukana/photoshop/  623:  1.20%: 99/05/15 07:20: /dekirukana/whois/  577:  0.99%: 99/05/15 04:20: /dekirukana/1999/  543:  0.64%: 99/05/14 22:53: /dekirukana/tire/  501:  0.80%: 99/05/15 01:55: /dekirukana/digicame/  435:  0.52%: 99/05/15 00:51: /dekirukana/e55/  435:  1.22%: 99/05/15 02:23: /dekirukana/ufo/  427:  0.37%: 99/05/15 04:15: /dekirukana/ocilo/  392:  0.43%: 99/05/15 06:53: /dekirukana/screensave2/  373:  0.50%: 99/05/15 05:23: /dekirukana/fem2/  321:  0.63%: 99/05/15 02:49: /dekirukana/wavelet/  320:  0.56%: 99/05/15 05:28: /dekirukana/ekisyo2/  279:  0.32%: 99/05/14 22:30: /dekirukana/hamaphoto/  267:  0.37%: 99/05/14 23:25: /dekirukana/real97/  264:  0.36%: 99/05/15 02:28: /dekirukana/karaoke/  263:  0.16%: 99/05/15 02:25: /dekirukana/ocilo2/  260:  0.41%: 99/05/15 01:15: /dekirukana/moire3/  256:  0.81%: 99/05/14 21:07: /dekirukana/onkai2/  256:  0.44%: 99/05/15 01:48: /dekirukana/sacchan/  252:  0.29%: 99/05/15 05:52: /dekirukana/toolplus/  247:  0.24%: 99/05/15 03:02: /dekirukana/server2/  243:  0.63%: 99/05/15 00:17: /dekirukana/bunsukai/  216:  0.42%: 99/05/15 06:52: /dekirukana/haidi/  195:  0.06%: 99/05/15 00:24: /dekirukana/1999_2/  194:  0.41%: 99/05/15 04:05: /dekirukana/kamogawa/  186:  0.38%: 99/05/15 01:02: /dekirukana/bunpu/  185:  0.39%: 99/05/15 04:21: /dekirukana/ufo2/  185:  0.28%: 99/05/15 05:30: /dekirukana/ekisyo/  180:  0.38%: 99/05/15 07:42: /dekirukana/moire2/  171:  0.33%: 99/05/15 02:48: /dekirukana/wavelet2/  169:  0.17%: 99/05/14 20:48: /dekirukana/rocket/  164:  0.16%: 99/05/15 04:04: /dekirukana/dorae2/  160:  0.31%: 99/05/14 15:03: /dekirukana/probe/  155:  0.14%: 99/05/15 07:08: /dekirukana/tamago/  144:  0.20%: 99/05/14 21:53: /dekirukana/onkai/  141:  0.23%: 99/05/13 20:15: /dekirukana/  126:  0.26%: 99/05/15 01:34: /dekirukana/harddisk/  124:  0.18%: 99/05/15 02:03: /dekirukana/watari/  122:  0.29%: 99/05/14 20:49: /dekirukana/webcolor2/  121:  0.59%: 99/05/15 01:29: /dekirukana/moire/  118:  0.10%: 99/05/14 14:08: /dekirukana/hori/  118:  0.18%: 99/05/14 09:21: /dekirukana/bunsukai2/  116:  0.10%: 99/05/14 21:05: /daily/9904.html  105:  0.19%: 99/05/15 07:34: /dekirukana/favicon/  105:  0.24%: 99/05/15 06:29: /dekirukana/log9905/   99:  0.20%: 99/05/14 20:49: /dekirukana/webcolor/   98:  0.05%: 99/05/15 07:08: /dekirukana/photoshop2/   79:  0.38%: 99/05/14 09:58: /index_e.html   61:  0.01%: 99/05/13 18:27: /dekirukana/fem2/math/   46:  0.01%: 99/05/12 19:50: /dekirukana/fem2/math/indexlnk1.html   42:  0.07%: 99/05/12 19:53: /dekirukana/fem2/math/indexlnk4.html   37:  0.03%: 99/05/12 19:51: /dekirukana/fem2/math/indexlnk2.html   33:  0.08%: 99/05/13 18:28: /dekirukana/fem2/math/indexlnk3.html   32:  0.02%: 99/05/14 14:22: /dekirukana/toolplus/readme/readme.html   31:  0.05%: 99/05/12 19:54: /dekirukana/fem2/math/indexlnk5.html   25:  0.06%: 99/05/15 00:22: /dekirukana/harddisk/math/   21:  0.03%: 99/05/12 19:49: /dekirukana/onkai/math/ 4070: 55.84%: 99/05/15 05:52: [not listed: 34 files]

　こうしてみると、興味が発散している作者であることがよくわかる。
　次にログ解析をするのは、おそらく半年先だろう。　その時、健やかに育っているのだろうか？

■インラインスケートの力学 (初心者編)　

つま先立ちの180°ターン

　今回は滑る道具の話である。シャレではないが、私はスキーが好きだ。そして、最近インラインスケートを始めた。使っている道具はこんなものである。

• Dynastar　AssaultSuperior
• Hart　FreeLaunch
• K2 BING AIR

　スキーとインラインスケートの道具の写真を以下に示してみよう。

3種の神器

Dynastar　AssaultSuperior (右) Hart　FreeLaunch　(左)	K2 BING AIR

　それぞれの滑走接地部の長さはDynastar　AssaultSuperiorが185cm程であり、Hart　FreeLaunchが110cmである。K2BING AIRは26cm位だ。

　Dynastar　AssaultSuperiorの長さを1とすれば、Hart　FreeLaunchは長さが0.6程度である。半分とは言わないが、かなり短い。75cmも違う。しかし、この程度の長さにしたくらいではそれほど不安定になるわけではない。特にHart　FreeLaunchは安定性が抜群である。私もゲレンデで普通に滑っている限りでは、遅い方ではないと思うが、特に不安定になることはない。不安定だと感じるのは、コブ斜面で、なおかつ、雪が積もってコブの形状が見えない場所を滑る場合などである。それほど、安定感があるのである。
　そして、スキー板が短いため、ターンのしやすさといったら素晴らしいものだ。1つのコブの上で、2回3回とターンが出来る。

　さて、今回の本題のインラインスケートはと言うと、かなり接地長さが短いため、さすがにスキーに比べて不安定さを感じる。とはいえ、思ったよりも不安定ではなかった。(初心者の頃の)スキーで曲がる時のことまで考えたら、もしかしたら、スキーよりも転びにくいかもしれない。急角度のターンのしやすさといったら、Hart　FreeLaunchの比ですらなく、瞬時の180°ターンなども簡単である(私は上手くないが)。

今回はインラインスケートにおける瞬時の180°ターンの力学について考察を行ってみたい。瞬時の180°ターンに必要なことは以下のようなものである。まず、前向きに進んでいる状態から瞬時に後ろ向きになって進む場合を考えてみる。状態の変化は以下のようなものだろう。

1. 前向きに進んでいる。
2. スケートを瞬時に回転させる。
3. スケートが180°回転した、すなわち、反転したところでスケートの回転を停止させる。
4. そのまま、後ろ向きになった状態で進行する。

　第一印象では、ちょうど180°分だけ瞬時に回転させるというのは、難しいように思われる。ところが、実際にやってみると比較的簡単なのである。やり方は、こういうやり方である。

1. 前向きに進んでいる。
2. スケートブーツの爪先で立つ。
3. スケートブーツが勝手に180°回転し、反転したところでスケートブーツの回転が勝手に止まる。
4. いつのまにか、後ろ向きになった状態で進行している。

　その様子をRealVideo形式にしたものはこんな感じ(モデルはK氏)である。一体、何故勝手にスケートブーツは回転するのだろうか、そして、何故ちょうど180°回転するのだろうか?

　まずは、足を回転させてみると、その回転軸は下の図で紫の円で示したような場所に位置することがわかる。土踏まずと中指の根元の中央辺りである。

足を回転させた場合の中心軸

誰がなんと言おうとこれは「足」

　この図を「インラインスケートのブーツを履いた場合」で示したものを以下に示す。

インラインスケートのブーツを履いた場合の回転軸

　それでは、つま先で立ってみよう。どういうものに近似できるだろうか?

つまさき立ちした場合はどのように近似できるか?

このような状態は

こういうものに近似できる。

　何か見覚えがないだろうか?　そう、台車の足部分である。ここまでくると判りやすい。台車の場合で考えれば、良く実感できる筈である。

台車の足はどうなるか?

台車の足を押すと...

瞬時に回転する。

　それでは、簡単な力学計算をしてみる。「足の回転軸」と「地面に接触しているローラ部分」を拘束系の剛体問題と考えてみよう。インラインスケートのローラは「足の回転軸」と「地面に接触しているローラ部分」を結ぶ方向にはいくらでも回転できる。したがって、転がり摩擦を無視すれば、その方向に関しては「地面に接触しているローラ部分」は地面からは何の力も受けない。しかし、ローラは「足の回転軸」と「地面に接触しているローラ部分」を結ぶ方向と直行する方向には回転することができない。したがって、その方向へ地面から力を受けることになる。滑っている人の速度をVとすれば、「地面に接触しているローラ部分」が「足の回転軸」と「地面に接触しているローラ部分」を結ぶ方向と直行する方向に受ける力はVsinθである(シータは文字化けしそう...)。

計算の説明図

　もうここまでくれば、一目瞭然である。「インラインスケートを回転させる力」であるVsinθ(シータは文字化けしそう...)をグラフにすると以下のようになる。ここで、θ(シータは文字化けしそう...)がPiを過ぎたところで、-Vsinθ(シータは文字化けしそう...)になっていることに注意してもらいたい。

インラインスケートを回転させる力をグラフにすると

　このグラフは縦軸が任意単位の「インラインスケートを回転させる力」を示しており、横軸がインラインスケートの回転軸に対する角度である。ちょっとでも、インラインスケートが回転軸に対して傾くと(θ(シータは文字化けしそう...)=0でなくなると)つま先を後ろへ向かせる方向へ力が働き急激に回転する。そして、つま先が真後ろを向き始めるとその力は弱くなる。つま先が真後ろを向いたところで、その力は0になり、もし回転しすぎると、また、真後ろへ戻す力が働く。そなわち、つま先が真後ろへ向いているのが非常に安定なわけである。

　というわけで、インラインスケートで前進中に爪先立ちすると、何も考えなくてもちょうど180°回転してくれるというわけである。もちろん、後ろへ進んでいるときに回転したいならば、進行方向側のかかとで立てば良いわけである。

　今回の話はひとまずこんなところである。

■スキー場の特殊相対性理論　

ジャンプの飛距離は何メートルだ?

突然ではあるが、HIRAX.NETのドメインレコードを調べてみると、

Record created on 16-Dec-1998.

となっている。自分のドメインのレコードをわざわざ調べたのは、一体いつ取得したのか私自身が忘れてしまったからである。何しろ、「できるかな?」は当初異なる場所での二本立てで公開していたため、私の記憶がごっちゃになっているのである。あと各回の公開順序も実はかなりシャッフルされている。そのため、完全に忘れていたのである。

　「できるかな?」はHIRAX.NETのコンテンツの一部である。しかし、HIRAX.NETの誕生日よりも、「できるかな?」の誕生日の方が実は早い。

• できるかな?東西南北 - 言葉のリズムはマトリクス- (99.10.10)

で書いたように、「できるかな?」はすでに満一年を迎えていたわけである。そしてやっと、本日でHIRAX.NETも満一歳になったわけだ。何はともあれ、目出度いことである。子供の頃やらされた「ドリル」でも3日も続かなかったのに、1年続くとは、正に奇跡である。奇跡はそうそう続かないような気もするが...

　さて、関係ない話はここまでである。今回の舞台は万座温泉だ。なぜなら、先週末私は万座温泉でスキーをしていたからだ。何故だか理不尽な話しではあるが、私は万座温泉でローレンツ収縮を考える羽目になったのだ。もう少し正確に言えば、スキー場で特殊相対性理論を考える羽目になったのである。(先に断っておくが、私はトンデモ話をマジメな顔で言うことが多い。)

万座の帰りに撮影した写真

　話の発端はスキーに行く前に遡る。職場の今年の新入社員であるタカノリ君(仮名)とスキーの話をしていた。彼は秋田出身であり、子供の頃からスキー三昧の生活をしていた。大学に入り京都へ行ってからは、スキーをやる頻度は下がったが、チョコチョコ行ってはいたという。

　そのタカノリ君(仮名)と話していると、彼はさりげなくこう言った。

「10m位のジャンプはよくするスよ。」
「えぇ、本当かぁ〜〜」
「いやぁ、そんなのよくやることじゃないスか？」

10mである。2mの身長の人の5人分である。それは、スゴイ。
　今回のスキー&温泉旅行は職場(と何故か競合他社)の人達30人程で行った。ほとんどの人は、割にスキーは好きな人が多い。従って、スキーも上手い人が多い。その人達に囲まれながら、タカノリ君(仮名)は断言した。

「6,7mは簡単だけど、10mってスゴイなぁ。」
「本当かぁ〜〜」
「えっ、だってただ飛ぶだけじゃないっスか。」

タカノリ君(仮名)、ただ者ではない。

　そこで、スキー場でその確認をしたわけである。場所は万座プリンスゲレンデの下部である。リフトとコースが交差する辺りに、ジャンプできる場所があったのだ。そこで、彼は軽く滑り出し、力一杯ジャンプした。
　果たして、タカノリ君(仮名)は何メーター飛んだのであろうか？　それとも、ただのホラ吹き男爵であったのだろうか？

　ところが、その答えをすぐに書くわけにはいかないのである。なぜなら、タカノリ君(仮名)がジャンプをしてみせた時に事件は起こったのである。

「どうスか！10mはいったんじゃないスか！」
「3,4mしかいってねーぞ！おイ！」

　これは、一体どうしたことだろうか?　しかも、会話はまだ続くのである。

「何でっスか！軽く1秒は宙に浮いてたっスよ！」
「そんなことはねぇぞ！コンマ数秒だろう！」

　ますます不思議なことに、時間感覚すら違っているのである。一体何が起こっているのだろうか？

　私はここで気づいたのである。観測者の間で時間と空間の不一致が生じているのであれば、ここはもちろんアレの登場である。アレと言えば言うまでもない、もちろん特殊相対性理論である。
　そう、万座温泉スキー場ではローレンツ収縮を実感することができるのである。「スキー場でジャンプする」という現象を考える際には、「スキー場におけるhiraxの特殊相対性理論」を導入しなければならないのであった。

　それでは、簡単に「スキー場におけるhiraxの特殊相対性理論」を説明しよう。今回、生じている不思議な現象は以下のようになる。

登場人物

• タカノリ君(仮名)　速度vでジャンプをしている。
• 観客　静止している。

「飛んだ距離」や「飛んでた時間」の観測量されているか

「飛んだ距離」や「飛んでた時間」の観測量

	タカノリ君(仮名)	観客
飛んだ距離	10	3
飛んでた時間	1	0.3

　つまり、速度vで飛んでいるタカノリ君(仮名)の感じる空間や時間といったものは、静止している観客に比べて、いずれも3倍程度に膨張しているのである。

　通常の世界で生じるローレンツ収縮は、速度vで移動している観測者の空間軸も時間軸も

倍縮むのであるが(ここでは光速c=1の単位系を使用している)、
であるが、「スキー場におけるhiraxの特殊相対性理論」では、速度vで移動している観測者の空間軸も時間軸も静止している観測者に対して、逆に

倍に延びてしまうのである。もし、ミンコフスキーの時空図を書いて確認しようとする人がいるならば、座標軸の傾きの変化も通常のローレンツ変換と逆に考えてみてもらいたい(その延長で考えていくと、矛盾があるというご指摘メールはノーサンキューである。)。

　さて、そもそもローレンツ収縮は、マイケルソン - モーリーの実験結果(エーテルの影響が検出できない)を説明し、なおかつエーテルの存在を認めるために立てられた。それは、「運動体はすべてその運動方向に収縮する」という仮説である。その仮説を理論的に完成させたのが、アインシュタインの特殊相対性理論である(考え方としては根本的に異なるが)。

　今回の話の中で「エーテル」に変わるのは、「空気」だろうか? いや、違う。私はむしろ、速度そのものであると、考える。つまり、特殊相対性理論と同じである。スピードを出して飛んでいるという感覚、速度が与える感覚の変化、すなわち速度そのものが、「スキー場におけるhiraxの特殊相対性理論」を要請するのである。

　今シーズン、スキー場でせっせとジャンプをする人がいるならば、ぜひ「スキー場におけるhiraxの特殊相対性理論」について考えてみてもらいたい。

　このWEBへ来る人の中で、同時期に万座温泉スキー場にいた人はいるだろうか?12/11.12に万座温泉スキー場のプリンスゲレンデの下部でジャンプにいそしんでいたのが、私達の一行である。そして、その中の一人(ショートスキーでせっせと飛び跳ねていたヤツ)はこんなことをずっと考えていたのである。

　さて、実際のタカノリ君(仮名)の飛距離がどの程度であるか知りたいと思う人も多いだろう。オマエらの主観的な評価でなくて、実測定した距離を教えろと思う人も多いに違いない。
　「絶対的な基準など存在しないから、そんなことは私はわからない。」と言い放ちたいところだが、タカノリ君(仮名)の名誉のために書いておく。彼が飛んだ距離は、2m弱のスキー板で4本分はあった。実は、タカノリ君(仮名)の基準が一番正しかったのである。彼は、「やるときはやる有言実行の人」なのであった。

■6502と並列計算とムーアの法則　

人間のクロック&スケールアップ

　「物理の散歩道」を読み直していると、とある文章に興味を覚えた。

• 第五物理の散歩道　ロゲルギスト著　岩波新書

の中の「通信を考える」である。この本は、何度読み返しても新鮮である。

　「通信を考える」の中の興味を惹かれた部分は「信号の伝わる速度と距離と処理速度の関係」を論じている部分だ。例えば、計算機は処理速度を高めるためには回路の大きさを小さくしなければならないとか、人間の頭脳の働きの速さから集団生活の広がりの限界について論じているのだ。例えば、

• 計算機の演算速度の時間スケール -> ナノ秒 = 10^-9s (クロックで考えると、1GHz)
• 人間の演算速度の時間スケール -> サブ秒 = 10^-1s (クロックで考えると、10Hz)

ということから、計算機の大きさが0.12=1.2x10^-1m角として、地球の直径が12000km=1.2x10^7とすると、その空間スケールが先の時間スケールと同じ比すなわち10^8であると言及しているのだ。

　つまり、通信の速度が光速度であるとして、演算の単位クロックの間に通信が行われなければならないとするならば、計算機の時間・空間スケールと人間の時間・空間スケールは等しいだろう、という推論だ。
　
そして、さらにロゲルギストの想像は広がり、並列計算についても論じている。

　計算機が東京と大阪に離れて置かれていて、通信をしながら作業をするとしたら、人間の場合にはそれと同じ条件というのはどんなものだろうか、と彼らは考える。それは、光の速度で55時間、ちょうど冥王星の軌道直径の5倍程度の空間スケールになる、と論じている。それ以上、離れた場合には演算の過程を共に行うのは無理ではないかというのである。

　こういう文章を読んでいると、この文章が作られたのが30年以上前であることを忘れてしまいそうである。この人達の思索の自由さに憧れを感じてしまう。この人達は、頭の中にタイムマシンにでも持っているのだろうか、と感じてしまうのだ。

　ところで、私がコンピューターをいじるようになった頃は、Apple][の時代だった。といっても、私はお金があふれていたわけではないので、ＸＸＸ電子でAplle][のコンパチ基盤を買って組み立てて使っていた。その基盤上の6502は1MHzで動いていた筈だ(あぁ、I/Oの6809派vs6502派の論争が懐かしい!)。

　それから20年程たち、CPUのクロックスピードは1GHzを越えようとしている。20年で1000倍である。そして、その集積度は、ムーア(GordonMoore)の法則の「半導体の性能と集積は、18ヶ月ごとに2倍になる」に従っている。

　それでは、人間はどうだろうか？人間の脳味噌のクロックがどの程度であるか測定されているかどうか、素人の私にはよくわからない。しかし、WEB上のデータとしては、例えば

• Mayo's Profile( http://www.ceres.dti.ne.jp/~mayo/profile.html )

というようなデータがある。ここでは、1演算/秒である。ロゲルギストの用いたものが10演算/秒である。これらは、かなり近い値と言える。もちろん、Mayoさんの演算速度はロゲルギストよりも一桁下であるわけだが、ロゲルギスト達と比べては可哀想というものだ。それに、おそらくMayoさんは謙遜しているのだと思われる。実はもう少し速いのだろう。それに比べて、私などは、二桁の演算(しかも足し算でも)になると1演算/秒もこなせるかどうか判らないくらいである。

　ロゲルギストの時代、すなわち30年以上前、から現在のMayo's Profileの値がほとんど変わっていないように、人間の演算スピードは変わるようなものではない。それは、そうだろう。ヒトのクロックスピードや集積度といったものは、変えるわけにはいかない。当然である。CPUと違ってプロセスルールを変化させるというような訳にはいかないのだ。

　それでは、演算性能を上げようとしたらどうするだろうか？そうなると、並列計算を行うのが自然だろう。単独のCPUの性能を上げるわけに行かなくても、共同作業を行えば、演算性能を上げることができる。

　現代はほとんどの作業が共同作業で行われる。また、その共同作業も大人数が関わるようになってきている。それは、どんな業種でも同じだ。一人では、なかなかできないことが多くなっている。
　それら共同作業、すなわち並列計算、を行う人達(例えれば並列計算機における各ノード)を増やし、それらの間の情報転送をすばやく行うことが多くの作業(計算)を行うための手順だろう。

　そこで、

• サンタが街にやってくる　- 複数サンタクロースの巡回問題- (1999.12.24)

で用いた

• 人口増加( http://www.t3.rim.or.jp/~kabutoya/KABHTML/Yoi/2-1.html )

のデータをもう一度眺めてみることにしよう。

最近500年間の人口の変化

　なるほど、人間界の並列計算機におけるノード数は増加している。そして、各ノード間の通信速度を調べるために、まずは、

• 来て、見て、触って、情報伝達
• ( http://www.f-jhs.fukuoka-edu.ac.jp/3-3/jyoho.html )

などの情報から、適当な通信の歴史を調べてみる。

西暦　内容
-4000 のろし
-2400 伝書鳩
-2300 馬による伝令制度
1837 モールス電信機
1876 ベグラハム=ベル電話機
1909 グリエルモ=マルコーン無線電話機
1973 Ethernet XeroxPARCで生まれる。(ちなみにEther=エーテル)
1979 DIX規格=10Mbps
1992 FastEthernet=100Mbps

　これを全部転送速度に直してみる。といっても、よくわからない部分も多いので、私が適当に決めてみる。それでは、その変化を示してみよう。とりあえず、ここ200年位の間のものを考える。

西暦　内容
1837 モールス電信機 = 2bps
1909 グリエルモ=マルコーン無線電話機=10kbps
1979 DIX規格=10Mbps
1992 FastEthernet=100Mbps

　という感じだ。グラフにすると、

最近200年間の情報伝送速度の変化

こんな感じである。対数グラフにおいて直線的に情報伝送速度が速くなっている。この関係は結構きれいである。
　別に意図してこういう数字にした訳ではないのだが、不思議なことである。
　このようにして、人間(ノード)間の転送レートが高くなることにより、先のような人口増加に伴うトラフィック増加をしのぐことができていると考えることもできるかもしれない。そして、人間達の共同作業、すなわち並列計算、を行うだけのバススピードを確保しているのである。

　最近、会社組織などで分社化とか事業分割とかの話題をよく耳にする。こういった時に、分割における時間と空間のスケールはよく考える必要があるだろう。分割が有効なのは、ほとんど独立なものを分割する場合のみである。並列計算における領域分割などと同じだ。

　共同作業がほとんどなく、結果のみをやりとりすれば良いような場合には分割による効果はあるだろう。その一方で、同じ事業・作業を行っているところが、離れていては作業の効率は上がらない。もし、技術系の会社でそのようなことを行うのであれば、事業や部署を並列化した際の真面目なシミュレーション位は行うべきだろう。いや、別に深い意図はないけど。

　こういったことは「新・闘わないプログラマ No.109　時代錯誤」に書かれていることとも少し似ているような気がする。

　さて、1999/12/30-2000/1/1は野沢温泉で温泉&スキーである。2000年問題で会社に泊まり込む人も多いが、私はスキー場で泊まり込みである。同時期に野沢温泉に行く人がいるならば、ぜひ一緒に「スキー場の特殊相対性理論」について討論したいと思う(スキー場で)。

■パノラマ写真と画像処理　Pt.1　

パノラマ写真を実感する

　「パノラマ」という言葉は何故か大正ロマンを感じさせる。かつて、流行ったパノラマ館や江戸川乱歩の「パノラマ島奇譚」という言葉がそういったものを連想させるのだろう。私も自分で写真の現像・焼き付けをしていた頃は、フィルム一本まるまる使ってベタ焼きでパノラマ写真を撮るのが好きだった。

　そういう癖は持ち歩くカメラが「写るんです」と「デジカメ」へ変化した今でも変わらない。例えば、

• スキー場の特殊相対性理論 - ジャンプの飛距離は何メートルだ?- (1999.12.16)

の時に撮ったこの写真もそうである。

1999年12月の万座温泉

　そしてまた、次に示す写真もそうだ。これは1999年夏頃の早朝に箱根の湖尻で撮影したものである。360度のパノラマを撮影したものだ。

1999年夏頃の早朝に箱根の湖尻で撮影したもの

　観光に行った先で撮影したと思われるかもしれないが、残念ながら違う。出勤途中に撮影したものである。豊かな自然がありすぎて、涙が出そうである。

　パノラマ写真としては、こういう景色を撮ったものも良いが、人が写っているものも良い。私の勤務先がこの大自然の中に移転してくる前、都会の中にあった頃に居室で撮ったパノラマ写真などはとても面白い。窓の向こうにはビルが見えたり、周りに写っている人ですでに退職した人が何人もいたりして、涙無しには見られない。

　もちろん、こういった写真はパノラマ写真で楽しむのも良いが、もっと実感できるものに加工しても楽しい。私がかつて都会の居室で撮影したものは、当時はAppleのQuicktimeVRのムービーファイルに変換して遊んでいた。今はもうない居室の中をグリグリ動かすのはホロ哀しいものがあり、とても味わい深かった。

　ところで、WEB上でそういうパノラマのVRファイルを見せるにはどうしたら良いだろうか？もちろん、AppleのQuicktimeVRを用いれば良いわけではあるが、プラグインが必要である。私はQuicktimeは好きであるが、ブラウザーのQuicktimeのプラグインは嫌いである。WEBを眺めているときに、「Quicktimeのアップグレードはいかがでしょう？」というダイアログが出ると、少しムッとしてしまう。そこで、Javaを使うことにした。いや、もちろんJavaをサポートしていないブラウザーもたくさんあるが、こちらの方がまだ好きなのである。

　そのようなパノラマのVRを実現するJavaアプレットには、例えば

• Panoramania
• http://www.lamatek.com/lamasoft/Panoramic/test.html
• Ｊａｖａアプレット（パノラマver1.1）
• http://village.infoweb.ne.jp/~fwbc6098/java/panorama/panorama.htm
• TheVRApplet1.0
• http://www.physik.uni-greifswald.de/~jonas/VRApplet/VRApplet.html
• how toinsert the panorama show (java applet) inside your home page ?
• http://persoweb.francenet.fr/~carl/brique/exapano1.htm

といったものがある。今回は先に示した「1999年夏頃の早朝に箱根の湖尻で撮影したパノラマ写真」を"Panoramania"を使って実感してみることにする。かなり重い(私のPCではかなりしんどいようである)Japaアプレットであるが、それを以下に示す。箱根の朝を実感して頂きたい。マウスでグリグリと言いたい所であるが、これがサクサク動くPCなんてそんなにあるのだろうか？
「1999年夏頃の早朝に箱根の湖尻で撮影したパノラマ写真 VR」

　さて、ここまでは単なる前振りである。本題は、実はこれから始まる。先日このようなメールを頂いた。

　私はWindowsを使っているのですが、AppleのQuicktimeVRに興味があって、QuicktimeVRのパノラマ・ムービーを作っています。しかし、素材となる画像の作成に四苦八苦しております。ご承知の通り、

1. ライカ版カメラに２４ミリ広角レンズをつけて、
2. 三脚にパノラマヘッドをつけて、ぐるりと周囲を１２枚撮りして、
3. 現像、プリントし、
4. スキャニングして、ステッチャソフトでレンダリングし、
5. それをMacintosh上でMake-QTVR-Pａｎｏｒａｍａにドロップして、
ようやく１枚のパノラマmovファイルができるわけですが、最初のカメラ撮影で、タイムラグのため、歩行者など、動きのあるものがうまくパノラマ化できません。

　その場合には、スリットスキャンカメラを入手し、それをカラープリントする設備を準備すればいいのでしょうけど、高価です。

　そこで、

1. ８ミリビデオに広角レンズを付け、
2. ９０度横倒しにして、１０秒程度で１回転するようにステッピングモーターで駆動するパノラマヘッド（自作）に乗せ、
3. 高速シャッター撮影し、
4. マックのＡＶ機能で円周１２枚の静止画を取り出
5. し、
パノラマ化しています。

　長々と分かりにくいことを書きましたが、要は、「マックで動く電子スリットスキャンソフト」をなんとか作っていただけないでしょうか？もし、そのようなソフトがあれば、

1. ８ミリビデオを横倒しにして、
2. モーター回転するヘッドでぐるりと３６０度撮影し、
3. その撮影した動画ファイルの、各フレームから走査線にして数本分を抽出し（インターレースで２５６本のうちセンター１２８本目の前後数本の走査線分）、
4. それを貯めて１枚のｊｐｇファイルにする、
5. そのJPEG画像をMakeQTVRPanoramaの入力にして、パノラマムービーを作る、
ということが簡単にできるようになります。こういうソフトがあれば、だれでも、旅先などで、ビデオを横倒しに持ってぐるりとスピンするだけで、あとはAVマックとパノラマ化ソフトで簡単にQuicktimeVRパノラマファイルが作れるようになると思うのですが…

　これはとても楽しい話である。しかもとても簡単なことなので、遊んでみることにした。

　まずは、答えを先に書いてしまおう。私が作らなくても、

• NIH-Image (MacOS)
• ScionImagePC (Windows)

というソフトがある。これらのソフトであれば、上に書かれている

• 複数画像(動画)からの走査線抽出

は実現できる(ファイルサイズが少々不安だが)。特に、NIH-Imageであれば動画ファイルを読み込むことができる。つまり、Mac上で簡単に処理ができるのである(と、書いた。しかし、後日気づいたが256色の画像でなければ、駄目だった。どうしよう？)。ScionImagePCはNIH-ImageをWindows向けにポーティングしたものである。Macを科学技術に使う人であれば、NIH-Imageを知らない人はいないだろう。

　ScionImagePCの動作画面を以下に示す。NIH-Imageとほぼ同じである。

ScionImagePCの動作画面

　これらのソフトのStack-Slice機能を用いれば「複数画像(動画)からの走査線抽出」ができる。その使用例と、その面白い座標軸変換について考えてみたい。しかし、このページは少々重くなってきた。まして、走査線の抽出の話は使用画像が多くならざるをえない。そこで、次回、詳しく使用例を紹介することにする。よく、次回といったまま数ヶ月経つことがあるが、今回は大丈夫である。少なくとも数日後には登場することと思う(多分)。

　あれっ、ここまで書いてからinfoseekで検索すると、

• パノラマ写真のひっみっつっ!
• http://www.imagica.com/nomad/sig98/hitachi/

なんてソフトがある。しまった、先に検索すればよかった。けど、まぁいいか。これはWindows上のソフトのようだし。とりあえず、次回へ続く。