前世紀最後のコラムでは、代々木駅の構造的な問題を紹介した。 人の流れが交差するような設計になっているという話である。 その後の情報によれば、このようなデンジャラススペースは結構よくあるらしい。 チェックポイントの配置を少し工夫すれば問題解決しそうな場合もあるが、 もしかすると、どうしても衝突が避けられない場合もありそうだ。 その場合、衝突を最小限にするにはどうすればよいかという問題になる。

※ 前世紀は2000年12月31日で終了した。

最近のビルの設計時には、 室内の空気の流れをあらかじめシミュレーションで確認しておくという噂だが、 同様に、都市設計においても人の流れをシミュレーションで把握しておくというプロセスが必要だと思う。 いや、もしかすると、既にやっているのかもしれないが、現実は厳しいようだ。

§

地下鉄といえば、その後、また面白いものを見つけた。 いや、単なる時刻表である。 今まで一部開通していた都営大江戸線が12月12日に全線開通するというので、 ダイヤが変更になり、新しい時刻表が配られていたのだ。 代々木駅の時刻表は fig.1 のようなものだ。 これを裏返せば、fig. 2 のようになる。

---- fig.1 ----

  (ってすみません、図がどこかに行ってしまったので探索中)

---- fig.1 end ----

---- fig.2 ----

  (これも行方不明)

---- fig.2 end ----

別に何ということはない、普通の時刻表のように見える。 このデザインで一つ優れているのは、 時刻表の所だけ切り離せるような位置に表が印刷されていることである。 言い換えれば、この時刻表は、表の部分と広告の部分から構成されているが、 表の時刻表が印刷されている個所のちょうど裏側は、やはり時刻表が印刷されていて、 それ以外が広告スペースになっている。 つまり、広告部分を切り取ると、表裏合わせてちょうど時刻表だけになるように作られているのだ。 というか、この程度がクリアできないようでは話にならないのだが。

※ 広告を出す側にとってみれば、 広告だけ切り取られるのは面白くないのだ。

面白いというのは、この時刻表を使おうと思ったところから始まる。 この種の小さな時刻表は、大雑把に考えて、2通りの使い方があると思う。 一つは、定期入れに入れたりして、携帯して使う場合。 もう一つは、家庭のホワイトボードなどに貼り付けて見る場合。 それにしてはちょっと小さいかもしれませんが。

問題は、この時刻表をどうやって定期入れに入れるかというものである。 切り離してもよいが、とりあえず折って入れることを考えてみる。 実際に折るとどうなるだろうか。 最もよく見る面が表になるように折ってみる。 どの面を見る確率が高いかは、ケースバイケースなわけで、一概には決まらないが、 とりあえず、全ての面を同確率で見る場合よりは、 特定の面を高い確率で見る場合の方が圧倒的に多いだろう。 なぜ?

よくある場合として、定期券を使ってA駅～B駅間を往復している利用者を考えてみる。 この人はA駅においては常にB駅方面の電車に乗るはずだし、 B駅から乗れば常にA駅方面の電車に乗ることになる。 つまり、両端が決まってしまえば、必要なのはそこから片方の情報だけ、 ということになるはずだ。

※ A駅の時刻表には、B駅方面とC駅方面の2種類の情報があるが、 定期がA～B間なら、C駅方面への情報は不要だ、という話だ。

ということを想定して、仮に、A方面、B方面の2種類の表があるとしよう。 この人が主に見るのはA方面の表だとする。 という前提を踏まえて、この時刻表を見てください。 あなたは、これをどうやってパスケースに入れるか。

実は、私ですが、パスケースに入れたりしないで、 そのまま無造作に裸のまま胸ポケットに入れたりすることの方が多いのだが、 それはそれとして、パスケースにこの時刻表が そのまま入ればいいのだが、実はサイズが問題になる。 どちらかの方面の平日、土日のいずれか片方の面で、ちょうど定期券のサイズになっているのだ。 つまり、4面のうち1面を選択しなければならない。 そこで、とりあえず、 一番よく使うと思われるA方面の平日の表が見えやすいように透明のポケットに入れることにする。 これは簡単で、例えば、時刻表の部分だけ切ったものを2つに折ってやればよい。 ここで問題です。この人がもう一つ見たい面があるとすれば、どれだろうか?

※ パスケースを持っていないのである。

もしかすると意見が分かれると思うが、私の経験としては、 A方面の土日の表だと思うのだが、いかがでしょうか。 違うといわれたらこの後の論理が総崩れになってしまうのだが、 とりあえずこれもそうだと仮定してください。 経験的にはそう外れていないと思う。

会社はA方面にあって、土日のレジャー系の場所がB方面、 ということは十分にあり得るのだが。

そこで、A方面の土日の表をパスケースに入れるとして、 両面透明のパスケースだとどうなるでしょう? 単純に折ってパスケースに入れると、 A方面の平日の表の裏はB方面の平日が見える状態になってしまう。 だから、A方面の土日の表を見るためには、パスケースから一旦出してやらなければならない。 面倒でしょ。 これを解決するのは簡単な話で、折るのではなく切り離して使えばよいのだ。

