テキストツールで使用するレンダラ部のUnicode対応化完了、これで取り合えずDerive(※1)でコピーした数式が (フォントも合わせれば) 画像に反映できるようになった(笑) まぁこれで数式をHP上に乗っける時も少しは楽になろうという所、必要性はまぁたまになのだが、そのたまにで使えなければ使えないで結構難儀していたので :-< しかし元々がASCIIで作っているコードにつき部分的にUnicode化すると色々面倒だったり、Unicodeのエディットコントロールに間違えてGetWindowLongAでサブクラス化してしまったら内部のエミュレーションにバグがあるのか正常動作しているように見えてGetWindowTextの文字カウント等一部機能が正常で無かったりと色々ハマる.

まぁそれ以外には ™ とか © とかも使えるので、用途想定を考えるとあるかどうか分からないアレ向けにもやっておいてみるかな、という所 ;-) まーこれは半分アレでネタがあれば何でも良かったのですが(苦笑) ただ未だ変形系フィルタの最終品質の取り回し、各アルゴリズムごとの使い分けや実行時間の兼ね合いなどの部分は落ち着かず、年末も後少ししか無いが、ここの部分だけは落ち着けねば、というカンジ.

※1) まぁ数あるメジャーな数式処理ソフトに比べたら必ずしも細かい所で賢いエンジンとは言えないのだが、如何せん電卓的な操作としてはかなり扱い易い為ちょっとした計算 (と言っても大学の学部レベル位までなら結構いける) の電卓として愛用している :-) 実装の検討過程などで一時的に使用する程度の身分としてはこういうお手軽なソフトは構えて使う本格的なソフトよりむしろ有り難い(苦笑)

TVでドバイの開発バブルとその崩壊の話をやっていた、こういう話を見るにつけ、或いは今の不景気を見るにつけ不思議に思う. 資本主義経済の最も基本的な原則は安い所で作り高い所で売る事にある、それを推し進める際より規模を大きくより安価にする為に投資という掛け金を募り更なる事業拡大を目指す. そうして出来上がった市場に競争力を持って参入する為、また参戦を維持する為により投機的な資金の調達を図る、これが繰り返された結果投資を募る範囲はどんどん拡大し、実際の資金規模を遥かに上回るベットが場を流れる事になる.

まぁ平たく言うとネズミ講とも似ている、決定的に違うのは差益が生じる為ゼロサムでは無いというだけの話だ. 但し借り入れに対し十分な差益を得られない場合は会員を増やすか(バブル) 一旦ゲームからそのラウンドの掛け金を全て (比喩的表現) 捨てておりる事になる、但しここに落とし穴があり、ゲームを降りても場にいる限りは毎ラウンドチャージを取られる事になる. その最大のものは人的コスト、すなわち雇用にある. 実際の手持ちのチップが実際に場に示されているチップよりも少なく、毎ラウンド「次の勝負に借りね」として運転していた状況で停止すれば、その最低限のチャージすら払えなくなる、実際「借り」にしても2期連続して決算に赤が出ればそれ以上の「借り」(銀行融資)はできなくなる. 結果、それでも何とか場に止まろうとするならリストラにより最も危険要因である人的コストを圧縮するのが効果的であるのは (残念ながら) 言うまでも無い. 雇用というのは一般の社員が会社に対して考える以上に企業にとってはリスクなのだから.

よくある話だ、走りつづけるネズミのごとく、立ち止まったら死ぬしか無いので走り続ける、そして何層にも重ねられた決断は誰も実体を掴まぬまま全てを動かして行く. 一方そういった賭けに出られない街中の商店 (分相応の掛け金のみで運用する) などは当然未来に対して大量に借金できる大きなプレイヤーが参入してきた場合に持久戦で勝てずゲームから抜けるしか無い. 事態としては結局の所これが今の経済の姿であるワケで、単なる分析に過ぎない、ただそこに常に何らかの違和感を感じる、結局この違和感は既に実体が残っていない不確かさに対する、実際のモノを触れる世界に生きる観測者である人間のプリミティブなものなのだろう、ある筈のないものがある違和感と言っても良い、メタファとしては正にバベルなワケで、タロットカードの塔の意味は破滅なのだが(笑) 我々の立つ足場は既に実体を持たず、もう後戻りできない所まできているのだろうか？(ドラえもんの仮想の雪を高く降らせる道具を使ううちにスイッチを切ると落下して死んでしまう高度まで来てしまったジャイアンとスネ夫のオチのように ;-)

