ぼうメモ帳

2004-10-26 病院通い

今作ってるもの

病院にいってきました。待ち時間が長いんだろうなあとか思ってたら、待ち時間10分という荒技で診察室までこぎつけました。奇跡。ま、喘息の様子を見るだけだからすぐに診察は終わったけど。

3DCADモドキ

| 3DCADモドキを含むブックマーク

いま、3DCADもどきを作ってます(画面参照)。まだワイヤーフレームを表示する程度のすげーショボイバージョンですが、少しずつ機能を付け足しているという段階です。

いちおう、Javaで、自前で3Dレンダリングを行ってます。Java3D/2Dを一切使ってないの、1ドットずつ自力で描画しています。だから、結構重たいけど、一応、秒間で500万頂点ぐらいは描画できる*1。エッジの方は…すごく重たいです。

まあ、初めての3Dプログラミングにしては、まあまあではないでしょうかね。

*1:Pen4-2.8c

トラックバック - http://d.hatena.ne.jp/susumu/20041026

2004-10-23 書きたいけど書けない このエントリーを含むブックマーク

日通してロードオブザリング3部作を見てました。おかげで土曜日が丸つぶれ。いいんだ、土日は遊んでストレス発散したほうが。

ま、そんなことよりも、日記に書きたいのにココでは書けないというのがストレス溜まりまくり。とくに、自分の周りのことが書けないのがつらい。ただ正直、性格的に向いてないことも考えて、俺はもう何も言わないほうが良くて、自分のアルバイト研究に集中したほうが良いのかなと思う今日この頃。ただいま愚痴を聞いてくれる人を緊急募集。そろそろ限界。実家に帰りたくなってきたけど、気軽に帰れる実家がない。

トラックバック - http://d.hatena.ne.jp/susumu/20041023

2004-10-22 書くネタがない

今週の進捗

| 今週の進捗を含むブックマーク

3日坊主ならず、1回坊主にならないように、今週の研究進捗を記します。

  • 自分の研究
    • 修論日本語版を少し書き足す
    • グラフシミュレータに機能を追加(PriorityModuleRunerの実装)
    • java.util.concurrentを使うと、グラフシムの実装負担がだいぶ少なくなる悪寒。

今週は、遊びすぎたと思う今日この頃。

トラックバック - http://d.hatena.ne.jp/susumu/20041022

2004-10-16 研究、研究

今週の進捗

| 今週の進捗を含むブックマーク

研究のための時間がなくなってきたので、今度こそ真面目に進捗を管理することにする。

論文はともかく、プログラミングが間に合うか心配になってきた。やばいやばい。

トラックバック - http://d.hatena.ne.jp/susumu/20041016

2004-10-06 仕事が溜まってきました。ゲームなんかやってる場合じゃない。

最近のコンピュータの速さといったら

最近のコンピュータの速さといったらを含むブックマーク

ここに1GHzで計算できるコンピュータがあったとして、このコンピュータは毎秒1ギガ回の足し算をするプログラムが与えられている*1。じゃあ、1ギガ回はどれくらいの大きさかを考える。

いま、私は1秒間に1回の足し算を行う。すると、1分間では60回の足し算、1時間では3600回の足し算、1日では86400回の足し算、1年間では3153600回の足し算、一生(80年)では2522880000回の足し算を行うことができる。2522880000回は、2522880Kになり、2522Mになり、2.5Gになる。

とすると、1GHzのコンピュータは、私が生涯かけて行う足し算を、わずか3秒足らずで行ってしまうわけだ。だからなんだという感じだけど、コンピュータって速いなあと思う反面、人生って短いなあと思う今日この頃。

*1:細かい話は置いておく

トラックバック - http://d.hatena.ne.jp/susumu/20041006

2004-10-03 日々の悩み このエントリーを含むブックマーク

昨日(今日か?)、朝までがんばってコードをチューニングしてたおかげで、予定性能をギリギリでクリアするぐらいのエンジンを書くことができた。本当、「これが性能を重視した結果さ!!」と言わんばかりのコードで、ループアンローリングから始まり、小さい配列のプリミティブ化、インスタンス変数のローカル変数化、データフローをみながらの式の並び替えなどなど、へたれな高速化技法をだいぶ投入しました*1。足し算・引き算、掛け算、割り算、ロード・ストア命令(が入りそうなところ)などをピックアップして、やばそうなところから一つずつ命令を削っていくなんてこともやりましたよ。それで、30%ほど高速化したから許せるけど、もうやりたくない。

それでも、本当にこれで速くなってるかどうかは自信がありません。なぜなら、-serverオプションを付けないときは高速化し、付けたら逆に遅くなったってことが多々あったからです。これでは、環境ががらりと変わっただけで、実は最適化のせいで遅くなってたなんてことが起こりそうです。

