hirax.net::Keywords::「計算機」のブログ



1999-02-15[n年前へ]

NotePCの発熱分布を比べてみたい 

お熱いのがお好き SOME LIKE IT HOT

前回の「感温液晶でNotePCの発熱分布を可視化する」で行った方法を使って、色々なNotePCの発熱分布を調べてみたい。NotePCを使う際にはパームレストの「気持ち良さ」が重要であると思う。そのパームレスト周りのアッチッチ具合はパンフレットには載っていない。そこで、周りにあるNotePCのキーボード周りのアッチッチ具合を調べてみることにする。

本来ならば、各マシンへの負荷を一定にした状態での比較を行うべきだが、私のマシンでないものも多く、注文を多くするのも、ちょっと...というわけで、平等な比較にはなっていない。

それぞれの結果の見方は、青=温度が低い、赤=温度がちょっと高い、黄色=温度が高い、水色、もっと温度が高い、である。前回の手形の跡などを参考にしてもらいたい。

まずは、私もずっと愛用しているToshiba Libretto50である。このマシンは全くのノーマルである。前回のLibretto50は150MHz駆動であり、別のマシンである。動いているアプリケーションはプリンタポートをたたくソフト。

Toshiba Libretto50

本来ならここに、Toshiba Portege320が入るのだが...

Toshiba Portege320
入院中
......................

次は、同じく、Toshiba Libretto100である。このマシンはずいぶんとアッチッチになっている。キーボードが全体的に熱くなっている。キーボードから熱を外に逃がしているのだろう。
動いているアプリケーションはプリンタポートをたたくソフト。

Toshiba Libretto100

次はIBM ThinkPad235 (Chandra2)である。Chandra1も同様であるが、キーボードの右半分がずいぶんとアッチッチである。ハードディスクがある場所かな?
動いているアプリケーションはデータ収録ソフト。

IBM Thinkpad 235 (Chandra 2)

次がChandra1。メーカーは、あれ、どこだっけ?
動いているアプリケーションはエクスプローラのみ。

Chandra 1

前回も紹介したPanasonic Let'sNote mini。これもchandraと同じく、右側がアッチッチである。たしか、この機種は放熱板がその部分にあったような...
動いているアプリケーションはプリンタポートをたたくソフト。

Panasonic Let'sNote mini
左側はLet'sNote miniのHDを入れ替える際に撮影した写真。右側に放熱板が見える。
パームレストの右側には何があるのか?

次は、鬼っ子FMV。まずは、FMV-5133。ここから下はA4以上のサイズとなる。
動いているアプリケーションはプリンタポートをたたくソフト。

富士通 FMV-5133

次はFMV-5100。サイズが大きい機種になると、局所的なアッチッチというものは減少する。
動いているアプリケーションはプリンタポートをたたくソフト。

富士通 FMV-5100

お次はSony Vaio PCG-707。大きいけれど、アッチッチ。キーボード左上にある熱い部分は一体何?
動いているアプリケーションはスクリーセーバのみ。ノートで何をセーブする?

VAIO PCG-707

PCだけでなく、Macintoshも、というわけでPowerBookG3。でかさと熱さには驚くばかり。とはいえ、確かに速い。動いているアプリケーションはグラフ計算機。

PowerBook G3

今回のような測定の場合、通常サーモグラフィーで温度分布を測定するのだが、家でやるにはかなり敷居が高い。それに比べて、感温液晶シートを乗せるだけのお手軽計測ならば簡単である。これからも、色々な測定を行う予定である。




1999-08-14[n年前へ]

年始は景気が悪いの法則 