じゃあ何も問題ないじゃん?　ということになるのだが、その通りだ。 ただ、時刻表を印刷するやり方は他にもある。 例えば、Fig.3 のように、A方面の平日、土日、というように並べて印刷すれば、 折り曲げた時に実にいい感じになるはずだ。 しかも、ホワイトボードに貼り付ける場合まで考えると、ますますこの方式の方が便利になりそうだ。

---- Fig. 3 ---

 +--------+  +--------+
 | A方面  |  | A方面  |
 | 平日   |  | 土日   |
 |        |  |        |
 |        |  |        |
 +--------+  +--------+

---- Fig. 3 end ----

じゃあ、なぜそうなっていないのでしょう?　 一つ思いつくのは、これがいいというのは、あくまで利用者の便宜を考えた場合の話ですよね。 片方だけ見るように印刷すれば、 この時刻表には広告が付いているのだから、見ない側に掲載されている広告主は面白くないかも。 考えすぎかもしれないが、 あえて両側見させるためにこの配置にした、という可能性もあるのだが、果たして真実は?

§

唐突だが、この場を借りてお詫びさせていただきます。 一体何の話かというと、Webで公開している「初級C言語Q&A」のコーナーだ。 殆ど休眠状態というより、全く活動していないと言った方が正しい。 メールを下さった皆さんには大変申し訳ありません。

※ もはやメールも来なくなった。

ところで、どの程度のメールが来るのかというと、 現状では1～2ヶ月に1通という程度だ。 しかも、その内容なのだが、特定の処理系に依存したものが増えてきた。 最近の質問だと、例えば 「デジカメで撮影した画像を画面に表示するにはどうしたらよいか」という質問をいただいた。 これはいい質問である。 私も教えて欲しいと思った。

もう一つ、多いのは、課題の解答を教えて欲しいというものである。 そういえば、最近、fj.comp.lang.c はご無沙汰なのだが、 昔は学校の課題を質問したら大変なことになったものである。 要するに自分で考えろというのだ。 もちろん、自分でこう考えたのだがどうも納得できないとか、 そこまで踏み込んだ内容だったらokなのだが、 大抵この種の質問をする人は、課題をそのまま書いて「全然分からない」という場合が多い。

※ fj.comp.lang.c: fj newsgroup の中の一つ。 www が流行する前は貴重な情報交換の場の一つだった。

ところで、個人的には、課題の質問には割と解答してしまうものである。 自分で考えずに解答をもらって丸写ししたりすると、 やはり、本人のためにならないと思う。 だから自分で考えろ、 というのがfjなどの優しい皆様のありがたいリアクションなのだろう。 私の場合、別にその人のためにならなくても、全然困りませんので、 とりあえず自分のためになるのであれば解答してみることがある。

さて、これはそのようなタイプの質問ではなくて、もっと正統派の質問なのだが、 最近面白いと思ったのが、「putchar(getchar());はいかなる操作をするか。 それを確かめるプログラムを作成せよ」という課題だ。 どこが面白いかというと、個人的に「操作」というのがちょっとピンとこなかった。 JIS X 3010 を見れば、操作という表現はしばしば出てくる。 例えば7.9.4は「ファイルに対する操作」となっている。 そう言われてみると違和感はない。

技術用語の意味は一般的なものと異なることを承知の上で、 あえて大辞林で「操作」とは何か調べてみると、 「機械・器具などを動かして、作業させること」となっている。 putchar(getchar()) というのは、 大雑把にいって、標準入力から1文字読み込んで標準出力にそれを書き出すのだから、 例えば「stdoutに1文字出力する」という処理は「操作」なのか、 というあたりで少し違和感があるのだ。 広い意味での操作には違いないと思うのだが、まあそれはどうでもいい。

さて、この課題は、それを確かめることを要求しているのだが、 どのような結果が期待されているのだろうか? 単純にstdinから1文字読み込んでstdoutに出すということなら、 何かキーを叩いたらそれに対応する文字が画面に出る、 というのが分かりやすい。 ただし、それはもしかするとうまく行かない。 というのは、バッファリングの問題があるからである。 そこまで考えると、 例えばList 1 のような解答案が思い浮かぶなのだが、 いくら何でもこれは出題者の想定した解答ではないような気がするのだ。 しかも、おそらくこれはうまく動作しない。 大抵のUNIXのシェル上では、 標準入力が行単位でバッファリングされているから、 キーボードから1文字を入力しただけでは、 それが改行コードであるような特殊な場合を除いて、 プログラムには文字が引き渡されていないのである。 どうなればいいのか考えてみると、これって結構難問なのかもしれない。

---- List 1 ----

int main()
{
    putchar(getchar());
    fflush(stdout);

    return 0;
}

---- List 1 end ----