*1:使用言語Java

トラックバック - http://d.hatena.ne.jp/susumu/20041003

2004-10-02 神!!

BufferedImageの高速化

| BufferedImageの高速化を含むブックマーク

BufferedImage.setRGBが遅くて遅くて使い物にならないと嘆いていたわけすが、ネットを散策してたら、

BufferedImage img = new BufferedImage( width, height, BufferedImage.TYPE_INT_ARGB );
int[] pixels = ( (DataBufferInt)img.getRaster().getDataBuffer() ).getData();
pixels[ width*y + x ] = c;

なるコードを見つけて、早速試してみたところ、神が舞い降りました。setRGBなんか使ってられねえ。実行時間の桁が違う。桁が。って、もしかして、常識

トラックバック - http://d.hatena.ne.jp/susumu/20041002

2004-10-01 く、苦しい…

晩御飯食べ過ぎました。

何年かぶりに、電車の音とともに目が覚めました。「ば、ばかな、電車の音なんか聞こえるはずがないのに」と思ったら、

http://www.ntt-east.co.jp/fukushima/mado/gazai/wakamatsueki.wvx&e=42

を開いたまんまでした。近くに住んでんだからわざわざライブで見る必要があるのかといえば…

フリーでオープンでマルチプラットホームなHyperCardクローンってないかなあ

フリーでオープンでマルチプラットホームなHyperCardクローンってないかなあを含むブックマーク

と思いながら、自分で作るんならどういう風に作るかなと妄想をしてました。なんでこんな古いものが欲しいかというと、やっぱり使いやすいからなんですね。いまでこそ、Javaをブンブン振り回したり、Cをガンガン走らせたり、C++をチマチマ弄ったりする私ですが、それでも古巣であるHyperCardに憧れます。それは、誤解を恐れずに書くと、他の開発環境はプログラミングをサポートするツールであるのに対して、HyperCardはプログラミングに重きを置いたオーサリングツールであるからです。ようするに、グラフィックとサウンドとテキストをチョロチョロチョロっとやって、ボタンなどのユーザーインタラクションのための部品とスクリプトをカタカタカタと書いてあげれば、それなりの作品が「はい完成」となります。しかもただのオーサリングツールとは違い、データベース的な要素も持ち合わせているため、ユーザーのインタラクション(テキストの編集など)が自動的に保存されます。

私は、HyperCardそのものにはそれほど不満がないので、作るとしたら、イメージ表示オブジェクトやグルーピングオブジェクトを導入するぐらいで、それ以外は似たようなものになると思います。あと、私が考えるHyperCardの一番の旨みは、やはり自動的に状態が保存されるということです(これは、Squeakなどでも見ることができます)。ですから、もしクローンを作るとしたら、そのときそのときの状態が自動的に保存されるというのに細心の注意を払うと思います。ま、インタラクションを保存しておいてくれるプログラミング前提のPowerPointみたいな感じでしょうか。

とりあえず、使えそうなライブラリリンク

piccoloは、2DGraphicsのフレームワークで、wicocoはJavaで非矩形・半透明ウィンドウを実現するためのライブラリ。あと、音をどうするかだ。

さて、プログラミングのためのHyperTalkそのものには不満タラタラです。何が不満タラタラかというと、

  1. オブジェクト指向プログラミング言語ではない
  2. データ型が文字列しかないくせに、扱いが浅い
  3. HyperCard専用言語のくせに、HyperCardのすべてにアクセスできない
  4. 手続き型言語のくせに、代入がタルイ
  5. GUIの動作を記述するには表現力がショボイ

と、不満なところを挙げていったらキリがありません。これだけ書くと(特に一番最初)、「こいつHyperTalkの何も分かってないんじゃね?」とか思う人も出るかもしれず、それはちょっと癪なので理由も書きます。

1.「HyperTalkはオブジェクト指向プログラミング言語ではない」について

まず、オブジェクト指向プログラミング言語とは、オブジェクト指向ソフトウェア開発を実現するためのプログラミング言語です。オブジェクト指向については、書くとそれだけで朝になってしまうので、ここでは書きません。ただ一つだけ注意したいことは、オブジェクト指向は「ただの物の見方にすぎない」というところだけです。