# あるいは聖書にある如く、塔を打ち砕き、然るに言葉を乱す事だけが解也哉、まぁこれは言葉遊びでしか無いが :-P

# 最近流行りの「エコ」(政治・産業用語)が個人的に嫌いなのも上にある結局勝てるゲームが無くなったら新しいルールを作るみたいな印象を受ける為、無論地球環境論としての温暖化などの問題を軽視するものでは無いが、それに関する研究論文としては「エコ」で提示される概念を裏付けるものもあれば別の説についても多数提示され未だ明確な結論は出ていない、北極の氷が小さくなっている＝産業による温暖化というのは余りに短絡的過ぎる、無論手遅れにならぬ為予防策を講じるのは重要な事であり、公害に対する対策を怠って良いと言うつもりは無い、ただ賛成・反対意見も含め常に公正かつ客観的に議論される事も、そういったものが提起される事も無く、呪文のように繰り返す現状を見るにつけ結局産業振興策なんだよねーと穿ってしまう :-P

# まぁそれが悪いとは言わないけどね、個人的に建前だけをもっともらしく述べるのは好きじゃ無いって事と、余りそういうものの加害者にはなりたくないという話なだけで、これもまた、自分だけでも「正しい」のであれば、一方その状況に従わざるを得ない他人の弱さなど知った事じゃ無いという独善的な態度であるワケで :-P

# 業であるなぁ(苦笑)

---------------

こういう事を考えるのも先日ちょっと考えさせられる内容の話題があったから、なのだが. あの時は人の弱さに起因するものに「まぁそれじゃ仕方無いね」というリアクションをしていたが、改めて内容を精査するとそこにクライアントにとってのデメリットというものが考慮されておらず、その皺寄せが全て最終顧客に発生するのなら、やっぱそれはシンプルに間違ってるんだよと言わざるを得ない、方法論の為に前提まで壊してしまっているのだから. そしてそれを「仕方無い」というならそれはその役柄における存在そのものとして間違っている、ただそれを正当化するのは「人間は生きる為には何をやっても良い」という良くある独善的な理屈 (というより駆り立てる漠然とした不安と恐怖) に他ならぬ.

まぁこれを読んだ人が僕の事を嫌いになってくれても良い、僕にはやはり他人の痛みなど分からぬのだと実感している、そしてこのエントリは先日の違和感の全てを処分する為の認知不協和の代償行為である事も否定しない ;-)

---------------

おまけ)

気候の極端な変動の例としては氷河のボーリング調査による観測で20年程度の短期間におよそ7度の平均気温の上昇が見られたケースもあるのだそーな (グリーンランド、およそ1万2000年前) 無論反証にはならぬが、未だ我々が如何に地球環境について無知なのかを示す一つの例としては面白いかもしれない ;-)

