少々間が空いてしまったが、一応多変数多項式を実装してみた. 一応基本的な四則演算と項の参照を実装してスクリプトエンジンに組み込んでアルゴリズムを色々テストしている所、一応1変数多項式のlcmなどは何とか実装できたっぽい、しかしlcm然りグレブナ―基底の導出然りで基本的に2進表現の誤差が指数関数的に累積し易い演算が多いように思う、有理数や多倍長演算を想定した方が良いかもしれないが、自前の処理系に乗せる場合元々が本実装の為の演算の検証で使うものを想定している為、全ての数値を多倍長や有理数で扱うのは抵抗があるのも事実、誤差を生じる個所はその特性が確認出来ないとプロトタイプと本実装で挙動が変わってしまう、まぁ多項式処理自体はプロトタイプ向けというより特性の解析に近い話なので仕方無いが.

この辺Webで集められる情報は断片的でしか無いので久しぶりに大学の生協で計算機代数の本を探してみようと思う.

、、、しかし、些細なきっかけからどうにも大きな回り道をしているような気もする今日この頃、ここ暫く延々と数値計算のアルゴリズムを追っかけている、まぁ己の身になるので良いのだが、いまいち何でこんな事をやっているのか自分でも思い出せない、、、どう考えても3Dやる程度なら不要な話が多いのだが、むしろ最近はこちらの方が面白くなって3Dはどうでもよくなっている気もする(苦笑)

なお当然仕事はまだ終わってない(駄目じゃん

追記)
やはり誤差や通常の2進浮動小数での表現可能な限界への抵触が馬鹿にならない、勉強としては続けるものの、実際の式の解析にはやはり数式処理系買ってきた方が良いかも、そんなに本格的な式を解析するワケでは無いので昔あったDeriveのような安直(ある意味オモチャ(^^;;)なものが良いのだけど (大は小を兼ねるとは言うけど、メインで使うものでは無いので出来るだけこういうのは簡素なものの方が楽(笑)

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

久しぶりに髪の毛切ったらどうも切り過ぎたっぽい orz
、、、気に食わんのでいっそ金髪にでもするか？(笑)

友人との雑談でふと出た多項式処理の話、興味が湧いたのでちょっと調べてみたのだが、、、というか凄く面白そう、作りたい、みたいなそんなカンジ. 1変数は整数論分野での応用がメインになるが、多変数なら日常用途でも有用だし(演算は限定されるが) 項の検索さえ上手くやれば基本的な四則演算は実装できる筈.

なんか面白そうでうっかりしていると頭の中がその事で一杯な状態、かなりヤバいのでさっさと今の仕事終わらせて作ろう.

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

細胞の寿命に関する本を読んでて出てたネタ.

生物の寿命は細胞の分裂速度が早い程短くなる、また性質劣化(ガン化)なども同様、運動における体細胞の活性化では同一生物種での差異は顕著では無いが、ラットによる実験では飽食のラットと生存に必要な栄養素のみに限定したラットでは飽食のラットの方が(細胞が活性な分)寿命の低下が見られるとの事. というかコレ美容製品なんかの「肌を活性化」という話との関連はどうなんだろー(笑) 一時的にツヤツヤになっても(寿命までは顕著な影響は出ないものの) 10年経ったら使ってる人の方がシワシワになったりして(笑)

また成人病の要因は食生活の影響があると言われているが、実際には遺伝的要因がそれと同程度の比率を占めるらしい、健康生活している人からするとミもフタもない話(いや、自分は不健康の極みなのですけど;-)

今度は真面目に照明計算してみた(前回のは単なる視点との内積)

当然PerPixelライティング、流石にスクリプトでは重くなってきたのでここらが限界かも(640x480で6分かかった)

ラスタ計算の部分をもう少しちゃんとデザインし直してからC/C++で書き直しを予定、飽きるか忙しくならなければ(笑)

まーちと仕事でこの辺絡みの話をやっているので学習用としても自分でも作っておくのは悪くなかろう、うん

.

何となくリストウェイトなど買ってみた、暫くこれを両手両足に付けて生活する予定、期待通りなら1ヵ月後にはコーディング速度は倍にハネ上がるに違いない.

、、、まぁ実際は良く「人間は適応するものだ」などと言うが実際に自分の経験での体系的な裏付けがあるワケでは無いので、だったら試してみるかという所.

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

確定申告の合間の息抜きでZバッファレンダラなんぞ作っている.

別に意図があるワケでは無いが、そういえば3D向け想定の多角形描画ルーチンって書いた事無いなぁ、などと気付いたので、何となく.

実際手数として持っていて不便なものでも無い、表現における限定事項が多く、レイトレ周辺がここまで進化しPCのスペックも大幅に向上した現状からすると、Zバッファが役に立つのはせいぜい髪の毛などのメモリに収めきれないものをレンダリングする場合程度に限られる(レイトレでは全てのジオメトリデータをオンメモリで持つ必要がある)だろうが.

まだロジックプロトタイプ段階で、考え方が間違っていないか模索しながらの状態という事もあって上のプログラムは実はスクリプトで書いているのだが、驚いた事にそれでも上の画像程度なら有限時間(と言っても3000ポリ程度で2分半もかかるが)で完了する点.

昔X68000のDoGAではもっと単純なポリゴンでも、もっと時間がかかったように思うのだが、あれから15年近く、PCは馬鹿みたいに速くなっているのだなぁ、などと改めて実感したり、もっと遡るとMSXで初めて画像処理を書いた時は簡単なフィルタで3時間半戻ってこなかった記憶もあるのだが、、、いやまーホント何ともバカみたい(笑)

という事で上のプログラムはこんなカンジ ちとネタにするのでこちらにも一応、起動はpoly3.txtをnoop.exe(※1)にドロップすれば動きます、まぁあくまでネタですが;-)

※1) 自分用に作っている雑用向けの言語処理系、これの仕様検討が全く終わらない為別のプログラムに移れないのは去年から書いている通りorz

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

