OSASK-WikiのKの落書きの過去ログ

  • 本家:OSA:K
    • 過去ログにコメントしたい人も、本家のこめんと欄に突っ込んでください。
      • そのうちKによって下のこめんと欄に移動しますので。

目の付け所

  • (2004.11.07)
  • 僕がそれなりにうまく開発できているときは、僕は普通の人とは違う観点でものをみているときでもあるような気がしたので、それを書きます。
  • たとえばtekの開発に成功したのは、圧縮率こそがすべてという観点ではなく、圧縮率がよければ展開が遅くて当たり前、圧縮率が低ければ展開が速くて当たり前、だから圧縮率がそれなりに高くて速度もそれなりに速いものをいくつか(スピードでランク分けして)作るべきだ、という観点に到達したからだと思います。
  • もし僕が圧縮率一辺倒な方法でのみ圧縮フォーマットを評価していれば、僕のような圧縮しろうとでは当然お話にならず、有益なフォーマットを提案することはできなかったでしょう。多くの圧縮研究は圧縮率を極端に重視しているような気がします(まあ理論的な研究としては、圧縮率のみを追求するほうが格段にかっこいいとは思いますが)。
  • tekの改良では、paqarの結果を100とする、圧縮指数による評価法も大いに役立ちました。こんな評価方法(それぞれの圧縮結果について、もっとも圧縮率の高いものを100と置いて圧縮率を無視して相対評価する方法)をしているサイトは、今のところ他には見つけられません。みんな圧縮率であったり、bit/byteであったり、いずれも圧縮対象のもつ情報エントロピーを全く考慮しないでやっています。
    • 一般的な圧縮率のみによる評価では、改良すべき点をうまく見つけられないという話を、Z:tekの「解説」に書きました。
  • またオールゼロの64KBのファイルを圧縮能力のチェック項目に入れているのも多分僕くらいでしょう。
  • さらに、不得意な対象での圧縮指数のみに注目し、これを最小にするような改良をもっとも重視する、という方針も珍しいでしょう。たいていは、自分の用意したテスト対象で圧縮の合計サイズが最小ならそれがトータルのベストであるとか、もしくは個々の圧縮率に適当な重みを乗じてその和をスコアにするとか、そんなのものばかりです。
  • OSASKにしてもそうです。僕は「機能密度」という聞きなれない観点を勝手に作って、OSを評価しています。この観点が無ければ、僕はOSを完成させるまでサイズの評価ができず、それゆえ気がついていたときは不本意なほど肥大化してしまった、なんてことがありえたでしょう。
  • 機能密度は、OSASKだけではなく僕が作るほかのソフトウェアの開発の際にも役立っており、この観点のおかげで、僕が作るプログラムはそれなりの評価を受けています。
  • GOの開発の際には、移植性の考え方を勝手に拡張して、標準ライブラリの存在すら仮定しないことにしました。普通の移植は必要なライブラリの移植も意味するものですが、僕の場合は必要不可欠なライブラリを適当に用意してコンパイラのソースの一部とすることでライブラリを不要にしたわけです。その結果OSへの依存が避けられない数個の関数以外には何もいらないという、そんなコンパイラができました。
  • 他にも探せばまだありそうですが、とにかく人と同じように考えていたら、僕が何か意味のあるプログラムを作ることはできなかったと思います。他の人が考えないような観点を思いついたときに、よい成果が出せていると思います。

リロード   新規 編集 差分 添付   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: 2006-02-16 (木) 18:00:05 (5977d)