株価・為替グラフ表示ソフトを作ろう

 自慢ではないが、私は経済には疎い。しかし、霞を食べて生きているわけではないので、勤務先の景気の行方は私の食生活を左右してしまう。その年の給料は年始に労使交渉の後に決まるのだが、何故か毎年その時期は勤務先の景気は悪いのである。当然、毎年不景気な労使交渉が行われることになる。

 「何故か毎年その時期は勤務先の景気は悪い」と書いたが、わかっている理由もある。例えば、その前年末に売れてない製品を売れたことにして前年の売上に押しこめてしまうから、次の年始は当然製品の売れ行きが下がるわけである。従って、給料を安く抑えるためには、労使交渉を年始に行うのがいいと思われる。

 そういうことはおいておいても、経済の勉強は少しはしなければならないだろう。こう思ったきっかけは、「今日の必ずトクする一言(http://www.tomoya.com/)」の

を読んだからである。株価変動グラフが簡単に見ることのできるサイトがあるなら、そういうデータを材料にして色々な解析を行ってみるのも面白いかもしれない。

 それでは、今回のサンプルには「カシオ計算機(株)」を使うことにしてみる。まずは、カシオ計算機の株価の最近一年間の変動を以下に示してみる。

カシオ計算機の株価の最近一年間の変動 (YAHOO提供のデータ)

 さて、これだけでは何がなんだかわからないし、カシオ計算機の特徴もわからない。

  • 他の会社の平均に対してカシオ計算機の特徴はどうか?
  • カシオ計算機の株価と相関があるパラメータは何か?
といったことを調べなければならないだろう。他にも調べなければいけないことは数多くあるのだろうが、経済のお勉強一日目の私にはこんなところが限界である。

 他の会社の平均を調べるためには、日経平均株価を見れば良いのだろう。そして、カシオ計算機のような輸出を主体とする製造業の場合は、円vsUS$為替が株価と極めて相関が高いことが多いので、日経平均株価と円vsUS$為替の変動を示してくれるサイトがあれば簡単に比較ができるだろう。例えば、そういった情報はYAHOOやASAHI..COMから得ることができる。

 しかし、大雑把に探した限りでは、日経平均株価と円vsUS$為替の変動を同時に表示してくれるサイトが見当たらなかった。そこで、日経平均株価と円vsUS$為替の一年間の変動を表示するソフトウェアEconomicを作成することにした(経済の勉強から離れてしまっている気もするが...)。

 プログラムの内容はごく簡単で、ASAHI.COMにアクセスして「日経平均株価」と「円vsUS$為替の変動」を示す画像を取得して、合成するだけである。今のところ、proxy対応にはしていないが、そうするのもごく簡単なので、気が向けばproxy対応にするつもりだ。
 また、動作のためにはSUSIEプラグインのJPEG対応プラグインを必要とするので「Susieの部屋」から適当なプラグインをダウンロードし、Economicプログラムと同じディレクトリか、システム、もしくはSUSIEアプリケーションのあるディレクトリに入れておく必要がある(経済の勉強をするのに、何故SUSIEプラグインの話になるのだろう? というツッコミは無しだ。)。Economicプログラムは以下からダウンロードできる。

 Ecomicの動作画面を以下に示す。ネットワーク環境が遅い場合には、起動に時間がかかるかもしれない。
Economicの動作画面

緑 : 円vsUS$為替
紫 : 日経平均株価:
 このグラフの中で、緑 は 円vsUS$為替であり、緑は日経平均株価である。それらが重なったところは白で示してある。このようなグラフと任意の企業の株価を比較することで、先の
  • 他の会社の平均に対してカシオ計算機の特徴はどうか?
  • カシオ計算機の株価と相関があるパラメータは何か?
というようなことを簡単に見ることができるだろう。

 それでは、このEconomicを用いて、カシオ計算機の株価の変動を見てみよう。

日経平均株価と円vsUS$為替とカシオ計算機の最近一年間の変動の比較(1999.08.14現在)
日経平均株価と円vsUS$為替
カシオ計算機の株価

 見比べてみると、カシオ計算機の株価は日経平均株価(左の紫の線で示してあるもの)とはあまり相関が無い。日経平均株価が右上がりで高くなっているのに対して、カシオ計算機の株価は最初に大きく低下した後に、低迷を続けている。

 それに対して、円vsUS$為替の変動(左の緑の線で示してあるもの)と見比べてみると、ほぼ同じであることがわかる。輸出を行っているメーカーはどうしてもこうなってしまう。例えば、1円円高になると為替で数十億円も損失が出たりするのである。素晴らしい製品を作るかどうかよりも、円高になるか円安になるかの方が重要であったりするのだ。しかも、(私の気のせいだとは思うが)いつも年始は円高で、そのため毎年給料が不景気になるような気もするのだ。困ったものである(私が)。

 さて、こういったプログラムは作るのが簡単な割に面白い(私としては)ので、色々と応用プログラムを作成して遊んでみるつもりである。そうして、いつか経済オンチを克服してみたいと思うのであった(経済の話なんかほとんど出てきてないような気もするが...)。

1999-12-30[n年前へ]

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

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


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

  • 第五物理の散歩道 ロゲルギスト著 岩波新書
の中の「通信を考える」である。この本は、何度読み返しても新鮮である。

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

  • 計算機の演算速度の時間スケール -> ナノ秒 = 10^-9s (クロックで考えると、1GHz)
  • 人間の演算速度の時間スケール -> サブ秒 = 10^-1s (クロックで考えると、10Hz)
ということから、計算機の大きさが0.12=1.2x10^-1m角として、地球の直径が12000km=1.2x10^7とすると、その空間スケールが先の時間スケールと同じ比すなわち10^8であると言及しているのだ。

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

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

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

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

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

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

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

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

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

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

 そこで、

で用いた
  • 人口増加( http://www.t3.rim.or.jp/~kabutoya/KABHTML/Yoi/2-1.html )
のデータをもう一度眺めてみることにしよう。

最近500年間の人口の変化

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

などの情報から、適当な通信の歴史を調べてみる。
西暦 内容
-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年問題で会社に泊まり込む人も多いが、私はスキー場で泊まり込みである。同時期に野沢温泉に行く人がいるならば、ぜひ一緒に「スキー場の特殊相対性理論」について討論したいと思う(スキー場で)。

2000-08-13[n年前へ]

WEBの時間、サイトの寿命 

ゆっくり長く続けましょうか?

 以前、

でロゲルギストが
  • 第五物理の散歩道 ロゲルギスト著 岩波新書  「通信を考える」
の中で「信号の伝わる速度と距離と処理速度の関係」を論じていることについて触れた。例えば、計算機は処理速度を高めるためには回路の大きさを小さくしなければならないとか、人間の頭脳の働きの速さから集団生活の広がりの限界があるんじゃないか、という話について論じている部分である。短く言ってしまうと、「通信を考える」の中で、ロゲルギスト達は「ある系」について
  • その系の情報処理の単位時間
  • その系の信号の伝わる速度
  • その系の空間スケール
には
  • 空間スケール < 情報処理の単位時間 × 信号の伝わる速度
という関係が成り立つだろう、と論じていたのである。速いコンピュータを作るためには、コンピュータのサイズを小さくしなければならない(信号の伝わる速度= 光速度は一定で情報処理の単位時間を短くすると、空間スケールは小さくならざるをえない)、なんてのはこの一例である。また、このロゲルギストの推論からは、人と人の間の情報伝達の速度が同じなら、
  • 大人数から構成される企業のスピードは、少人数から構成される企業のそれには遙かに及ばない
などのごく当たり前の事実が導かれるわけだ。
 
 

 ところで、ロゲルギスト達はある系の「単位時間・信号伝達速度・大きさ」の間の関係について、

  • 「単位時間・信号伝達速度」を入力値として、「大きさ」を考える
  • 「大きさ・信号伝達速度」を入力値として、「単位時間」を考える
ということをしていた。ところが、この話の30年以上前に実は似たようなことを考え、この話をさらに展開していた人がいる。それはもちろん寺田寅彦である。この手の話題を考えるときには、どうしても夏目漱石-> 寺田寅彦 -> ロゲルギストという流れを意識せざるをえない、と私は思う。

 さて、寺田寅彦が「単位時間・信号伝達速度・大きさ」について、さらにどのようなことを展開していたかというと、それはある系の「大きさ・寿命」についての関係である。寺田寅彦は

  • 空想日録 三 身長と寿命 (寺田寅彦随筆集 第四巻 岩波文庫 小宮豊隆編)
の中で
  • 人体感覚について振動感覚の限界を調べた実験データ、 - 人は自らの体の固有振動周波数の振動に対してもっとも過敏である- 、というものをきっかけとして、
  • 生物の時間の長さの単位は相対的なものである
  • ある系の「時間の長さの感覚 = 相対的な単位」はその系の固有周期と密接な関係がある(振り子時計なんてわかりやすいだろう)
  • ある系の「寿命」を測る単位は、その系の「時間の相対的な単位」、すなわち、その系の固有周期だと想像してみよう。
  • その場合、ある系の固有周期はその系の大きさに比例するから、大きい動物ほどその系の「時間の相対的な単位」は長いものとなり、見かけ上の「寿命」はその動物の「大きさ」に比例するだろう。
という想像を展開している。

 なるほど、サイズが小さい動物(すなわち固有振動の波長の短い動物)にとっては、ほんの小さな変化も大きな変化である。ということは、その動物の感じる「時間単位」は短くなければ、生き残れないだろう。逆に、サイズの大きな動物は俊敏な動きはできないわけで、その動物の「時間単位」は長くならざるをえないだろう。
 ゾウのような大きい動物は「時間単位」が長く、一見「寿命」が長いように見え、ノミのような小さな動物は「時間単位」が短く、一見「寿命」が短く見えるというわけだ。実は、ゾウもノミもその動物自身の「時間単位」を基準にすると、同じ寿命を生き抜いているということになる。

 本川達雄の中公新書「ゾウの時間 ネズミの時間」では- 体重の4分の1乗に比例して「その動物の時間単位=生理的時間」が長くなる-と述べられているが、昭和八年に既に寺田寅彦は体重は身長の3乗に比例する、逆に言えば体重は身長の3分の1乗に比例するから、「体重の3分の1乗に比例して時間が長くなるだろう」と想像を巡らせているのである。素晴らしい、想像力である。
 

 さて、寺田寅彦はロゲルギストと違って、「単位時間・大きさ」については言及しているが「信号伝達速度」については触れていない(その替わり、さらに「寿命」にまで触れているわけであるが)。もっとも、私があえて書き加えてみるならば、ある系の固有振動にはその系の中での弾性が密接に関係するし、弾性はその中での弾性波の速度も密接に関係する。つまり、ある系の固有振動の周期というものには「その系中での波の伝達速度」が暗に隠されていて、寺田寅彦は単にそれを一定とおいていたわけで、寺田寅彦が述べた内容は実はロゲルギスト達の述べた内容を包括している、と私は思うのである。
 

 このような「単位時間・大きさ・信号伝達速度・寿命」に関する話は動物に限るものではない。

  • ロゲルギストが「信号伝達速度=光速度」として、「処理速度を確保する」ための人類の行動範囲について論じたり、
  • 私(いきなり自分を例に出すのも何だが)が「信号伝達速度の変化」と「大きさ(人口)の変化」から人類の処理速度の変化について論じたり
したように、集合体に対してもその適用が可能であると思う。ここらへんは、ロゲルギスト達が寺田寅彦の想像しえた範囲を越えている部分でもあり、時の流れを感じさせる部分でもある。
 

 さて、前振りが長くなった。前回、

では、単に「信号伝達速度の変化」と「大きさ(人口)の変化」を並べて「処理速度」の変化について考えてみただけだった。今回は寺田寅彦が考えたのと同じく、「信号伝達速度」と「大きさ(人口)」から「寿命」が決まると考えることにより、「人類」の「寿命」の変化について考えてみることにしたいと思う

 まずは、前回使った「人類の大きさ=人口」の変化が次のグラフである。ただし、この人口は全然正確ではないし、むしろかなり不正確なものであることは先に断っておく。ここでは、細かな値を使うのが目的ではないので別に構わないだろう。
 

「人類の大きさ=人口」の変化

 そして、「人類」の中での「情報伝達速度」の変化を示したものが次のグラフである。この速度が「人類」という集合体の中での波の進行速度を決めるのである。
 

「情報伝達速度」の変化

 それでは、「人類」という集合体の固有振動はどうやって扱うかというと、この

  • 「人類の大きさ=人口」
  • 「情報伝達速度」
から求めることができる。「人類の大きさ=人口」をその内部での波の速度「情報伝達速度」で割った
  • 人口 / 情報伝達の速度
というものが、「人類の固有時間」の目安となるのである。この「人類の固有時間」が短くなれば、人類の時間の流れは速くなり、それに応じて見かけの「寿命」は短くなる。これが逆に、「人類の固有時間」が長くなれば、人類の時間の流れは遅くなり、それに応じて見かけの「寿命」は長くなるのである。

 その、人口 / 情報伝達の速度 = 「人類の固有時間」を計算してみたものを次に示してみよう。
 

固有「時間単位」の変化

 こうしてみると、人類というヒトの集合体においては、どんどん時間の流れは速くなり、それに応じて見かけの「寿命」は短くなっている、ということがわかる。人類はまさに生き急いでいるのである。もし、この流れを止めようと思ったら、どうしたら良いだろうか?それには、今回の計算から言えば情報転送速度を遅くするか、人類の大きさを大きくするしかない。情報転送速度を遅くするのはなんとも後ろ向き(byわきめも)だし、人口を減らすというのもなんとも後ろ向きだ。だとしたら、宇宙へでも人類が進出して、人類の空間的なスケールを大きくしていくしかないのだろうか?これもまた難しい話である。
 

 さて、最近、大好きなWEBサイトが閉鎖してしまったり、更新速度が遅くなっていたりしていて少しさみしい。だけど、もしかしたら各WEBサイトにも、「更新速度が速いと、WEBサイトの寿命が短い」なんて法則が実はあるのかもしれない。更新速度が速いということは、そのWEBサイトの固有時間が速く流れているということで、限られた寿命をどんどん使い果たしているのかもしれない。

 だとしたら、更新速度が遅いということはそのWEBサイトの寿命が長くなるということだから、それはそれで良いのかなぁ、などと思ってみたりする。「太くて短い寿命」も「細くて長い寿命」も実は本人からすればどちらも同じ長さなのかもしれないけれど、外から見ている私は「細くても良いから長く続いて欲しいなぁ」なんて思ってもみたりするのである。
 

2002-08-26[n年前へ]

CleType自主学習(仮) 

ちょっと真面目にClearType(仮)

- ちょっと真面目にClearType(仮) -
(2002.08.26〜)
  1. 楽しそうな「iMac」&「電子ブック」風ノートPC用スタンド -はじまり - (2002.08.26)
  2. 一本道か、分かれ道か - ドキュメントの縦横比について- (2002.08.29)
  3. 水平思考と垂直思考 - 文字の縦横解像度 - (2002.08.29)
  4. 細かくすると楽(粗く)になる? - ClearTypeの一番の秘密- (2002.09.09)

楽しそうな「iMac」&「電子ブック」風ノートPC用スタンド -はじまり - (2002.08.26)


 Lapvantageという楽しそうな会社を初めて知った。ノートPCをiMac風にするLapvantageDomeやPCを縦置きで使うためのLapvantagePortraitという、とても実用的でいて、それでいて明和電機のような面白い製品を作っている会社である。明和電機は兄弟が運営しているが、こちらのLapvantageの方はビアボーム親子がやっているらしい。iMac風スタンドの方は角度が振れないようのが(特にノートPCを立てられない)残念だが、Lapvantageの方はもう少しデザインがスマートであるならば今すぐにでも欲しくなる。
 

Lapvantage Products
Lapvantage Dome
Lapvantage Portrait

 複数の作業を切り替えながら作業をしたり、あるいはツールバーが多数出てくるようなソフトウェアを使って作業をする時には、左右に広いディスプレイが便利で使いやすい。しかし、単純に一つのドキュメントを読んだり、一つのドキュメントを書いたりする場合には上下に長いディスプレイを使うと、見通しがきいて考えをまとめやすくなる。気のせいか、頭の中の見通しがとても良くなるように感じたりする。だから、以前から横長の画面のノートPC(ToshibaPortege 320)を愛用していたりした私はノートPCの画面を横にして使ったり、縦にして使ったりと、画面を切り替えて使ってみたいと感じていた。AdobeAcrobat Readerであれば、画面を回転させて文章を読む機能があるので、これまでノートPCを回転させて電子ブックのようにして文章を読んだりすることもあった。 

 Lapvantage PortraitはPivotProのソフトウェア付きなので、Windowsの画面を自由自在に回転させることができる。だから、ノートPCを普通に横置きに使ってみたり、スタンドに載せて縦置きに切り替えて使ってみたり、と好きなように切り替えることができる。「これはなかなか便利そうだ」と思い、私も私も30日有効のPivotProのデモ版をインストールして使ってみることにした。

 そして、このソフトのインストールをきっかけにして

で調べたClearTypeに関して、ちょっと少し考えてみた。 (続く)

 

一本道か、分かれ道か - ドキュメントの縦横比について- (2002.08.29)


 前回書いたように、複数のことを考えるなら「左右に長いディスプレイ」が良くて、一つのドキュメントを読むなら「上下に長いディスプレイ」が良い。その理由を端的に言えば、「目が左右についているから」だと思う。

 まず、「目が左右に付いているので、あまりに大きい左右への目の動きは、目にとってとても非対称な作業であるから不自然」だ。だから、左右を眺めるときには自然と頭を左右に振ることになる。その頭を左右に振るという作業は、頭の中での何らかの切り替え作業を伴うような気がする。だから逆に、ツールパレットの切り替えのような「何らかの作業の切り替え」を伴う作業であれば、その左右へ視線を移動する(自然と頭も左右に動かす)ということはとても自然な行為になる。しかし、それは一つのドキュメントを読むような場合には、いたって不自然な行為になってしまう。だから、一つのドキュメントというのは本来「上下に長い=縦長」であるべきだと思う。

 そしてまた、「目が左右についているから」、人は上下方向を「一本道」に繋げて考える。例えば、絵画を眺めるとき、上に見える景色は多くの場合遠い景色で、下に見える景色は多くの場合近い景色だ。漱石の文学論の図を引くまでもなく、この「上下の遠さ、距離」というものを例えば時系列上の「一本道」に繋げるのは、いたって自然な連想だと思う。「遠い上」に見えるものは「遠い過去」で、下に来ればくるほど新しいことになる。それは、ドキュメントを読む場合に対応させて考えると、とても自然だ。それに対して、左右に並ぶものは決して「一本道」ではないのである。それは、「選択肢=分かれ道」であって、決して一つの道ではないのである。左右に並ぶものは「複数の何か」なのである。

 だから、一つのドキュメントは上下に並び、上下に長いべきなのである。ドキュメントの表示も同じく、縦に長いべきなのである。
 

「文学の焦点」

漱石 「文学論」より

 最近のPCであると、ディスプレイは通常横に長い。だから、本来縦に長くあるべきドキュメントを眺めようとする場合には、表示を90°回転させてやることもある。そうすると、本の一ページのようにして画面表示を眺めることができる。例えば、AcrobatReaderで表示画面を回転させたり、PivotProなど使ってPCの画面表示自体を回転させてやれば良いわけである。
 

Acrobat Readerで90°回転表示をする
回転させない場合
回転させた場合

 
PDF表示を90%回転させている例
縦長のドキュメントを読むことができる

 このように、ドキュメント表示のための縦横比については、単にディスプレイの表示を90°回転させてやれば問題は解決する。しかし、表示のためのもうひとつの条件、表示品質が問題になってくる。そもそも、液晶(二十世紀においてきたCRTは無視しよう)の解像度はまだま低くて、それを改善するための技術としてClearTypeやCool Fontがあるのだけれど、AdobeのCool Typeはともかく、Clear Typeの場合には表示が90°回転しているという情報をClearTypeが取り扱わない(知らない)ために、上手く動かなくなってしまう。ClearTypeにしてもCool Fontにしても、液晶のRGBのカラーフィルターの並び方を利用してやることで解像度を高めているわけで、その並びの変化(表示の回転)に対応できない場合には表示品質を大幅に落とすことになってしまう。

 次に、「ファイト!縦文字文化 -縦と横の解像度を考えよう - (2001.04.29)」で考察した、文字の解像度についてもう少しちゃんと考えてみることにする。



 

水平思考と垂直思考 - 文字の縦横解像度 - (2002.08.29)


 ドキュメントを表示させるためには、文字を表示させてやらなければならない。しかし、液晶ディスプレイの解像度は必要十分には高くないから、文字はつぶれてしまうことが多い。例えば、「現実問題春夏雪雹資本主義電計算機」なんて文字を表示させてみるとかなり潰れてしまい、非常に読みにくいのが判るはずである。これが、英語の"RealProblem seasons Snow capitalism Computer"なんて文字であれば、まだマシである。

 この日本語と英語の文字の解像度の差について考えてみる。比較例は下に示した、「漢字」と「英語」のテキストを用いることにする。
 

日本語と英語の文字の解像度
「漢字」
「英語」

 まずは、600dpiで20ptのMS Pゴシックのフォントを展開して上のような画像にした後に縦・横方向のそれぞれの解像度を考えてみる。ここでは、縦・横方向の黒い線(あるいは線でない部分)の太さ(幅)の分布を測ってみることにした(今回解析のために作成したソフトはここ(RunLength.lzh)においておく)。テキストのような二値の画像の「解像度特性」を計測するのであれば、このような解析にしなければならない。「ファイト!縦文字文化 -縦と横の解像度を考えよう - (2001.04.29)」でやったようなフーリエ解析は適切な方法ではないのである。

 下の図が縦・横方向の黒い線(あるいは線でない部分)の太さ(幅)の分布である。縦方向に計測した黒い線(あるいは線でない部分)の太さというのは、結局のところ横線の太さ(あるいは線の間隔)であり、横方向に計測した黒い線(あるいは線でない部分)の太さというのは、結局のところ縦線の太さ(あるいは線の間隔)ということになる。どれだけの細かさで「太さ」(あるいは「位置」)を描いてやらなければならないか、を示すグラフということになる。
 

600dpiで20ptのMS Pゴシックのフォントをビットマップに展開してみた場合
「漢字」の場合
「アルファベット」の場合

 「漢字」の場合には「Vertical 方向で計測した線の太さ(あるいは線の間隔)、すなわち横線の太さ(あるいは線の間隔)」が「縦線の太さ(あるいは線の間隔)」に比べて、大きく小さい方にシフトしていることが判ると思う。また、横線の量が縦線の量に比べてずっと多いことも判ると思う。後者は「数字文字の画像学 -縦書きと横書きのバーコード - (2000.01.21) 」で考えたことと全く同じで、「日本語は横線が多い」ということを端的に示している。そして、前者は「Vertical方向で計測した(すなわち横)線の太さ(あるいは線の間隔)」が縦のそれより大幅に小さいということは、「漢字」の解像度は縦方向に大幅に解像度が高い、ということを示している。漢字は縦書き文字故に鉛直思考志向なのである。

 一方、「アルファベット」の場合には、これも「数字文字の画像学 -縦書きと横書きのバーコード - (2000.01.21) 」で考えたことであるが、縦線と横線の量においてはむしろ縦線の方が多いことが判る。水平方向に対して情報量が多いのである。アルファベットは水平思考志向なのである。「アルファベット」の情報量はそのかなりの部分が縦線によるものなのである。そしてまた、線の太さ(あるいは間隔)は横線の方が細い(あるいは線間隔が短い)が、その横線であっても「漢字」の縦線程度の解像度であることが判る。「漢字」に比べて「アルファベット」の解像度は低いのである。

 ただし、文字の解像度を「線の太さ(あるいは間隔)の最小値」だけで論じることはできない。「適切な線の太さ(あるいは間隔)」にすることができるほどに解像度が十分高いか、ということも重要である。もし、そうでなかったら線が妙に太くなったり、細くなったりしてしまったり、あるいは、線の間隔が妙に近づいたり離れてしまったり、つまりは文字のプロポーションが崩れてしまったりするだろう。上の場合は600dpiで文字を表示させた場合の解析例だが、次に現在の液晶と同じような解像度(例えば)150dpiでこの文字を表示(展開)させてみる。こうすることでことで「適切な線の太さ(あるいは間隔)」にできていない様子を確認してみたい。
 
 
 



 

細かくすると楽(粗く)になる? - ClearTypeの一番の秘密- (2002.09.09)


 まずは、「現実問題春夏雪雹資本主義電計算機」という漢字と"RealProblem seasons Snow capitalism Computer"というアルファベットを現在の液晶と同じような解像度(例えば)150dpiでこの文字を表示(展開)させてみた。そして、前回と同じようにそのビットマップ画像の「縦・横方向の黒い線(あるいは線でない部分)の太さ(幅)の分布」を調べてみる。その結果が下のグラフである。また、前回に調べた、これよりも4倍程解像度が高い「600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合」をさらに下に比較用として示してみる。
 

150dpiの解像度で20ptの文字を出力してみた
「漢字」の場合
「アルファベット」の場合
600dpiで20ptのMS Pゴシックのフォントをビットマップに展開してみた場合
「漢字」の場合
「アルファベット」の場合

 150dpiでTrueTypeをビットマップに量子化した場合には、漢字・アルファベットの場合共に、縦・横方向とも600dpi単位で4,8pixelの太さ=150dpiで1,2ピクセル幅のパターンが発生していることが判る。このようなパターンは、600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合には見られなかったものである。つまり、、着目すべきは例えばアルファベットの場合、

  • 縦方向には幅10pixel(600dpi単位)=2.5pixel(150dpi単位)以下の高い周波数は存在していなかった
  • 横方向には幅13pixel(600dpi単位)≒3pixel(150dpi単位)以下の高い周波数は存在していなかった
ものが、150dpiで量子化した場合には
  • 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が生じている
ことであり、漢字の場合も全く同じように、
  • 縦方向には幅7pixel(600dpi単位)≒2pixel(150dpi単位)以下の高い周波数は存在していなかった
  • 横方向には幅11pixel(600dpi単位)≒2.5pixel(150dpi単位)以下の高い周波数は存在していなかった
ものが、150dpiで量子化した場合には
  • 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が非常に多く生じている
ことである。液晶の解像度が低いために、その低解像度で量子化する際に「幅の狭い高周波のパターン」(歪み)が生成されてしまっているのである。そのような高周波のパターンが生成されてしまった場合には、低解像度のディスプレイで表示するためには、ますます無理が発生してしまうことになる。「低解像度の表示系の解像度に合わせて量子化(ビットマップ化)してしまうと、ますますその表示系では表示しづらい高周波のパターンが生成されてしまい、結果として読みづらい」という現象が生じてしまうわけである。

 また、これらの文字の場合には本来18〜15≒12pixel(600dpi単位)の線幅・線間のパターンが多いわけであるが、それを150dpi単位( =600dpi単位で4pixel )で量子化してしまうと、場所により4/12 = 33%もの線幅・線間の位置の誤差が生じてしまうことになる。不必要に狭い幅のパターンが作成されたり、不必要に広い幅のパターンが作成されたりして、これでは文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまい、見にくいことこのうえない。これはすべて、150dpiという低解像度で量子化してしまったためである。「低解像度の表示系の解像度に合わせて量子化(ビットマップ化)してしまうと、ますますその表示系では表示しづらい高周波のパターンが生成されてしまい、結果として読みづらい」という一見逆説的に思えてしまう(しかし当たり前の)現象が生じている。

 ところで、本題のClearTypeの場合には横方向(通常の液晶はRGBの3つのサブピクセルが横方向に並べられているから)の解像度を3倍だと仮想的に考えて、横方向を3倍の解像度で量子化を行うことになる。ここで、話の単純のために3倍≒4倍と思うことにすれば、つまりはClearTypeの場合には本来150dpiの解像度であるにも関わらず、サブピクセルを考えて600dpiの解像度で量子化している、ということである。それは結局上の二つのグラフの比較と同じであって、ClearTypeを使うと実は表示すべきパターンが「より表示しやすい低い周波数のパターン」になっているのである。それは、「文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまう」ことがなく、目にとってはとても見やすいパターンになるだろう。この量子化の段階について触れている情報は見たことがないが、実はこの量子化の段階にClearTypeの隠された(しかし、一番重要な)メリットがあるように思う。また、アルファベットの場合にはHorizontal方向に振幅を持つパターン(=縦線)が支配的に多いため、Horizontal方向に仮想的に高解像度の量子化を行うことは非常にメリットを効果的に得られると考えるのが自然である。

 次に、このように量子化されたデータをClearTypeで表示する際の問題点・その解決方法について考えてみていくことにしたい。

 P.S.ちなみに解析ソフト(RunLength.lzh)をアップロードしました。
 



 
 
 



■Powered by yagm.net