最近は特になにもしていないので、書くことがたまりません。
なので先月の夏コミに関する話を。
東京ビッグサイトに行くときは「新交通ゆりかもめ」をいつも利用します。そして帰りはだいたい水上バスを利用します。
(徒歩でレインボーブリッジを渡ったこともありますが・・・)
8~9年前から帰りは水上バスのパターンに落ち着いたので、水上バスに乗るとなんとなく達成感を感じます。
水上バスは東京ビッグサイトから日の出桟橋(浜松町付近)の航路が利用できます。
Rollei35 + Kodak ELITE CHROME 100
水上バスは発着時間の間隔は長いのですが、鉄道のように混雑感が少ないんですよね。
安全上定員以上は乗せられませんし。
そして何より東京湾はとても眺めが素晴らしいのです。
東京って綺麗ですよね。本当にそう思います。
と言うわけで、イベント帰りには水上バス、オススメです。
#あ、ゆりかもめも空いている時、特に夜間に乗ると夜景がとてもキレイです。
#近年汐留付近の開発が進んでファンタジーの世界のような光景が見られます。言い過ぎか。
ってわけで、結局1年以上待たされてやっと出ました。5D後継機。
http://cweb.canon.jp/camera/eosd/5dmk2/index.html
スペックは概ね5Dからの妥当な進化ですね。
細かいところですが、Kiss系で使っていたリモートコントローラーに対応したのが小さなサプライズです(w
(これかなり便利で値段も安いので上位機種にないのが心配の一つでした)
キヤノンが言っていたサプライズってのは動画撮影でしょうか。
動画は不要って気もしますが、EFレンズで撮影する動画は少し興味沸きますね。ハード的にさほどコスト増でも無いでしょうから良い付加価値追加だと思います。
連写が3.9枚/秒ということにガッカリしてる人が多いようですが、フルサイズはミラーも大きいし、画素数も上がったし、上位機種との差別化もあるので仕方ないんですかね。
個人的には連写はほとんど使わないので問題ありません。
で、それで発表日(昨日)の昼間のうちに予約注文してしまいました。
5Dでも十分だったんですが、「もう出るぞ」「もういい加減次出るぞ」と脅されて1年間買えなかったww
しばらく待てば値段が下がるかもしれませんが、それよりも欲しい時にまた品薄で買えないとか悔しい思いするのも嫌なのではやめに注文しました。
楽しめる期間が長くなりますしね。
念願のフイルムサイズ。発売日が楽しみです。
なんとなくフイルムカメラで撮影。
CONTAX T3 / FUJICOLOR 100
今更ですが、インターネット普及しましたね。
そしてそれが世界を狭くしてしまいました。
それは大変便利ではありますが、広い世界もやっぱり良かったな、なんて時折思うのは身勝手でしょうか。
10人に注目されれば満足だったことが、今では100人に注目されてもあまり達成感が無かったって話をまわりで耳にします。
10人が注目していた事柄は井戸の中にある僅かで希少価値を認めてくれる注目でしたが、その100人は海原を広く浅く見渡して、緩やかに注目しているからかもしれませんね。
イベント参加などすると10年前からの変化を特に感じる部分です。
とはいえ、世の中の情報化は世の中には色々な人がいる、ということを広めてくれました。
サブカルチャーは広く浸透するようになったし、多様な趣味を是とする風潮は文明的で気持ちの良いものです。(多様な趣味は昔から存在しましたが、認知度は上がった気がします)
一つのことにみんなで夢中になった、バブル以前の時代もいいですが、今の時代、これからの時代も捨てたもんじゃないですよね。
自分の20代はまさにインターネットの黎明期から今にいたる時代です。なかなか絶妙に良いタイミングで生まれたものです。そしてそこに自分時間の多くを捧げてきました。
なかなか不幸な過ごし方だと思っていた時もありましたが、今思えばとても良かったと思えます。
まとまりませんが、そんな感じです。
秋葉原駅上より(やっぱり一番思い出があるのは秋葉原w)
EOS Kiss Digital X + EF24-105mm f/4L IS / ISO100 / 15秒
エスカレーターの歩行利用は危険らしい。
確かに公共交通機関では健常者ばかりではないし、荷物がある人もいるので危険かもしれない。
ただ、混雑具合から「歩かない」ってのが非現実的な場面も通勤中にはあるような気がする。
どうせ駅員が押さないといけないような満員電車の時間帯なんかは立ち止まってたら返って危険な気もする。(人があふれて)
そんな中、「みんなが止まって利用したほうがむしろ効率が良い」という意見も耳にした。
たしかにそういう場面もある気がする。
気になったのでちょっと計算してみた。
<仮定>
だいたい毎分70ステップくらいらしい。
なので以下のようにする。
■1分あたりに何人が新たに乗ることができるか=平均サービス率μ
・止まって乗る場合
μ=70[人/分]
・歩く場合
μ=100[人/分]
移動速度は2倍近いとは思うが、すべてのステップに立てなくなると仮定して速度を少し落とした。
*数字は片側のレーン。両側なら倍。
■1分間に平均何人到着するか=平均到着時間λ
λ=90人
■エスカレーターの長さN
N = 30ステップ分
<理屈>
まず、待ち行列をどのように仮定するかだが、情報処理試験などで良く出てくる[M/M/n]モデルを仮定する例が多いようだ。
[M/M/n]は、窓口n個に、ポアソン分布に従って何かが到着し、指数分布に従った処理時間で処理されるというモデルである。
簡単に言えば、n個の窓口があって、そこにランダムに人が来て、ランダムの時間で用事を終えるというモデルである。
エスカレーターの場合、特に歩行しないで乗る場合にはステップに一人づつ立つという前提なので処理時間は指数分布ではないはずであるが・・・。
ま、とりあえずは検証のために[M/M/n]モデルで計算をしてみる。
まず両側に止まって立つ場合だが、[M/M/1]の待ち行列が2つあると考えるか、[M/M/2]の待ち行列として考えるかによって効率が異なる。
多くの場合は左右それぞれに列を作ってしまっているので[M/M/1]が妥当であろう。
[M/M/2]モデルでは窓口による処理時間のバラツキを効率化できるわけだが、今回のケースでは上記のようにあまり意味がない。
具体的には列の片方が偶然空いてしまうときに利用効率が著しく悪化するわけだが、現実的にそのような場合は人は列を移動するので発生しないはずである。
両側を歩行せずに利用する方法を<止まって利用>と呼ぶことにする。
一方、片側を歩行レーンとする場合は単純に二つの独立した窓口があると考えれば良い。
左右どちら側を歩行するかは地方によって異なるが、便宜的に左側を歩行しないレーン、右側を歩行レーンとする。
この例の場合、歩行したくない人と歩行したい人がどのくらいの割合で存在するかが結果に大きな影響を与える。
割合を1:1とした場合、両側を止まって使う場合に比べて、レーンごとの利用人数がちょうど同一となる。
つまり待ち時間は同一となるはずである。
片側を歩行レーンとする利用方法を<歩行利用>と呼ぶことにする。
最初の仮定を用いて計算した結果をグラフにすると以下のようになる。
エスカレーターに乗るまでの待ち時間の比較
このグラフはエスカレーターに乗るまでの時間のみを示したもので、実際にエスカレーターの通過を終えるまでの時間はこの値にエスカレーターに乗っている時間を足したものになることを注意する。
(つまり、歩行レーンを歩いた人はすぐ到着するし、止まって乗った人はなかなか到着しない)
<歩行利用>では右側を歩く人の割合が少ないほど、左側の効率は大きく下がる。
具体的には左側に止まって乗る人の割合が50%を超えると<止まって利用>に比べて待ち時間が増える。
この結果だけを見ると<止まって利用>の利用が安定して有利であるように見える。
ただし、このグラフはエスカレーターに乗るまでの時間のみを示したもので、実際にエスカレーターの通過を終えるまでの時間はこ
の値にエスカレーターに乗っている時間を足したものになることに注意が必要である。
また、今回は比較的混雑した状況を想定したが、空いている場合は以下のようになる。
この例はλ=20とした場合の例である。(凡例は上のグラフと同じ)
もう少し空いている状況のときのグラフ
わざと判りにくくしたわけじゃなくて、上とスケールを同じにしただけです・・。縦軸が(秒)なので、そもそも空いている時には待ち時間はほとんど存在しない。
この結果から、<歩行利用>と<止まって利用>の待ち時間の差はほとんどなく、<歩行利用>を許容すれば右側を歩行した人たち
の所要時間が短くなり、かつ止まって利用する人の待ち時間もほとんど変わらないということがわかる。
逆にさらに混雑させた場合はどうであろうか?
λがエスカレーターの処理能力である70を超えた場合、<止まって利用>では列をさばくことができなくなる。
つまり<止まって利用>の場合の平均待ち時間は無限大となる。
「<止まって利用>のほうがほとんどの人にとって効率的」という条件は結構狭いことがわかる。
ある程度空いている状況ではそもそも待ち時間がないし、ある程度混雑した場合は歩く人がいないと列が伸びる。
さて、ここまで来ておいてなんだが、やはり待ち行列のモデルがちょっとおかしいと思う。
上記で計算された待ち時間はどれも数秒であり、日常生活の経験からは待ち時間はもっと長いことがある。
といって、仮定よりも混雑したケースを想定すると待ち時間が無限大になってしまう。
この原因は人がエスカレーターのところにやってくる分布をポアソン分布で仮定したことにあると思う。
特に混雑するケースというのは駅のホームなどで電車が到着したタイミングなどである。
最近はもともと階段であったスペースをエスカレーターに置き換えてしまい、階段が存在しない通路もみられ、エスカレータに長い行列ができる。
<仮定>
n人が一気に到着し、全員がエスカレーターを利用する。
人数が二つの列に分かれるのでμは2倍。
最後まで処理する時間の半分が平均時間となるので2で除算する。
<止まって利用>
Tw= n / (μ×2) /2
Tw= 100/(140/60) /2 = 約21秒
平均待ち時間は約21秒。
<歩行利用>
[左]
TwL=n/2 / μL /2
TwL = 100/2 /(70/60) /2 = 約21秒
平均待ち時間は約21秒。
[右]
μR
TwR=n/2 / μL
TwR = 100/2 /(100/60) /2 = 約15秒
平均待ち時間は約15秒。
別のモデルの場合のグラフ
なんとも判断は難しいが、、
また、このグラフは「乗るまでの時間」であって、歩行した人の移動時間はかなり短縮され、かつ歩行しない人への待ち時間の影響
もほとんど無い。
逆に言えば待ち時間に対する影響は<歩行利用>から<止まって利用>に変更してもさほど無いとも言える。
■まとめ
・歩行する人の割合が一定以下であり、かつ程好い混雑具合の場合は、「止まって乗る」ルールが有効。
その条件はかなり狭いが、具体例をあげれば東京駅のJR線ホームへのエスカレーターは慢性的にそのような状況と個人的観測から
推測する。
「止まったほうがみんな効率的」というのは、このような状況を見ての意見だと思われる。
これは、荷物を持った人が多く、長いエスカレーターで起こりやすいと考えられ、安全の面からも「止まって乗るルール」にすることが有効であると思われる。
・一方、一定以上に混雑した場面で、かつ歩行する人が一定数見込まれる場合は、片側歩行にした方がほとんどの人にとって効率が良い。
特に階段がないエスカレータのみ設置の駅のホームなどは顕著である。この場合、混雑が一定以上になると、歩行を許容しない場合は永遠に待ち行列が長くなり、転落事故になるだろう。
ただ、エスカレータを歩行することは近年、安全面から問題視する声が大きい。安易に階段をエスカレーターに置き換えず、階段を併設することが有効であると個人的には考える。
なお、「片側を歩くのはかえって非効率」というの意見は上記の結果から正しいとは言えないと思う。
この結果が成り立つ条件はかなり限定的である。
結局どうしたら良いのかは判らない。
通行量の多いにも関わらず安易に「歩行禁止」をうたって責任逃れしてもルールは守られず結局危険な状況を作ってしまう。
設置スペースが許す場所では、通路の全てをエスカレータにせず、階段の併設が良いと思う。エスカレーターに止まってのるより階段ほうが効率は良い。急ぐ人は階段を使えばいい。
または時間帯によってルールを変えることもひとつの解かもしれない。
■結論
・「やっぱり効率だけなら歩いたほうがパフォーマンスが良い」
・・・そして色々計算が面倒だったわりには結果がぱっとしない。。
tDiaryがかなり重たいのですがRAA:erbscanを入れると良いらしいので入れてみました。
Windows(i386)環境でやったら微妙に面倒だったので手順をメモ。
まずVisualStudio6.0を今さら入れるのも面倒だったのでいつも利用しているVisualStudio2005 Professional Editionを利用しました。
他のバージョンでも問題ないと思います。
VisualC++6.0だとMakefileの修正などは不要かもしれません。(未検証)
なお、rubyはi386-mswin32(Version 1.8.7)、Cドライブ直下にインストールしています。
VisualStudioもCドライブに普通にインストールしています。
環境に応じて適宜読み替えてください。
■Makefileの生成
以下を実行。
>ruby extconf.rb
Makefileが生成される。
■Makefileの修正
Makefileの42行目くらい
CFLAGS = -MD -Zi -O2b2xg- -G6
という行の-MDを-MTに変更する。
これを変更しないとVisualStudioが無い環境で実行できないバイナリになってしまう。
■rubyのヘッダの変更
ファイル「C:\ruby\lib\ruby\1.8\i386-mswin32\config.h」を変更。
一番最初の行にVCのバージョンチェックの部分があるので変更する。
デフォルトだと_MSC_VER==1200(=VisualC++6.0)以外はエラーになる。
#if~#endifまでを削除するか条件式を「_MSC_VER < 1200」とかに変更する。
■コマンドプロンプトの準備
コマンドプロンプトを開いて以下を実行。
>C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat
これをしないとCL.exeなどが利用できない模様。
もしパスが通っていないならばCL.exeにもパスを通しておく。
例:
>path=%path%;C:\Program Files\Microsoft Visual Studio 8\VC\bin
■Makeを実行
上で準備したコマンドプロンプトの窓からnmakeを実行。
>nmake
動かない場合は1個前の「コマンドプロンプトの準備」のところもう一度チェック。
うまくいけば「erbscan.so」が出来上がる。
なんか間違えていてMakeしなおす場合はnmake cleanで一度ファイルを消す。
■インストール
installを実行。
>nmake install
これでインストールされる。
rubyのフォルダごとサーバマシンに持っていくか、実際にはerbscan.soとerb_fast.rbが入るだけなのでバージョンが一致していればこの2つをrubyのフォルダにコピーすれば良い。
コピー場所はそれぞれ、
.\ruby\lib\site_ruby\1.8\i386-msvcrt
.\ruby\lib\site_ruby\1.8
これで動いていると思うのだが、効果のほどは不明。
若干体感速度が上がったような・・・?
§ kazatachi [水上バスって、自分としては懐かしいイメージ。 小学校~高校までは展示会行く時は水上バスに乗ってたんだよね。 親に連れ..]
§ Suika [僕も既に懐かしい感じではありますがねw いい親だなー]
§ kazatachi [乗りたくなってきた。ムダに乗ってこようw]
§ Suika [乗るだけなら浅草行きもお勧めです。]