という事で確定申告も無事完了、保険の更新手続きなどたまっていた雑務も完了して実に良い気分.

電話で話してて「人間嫌いだから」という話をして、結構これは複数の人間から言われる話でもあるのだが、毎回違和感がある、面倒なので別段訂正もしないのだが、どちらかというと人間は好きなんだけど、まぁそう見えるのかなぁという気もしてみたり.

単に他人に干渉しようとするタイプと自分自身の基準を持ってないタイプが嫌いなだけなのだが、、、後は嫌いなタイプの時にそれを包み隠そうとは一切しない (時間の無駄だし) って所がそう見えているのかも.

まぁ今の現状ではいちいち説明するのも面倒だし「人間嫌い」で通しておいた方が何かと都合が良いので、適度に誘導しておくのも悪くないかもしれぬ:-P

、、、というようなそんな愚痴、いかんねー(苦笑)

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

確定申告で買ってきたソフトが役立たず (決して使えないソフトだったワケでは無く想定と違う方向が重視されていた) しょんぼり:-<

先日ネタにした行列計算言語は自分の為の表計算ソフトの代わりとして使っているのだが、正直一般的な扱いを想定しているものでは無い、検討していた電卓も機能を増やすとインターフェイスがどんどん複雑になってしまう. という事でフリーフォーマットのスプレッドシートのようなものを考えてみる(Excelは便利なのだが、あのセル指定だけはどうにもいただけないので(笑)). インターフェイスはテキストエディタが横に2つ並んだようなもので一方に文書を、他方に計算結果が出力されるような具合で、多分こんな↓カンジになるだろうか?

# 直角三角形のパラメータ


斜辺    = sqrt(底辺^2+高さ^2)
底辺    = 10
高さ    = 2
角度1   = atan(高さ/底辺)
角度2   = 90-角度1

Excelと同様未定義変数が解消されたものから式の評価を行い計算する(※1) 統計や離散データを扱う場合はこんなカンジ.