waveletは相変わらず勉強中なのだが、ふと参考資料のページをめくっていたら主成分分析の項目が目にとまる、数式ベースの証明なのだが改めて読むと何の拍子抜けする位何の抵抗も無くスルスル頭に入って行くのを感じる、至って当たり前だよねーみたいなそんなカンジ、うん物事というのは何かある瞬間、あるきっかけから一気に理解が深まるものだが何かその不思議さを実感、何かちょっと気持ちイイ. まー元のスペックが低いからというツッコミは無しの方向で (まぁ高校卒業直後がピークだったのは認める所ですよ、ええ、あの頃は大学生活なんて遊ぶものと考えてましたし、ひたすら遊び呆けた挙句に失ったものに気付くのは社会人になって暫くしてからの事 :-<

ちなみに一緒に書かれていたKL分解は特徴パラメータを上の主成分分析の定義で得られる共分散行列の固有値と固有ベクトルから絶対値の大きなもの(=写像に変動の大きい次元) から順にn個取ってそのベクトルを基底に減次(投影) された特徴空間を表すというもの、固有ベクトルは(漠然とした言い方だが)写像の変形辺であり、固有値は拡大率、で実対称行列の場合各固有ベクトルは直交する (∵転置行列の定義よりa.A(b)==A'(a).bから直感的にも理解できる通り、また複素数の対称行列の場合には共役転置になりv1.conj(v2)=0が成立) 、うん当たり前当たり前.

まー何か調子が良いです、先週の頭は頭の回りが悪く考えもまとまらず、コーディングも微妙に手がつかずでやたらイライラしていて、ちょっと前は一気に画像フィルタを50個実装したりと極めて絶好調だったのが何だろねーみたいに考えると、当時何となく飲んでいたビタミン剤のサプリメントを思い出し、薬局に行ってビタミンC,B,マルチビタミンなど大量購入、毎日スナック菓子の代わりや口寂しくなった時のお供になどオーバードーズ気味に飲んでみるとやはり調子が良い、まぁ普段の食生活が朝夜２食タイヤキとか極端な食生活を送っているからかもしれないけど、結構影響するものだねーなどと改めて人体に感心、きっと早死にしますね(ぇ

宿題を貰いました、3ヶ月でwaveletの基礎理論から含めて説明できるようになるまで理解しないと呪いでハゲるらしいです、困ったものですが、ハゲだけは断じて嫌なので頑張ろうと思います、特に全域に対してならまだしも頭頂部だけハゲるとどう見ても河童か年食って過去をまだ引きずっている勘違いロッカーか、周辺にパーマをかけて御茶ノ水博士を目指すしか許されないので、それだけは何としても避けたい所です.

まぁ後はペイントソフトが実験段階の不安定なロジックを使用している個所があるので、年末までにその辺の加減を一旦fixとして参考リリースを出せるようにするという所、まぁこちらは個人的目標、相変わらず内輪のみで一般公開の予定は無いものなのでアレではありますがまぁ内々のスケジュールの都合もあってという所 ;-)

欲せよされば与えられん、逆説的には真也哉. 努力は欲望を超えられない、残酷な現実、なればこそ欲せよ、的に :-P

# その後冷静に考えるとスキンヘッドはアリかもしれない、ような気がしないでもない ;-)

---------------

んー、まだ完全に酔っぱらった状態で資料を読んでいるので読み違えている可能性もあるが、細かい数学的背景は置いといて、概念的理解としてはFourier変換が全ての周波数について同一の固定の領域に対して周期関数で割り当てるのに対し、waveletは基底に無限大で減衰するタイプの基底関数を割り当て、それの位相とサイズをスケーリングしながらマッチング (と言うか式内の(x-b)/aの個所が正にソレ、連続系で言えば全てのa,bに対する演算で離散化環境では単なる反復) して分解する手法のような、元々の定義はそれを積分区間で表しているけど、離散化する際に2^nによる離散化を定義してそれを離散waveletとするとまーそんな具合の話なんじゃないかと.

細かい所言えばその基底の選択で色々性質はあってjpeg2000などでは発生する誤差をエンコード/デコードで吸収するようにデザインされていたり色々派生的な研究の余地がある個所だけど、まぁ一番単純なhaarのwaveletなんかは正に2^n量子化そのままみたいなカンジだし、正規直交基底による内積の話も全ての離散化範囲で直交するような基底を選んでいるみたいだし、んでサンプルにあるものは実数係数のみで扱う話が多いけど、基本的には基底によっては係数は複素数にもなり得て、ただスケーリングと各区間の離散化の話を考えると、1次元では時間方向、2次元では位置情報の相互関係は保持される、みたいな. でも無限領域の積分として出ているワケでは無いので、Fourier変換みたいな便利な畳み込みの応用とかはできないのでまた別の応用でみたいな、でも周波数としてはバラせるし (ただ周波数の規則的な脈動みたいなパターンの解析にはFourier変換の方が妥当なんで微妙に使い所も違うんだろうな的な気がするけど) みたいな. そう考えるとそーいう事なんじゃない？ という気がしなくもないけどどうでしょう？＞O氏

先日KOJIさんから連絡貰っていた話なので元ネタは自分では無いのだが、Win32 APIのFindFirstFile/FindNextFileでワイルドカードを指定した場合のマッチングがどうも変だという事で確認してみた.

具体的には例えば"*.cfg"で列挙した場合"test.cfg"以外に"test.cfg1"や"test.cfgab"なども検出される、但しこれはワイルドカード+拡張子が3文字の場合のみで、2文字や4文字の拡張子指定ではこのような動作にはならない.

また"test?.cfg"とした場合には拡張子".cfg"のもののみが正常に列挙される. ただこれも"t*?.cfg"などとすると前述の結果となり、"t*t?.cfg"ならcfgのみとなったりする. 3文字という所から恐らくはdosのショートファイル名まで遡るバグ互換な気がするが、例えばあるディレクトリにある拡張子.spiのDLLを読み込む場合など、思わぬ動作をする可能性は十分あり得る.

対策としては自前でワイルドカードで展開する事だが、更に頭の痛い事にコモンダイアログでのワイルドカード指定にも影響している、深く考えると思わぬ所で深刻な影響になりそうな仕様であるのでメモがてらここに残す. なお確認はwin2kで行ったがXPでも同様であるとの事らしい :-<

なお余談だが?は0文字以上1文字以下にマッチするそーな、Unix系のツールと同じ感覚で使っているとこれまた痛い目を見そうな気がする X-<

ここ暫くの結果、ライブラリとしてはストックするものの、ペイントソフトへの組み込みは見送り、瞬間的とは言え想定解像度ですら (消費メモリを可能な限り削っても) 最大で512MBワークに必要となると他の部分のメモリ消費が見積もり辛いプログラムでは少々荷が重い :-< まぁスタンドアロンのアプリ向けとしてはあって良いので、取り合えずはライブラリ及びスクリプトに組み込んで考察用Utilとしてのみ保持という具合に止める.

まぁこっそり別プロセスにしてメッセージと共有メモリベースでやりとりって考え方はあるが、それがメインロジックならともかく傍流の1機能としてはそこまではやらないという具合で ;-)

基本必要になるまでスペックには拘らない主義で自作PCとかベンチマーク追求とかあまり興味ないたちだけど、流石にここまで来ると64bitメモリ空間が欲しくなるなぁ(苦笑)

---------------

for[each]〜in構文って結局の所リスト内包表記と同じようなものなんだよね、と思うと表記は統一しておいた方が良いと思い立ちfor[each]構文を拡張、別段x,yの多重ループを1ブロックで書いたらいけないという事は無い筈なのだから.

for(y in range(h), x in range(w)){ ピクセル処理 }
とか

for(a in list1, b in list2, a.id>b.id){ 〜 }

とかそんな具合で、ちなみにリスト内包表記は

r = [[a.name,b.name] : a in list1, b in list2, a.id>b.id];

みたいに書く.

まーぼちぼち. 幾つか思いついた内容もあるのでペイントソフトに戻る前に少し自作言語をいじるかも. しかし言語作る上で一番辛いのは色々な機能を増やして行くと割り当てる記号が足りなくなる事だよなぁ、など(笑) 余り予約語は増やしたくないし ;-)