次に、プログラミング言語とは何かと考えると、ある問題やシステムなどをコンピュータ上のプログラムとして実現するとき、そのプログラムを記述するための言語です。そんな当たり前のこと言わなくても分かってるよ〜ってな感じですが、ここからが大切です。このプログラムを記述するための言語に、なぜたくさんの種類があるのでしょうか。プログラマの数だけプログラミング言語があるなんていう言葉もありますが、なぜこのような言葉が生まれたのでしょうか。答えは簡単です。プログラミング言語の性質は、問題領域+実行環境(+感性)によって決まるからです。世界中には無数の問題領域があり、無数の実行環境があり、プログラマの数だけ感性があります。ですから、プログラミング言語はたくさん種類があるのです。ここでは、問題領域に焦点を当てます。ある万能言語があったとします。この万能言語は、どんな問題領域のプログラムも記述することができます。一見、この万能言語さえあれば、他の言語は必要なくなるかのようにみえます。でも現実にはそんなことはありません。なぜなら、ある狭い問題領域にしか扱わないとき、万能言語と特化言語を比較すると、特化言語の方が記述が容易かつ単純になるからです。そして、プログラムが人間の時間を節約するために開発される限り、記述が容易かつ単純であるプログラミング言語は生き残ります。なぜなら、プログラムの開発コストプログラムを開発することにより節約されるコストよりも小さいとき、プログラムは開発されます。人間は貪欲ですから、少しでも開発コストを小さくしようとします。特化言語の法が記述が容易かつ単純になるのであれば、万能言語よりも特化言語のほうが開発コストは小さくなり、特化言語が用いられることになります。ですから、特化言語は生き残るわけです。こうして、プログラミング言語はドンドンと生まれていきます。逆に言えば、現存するプログラミング言語には、それが対象とする問題領域が必ず存在するということです。

では、オブジェクト指向プログラミング言語が対象とする問題領域とはなんでしょうか。それは、「オブジェクト指向のものの見方でプログラムを実現すること」です。ですから、これを実現するための機能が文法や意味に盛り込まれています。HyperTalk単体では、この問題領域をまったく扱うことができません。すなわち、オブジェクトオブジェクトメッセージパッシングを使ってモデル化されたシステムを記述することができないのです。そもそも、オブジェクトを記述する手段がないのです。そんな言語オブジェクト指向システムモデル化できるでしょうか。なお、一般的にHyperTalkがオブジェクト指向であると誤解されるのは、HyperCardという環境下でHyperCard上でモデル化されたシステムの動作を記述することにより、オブジェクト指向”っぽいこと”を実現できてしまうことが原因ではないかと考えています。

正直、オブジェクト指向ちっくなHyperCardの動作を記述する言語がまったくオブジェクト指向ではないというのは、まったくスマートじゃないので私はいやです(ここが感性)。

2.「データ型が文字列しかないくせに、扱いが浅い」について

HyperTalkにおいては、データはすべて文字列である。たまに数値として解釈されるが、基本的には文字列である。スクリプト中に未定義の名前が出てきたら、それも文字列として扱われる。でもここで問題が。変数内の文字列そのものを名前として利用できないということ。すなわち、HyperTalkにおいて、参照を表す変数の値が存在しない!!

これは、HyperTalkが変数の値として文字列しか扱えないことが原因かというとそうではない。Cでは、変数の値はすべてバイナリ列により表現された値である。この値を、文脈(変数の型)によって、値なのか参照なのかの区別を行っている。すなわち、変数の値はすべて2進値にもかかわらず、参照を実現することができている。ならば、HyperTalkでも参照が表現できてもおかしくないのではないか。なぜそれを行わないか。それが、扱いが浅いという意味

以下、疲れたので手短に。

3.「HyperCard専用言語のくせに、HyperCardのすべてにアクセスできない」について

カードとかに描かれてる絵にアクセスできない。あるドットを白や黒にすることはできても、白か黒かを判断できない。あほっぽ。

4.「手続き型言語のくせに、代入がタルイ」について

Cだと、

a = 10;

と記述すればいいところを、

put 10 into a

と記述しなければいけない。

5.「GUIの動作を記述するには表現力がショボイ」について

GUIを真面目に記述したかったら、マルチスレッドは基本だよね。

擬似的にマルチスレッドを記述するために、関数を分割して、idleにて自力でスケジューリングなんてやってられん(これが大変なんです、ものすごく。そのくせ糞重い)。

で、以上の5つを、HyperCard/HyperTalkの限界に挑戦して実現したことがありました。利用するためには、ものすごい冗長な表現を使わないといけなかった&こちらが用意したスタックを利用してスクリプトを編集しなきゃいけなかったという制限つきですが。たしか、zorkタイプアドベンチャーゲームを作る過程で副産物として出来上がったものだったと記憶しています。で、動かすとすごく重いんですよ。なにしろ、do文やsend文を使いまくってるからです。そのとき思ったんです。一から言語を作ったほうが早いってね。

で、今日一日、このHyperTalkに変わる言語はないかな〜って妄想してたわけです。

トラックバック - http://d.hatena.ne.jp/susumu/20041001
274052
Connection: close