# 統計計算


ID, データ  = [
    1   8.2
    2   20.5
    3   30.2
]

平均    = mean(データ)
二乗和  = sum((データ-平均)^2)
標準偏差= 二乗和/(size(データ)-1)

最大    = max(データ)
最小    = min(データ)
median  = median(データ)

可読性を考えると上のような書き方のミニプログラム(プログラマの人怒らないで)を式ごとに保存して使うのだろうが、正直これは余り便利では無い、不備が露呈するのは以下のようなケース

# 気体の状態方程式


圧力 * 体積 = モル数 * 気体定数 * 絶対温度      # 関係式

絶対温度    = 温度+273.15
体積        = 1
圧力        = 10
#モル数     = 2
温度        = 120
気体定数    = 8.31

# ここで関係式からモル数の解が自動で出ていて欲しいが、、、

分子数      = モル数+アボガドロ数
アボガドロ数= 6.02*10^23

お馴染み(?)気体の状態方程式だが、基本的にプログラムの都合としては順方向の計算のみが得意で、解が複数あったり関数形状が極端な場合に上手く解くのは難しいので、数学専門のソフト以外の殆どの("計算"程度向けの)ソフトでは順方向の演算しかサポートしていない(プログラムなどで別途サポートするケースはある). しかしこれらについて求めたい項目ごとに関係式を変形して解を求める形式にするのは面倒で(それが例え簡単な式であっても)プログラマ以外の人間の期待としては「コンピュータなんだからそれ位やって当たり前だろ」という所だろう、実際自分もコンピュータを触ってまもない頃似たような事を思った記憶がある.

という事でコンピュータを計算の道具として電卓以上のメリットを見出すには最低限ソルバー(Excelでいう所ではゴールシーク)が必要だと思うのだが、自動で計算を行う場合、複数解がある場合にそれを選択できる必要があり(実際は"日常で"使う計算は殆どが状態に対し解が一意に定まるものが殆どだが、例外があっても適切に対処できねばならない) エンジンは完成しているのだが、これを設定する為のインターフェイスが思いつかない :-<

数式処理などの専門のソフトから見ると実にささやかなレベルの話でしか無いが、人間が面倒な事をやってくれてこそのコンピュータだと思うワケで、さてさて(※2)

※1) プログラムの上から順に書くというルールはエンドユーザー的にはそれだけでイカンだろーと思うのですな、順番を考えねばならないので、同様に式を変形するのは更にイカンでしょ、頭使うもの(ぉ、、、いやマジなんですけどね.

※2) ちなみに自分の経験上、この類の(ソルバーとか数式処理系とかの)ソフトを使っているとどんどん馬鹿になる事を付記しておく(ってダメじゃん

※3) まぁ自分にとっての用途は前述のソフトで足りているので、実際に上に書いたようなもの作るかどうかは微妙なんだけど(ある意味オモチャではあるし)ただ最もコンピュータのプリミティブな用途として「計算」機としてのありようをあれこれ考えるのは好きなんですな.

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

汎用言語の方はVC7コンパイラのバグにぶち当たり停滞中、出力コードを見るにコンパイラ内部のクラス情報データベース自体が狂っている模様でオプションに関係なくイカれたコードを吐いてくれるという何とも困ったもの、VC6/8ではコンパイルできるのだが、VC6はVC7に比べると最適化時のパフォーマンスが70〜80%程度、VC8は何故かVC7より(というか総合的には何故かVC6よりも)悪いパフォーマンスのコードしか吐いてくれないみたいでダメダメ.

昔はコンパイラのバグなんて世界でこれだけ使われているんだからそうそうブチ当たらんだろーとか思っていたのだが、どうも最近の経験では(複数のプログラムで)規模として3万行を越えた辺りから稀にブチ当たる事があるように思う、、、会社時代のコードなんてある意味オモチャみたいなものだったんだなぁとしみじみ(そして何年後かには今書いているコードについても同じ事を思いそうな予感(苦笑)