ここ数日はプログラムは気付いた所の微調整のみで余り進んでいない、先日も書いた通り数学周りの学習がメインであった為. 以下ここ数日で掴めた内容(という程大げさでは無い、せいぜい前提知識) のまとめ.

・Fourier変換は関数を無限次元のベクトルとみなした場合に定義される拡張された内積空間における写像問題である. (内積は積和から周期関数の場合周期単位の積分に拡張される)

・よって離散Fourier変換における積算計算は正規直交基底による写像マトリクスの計算になる.

・逆Fourier変換は正規直交基底より逆行列は(共役)転置行列となる為、複素数関数e^ixの定義より共役をとってあの形状になる.

・写像された空間の基底は関数で表現される為、その特性を保持しているので周波数空間での操作が成立する.

つーことらしい、つまり写像における代数的な性質の保存を考えると周波数域での乗算が畳み込みとなるの (一般的な写像の話では無くあくまでFourier変換で使われている基底の性質を考慮すると) もごく当たり前とゆー事になるのかな (まだ少々曖昧) ここまでイメージを掴むのに結局1週間近くかかってしまった. やっぱ要領良くないよなー、まぁ天才と違って凡人はせいぜい努力するしか能がないという所ですよ、ええ :-< まぁそれでも 「何かの魔法」 という認識よりは遥かに良いので無駄だったとは思いませんが(苦笑)

なんかこの手の応用が相対性理論 (直交基底が成立しない空間での計算) とか量子力学 (無限ベクトル空間) でもベースになっているとか、上に書いたのなんてほんの触りに過ぎない訳でこういう内容を深く理解した上で組み合わせて、更に新しい理論を組み立ててゆく人達ってのは本当凄いなぁと感じる次第なワケです.