微妙にテンション低下気味につきだらだらと、とゆー事で任意分割

一応モデル式としては完成、接続境界を更に滑らかにする事もできるが、制御と視覚的なリニア性を重視した方の計算を取り合えず採用、この辺は曲線ツールとはまた要点が別なのだよね.

しかし、問題はとにかく処理が重い事、と言っても数秒程度なのだが対話的編集には問題有、この辺はある意味どーにもならない部分もあるので見せ方を工夫するかなぁとか(※1)まーそんなカンジで実装には未だ考慮の余地が残る :-<

※1) 改めて考えると速度は何とでもなりそう、というかなった模様 ;-)

食中りで一回休み、発症は昨夜だったのですが、翌日になっても体のだるさが抜けず、余りのだるさと頭痛により昏倒、脱水気味なのだが水を飲むと気持ち悪くなる等々、ある程度復活してプログラム書こうとしては力が入らず机に突っ伏す始末 :-<

まだ残っているのか或いは体内の電解質バランスが悪化しているのかはちと不明、食欲は戻ってきているので大丈夫だとは思うが、それでも結構辛いX-<

結局これをある程度の限定条件を付けてでもs=またはt=の形で展開できりゃ後は連立させられる形になるんですが、

、、、ごめん、無理(笑)
3次なので無理矢理展開した解の公式に突っ込んで3解各々について更に変形すれば出来ないものじゃ無いとは思うけど、そんなのやってたら死ぬ(笑)

何とか変数組み合わせて連立一次方程式の形に変形できないかと色々試みるも、これも玉砕、後はヤコビ行列作って多変数のNewton法に帰結させる方式もあるが、ちと不安定なんでやりたくない、まータイリングが妥当でしょう ;-)

気を取り直して既存のもので応用

んー、これはこれで辺を上手くオペレーションできる操作系を提供しないと扱い辛くて駄目だなぁ、線形だから境界で見事に勾配の不連続性が目立っているし、、、sigh. まーあっても良いものだし、もーちょいちょい気が向いたらいじるかも.

# 「グラフィックに数学って必要なの?」なんて言われてしまった事もありましたが、結構これはこれで大変なんですよ、ええ(苦笑)

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

(夜分追記) 、、、でもって安易に均等分割(笑)

フルドラッグプレビューとか無理、更にこれはこれで任意分割どーするかなとかまー色々 :-<

C++0xではどうも見送りになったようだけど (ま、これはどっちでも良いです、単純なgcの有無なんてアプリケーション全体の開発効率としては大して変わらんし ;-) 標準機能では無理でBoehm GCみたいに無理する位しか無いかと思っていたのだけど、gcオブジェクトのプレースホルダ(gc_ptrのようなもの、C++/CLIでは ^ ね) のアドレスがgc管理のメモリの中に含まれるかどうかでルートを判別すればある程度限定的なものなら可能な模様、GCオブジェクトの可変長配列やコンテナまで考えるとplacement newを上手く使ったり、コンテナは自前で実装になるけど、実際に簡単な模式モデルとして簡略化したもの (単一スレッドのみ対応、検索は順次探索のみで効率化等は行っていない) だけ作って試してみた所ちゃんと動いている、まぁ当たり前と言えば当たり前なのだけど、C++って度量が広いねーなど改めて感心、、、一緒に仕事する相手に書いて欲しくない言語No.1ではありますけど(苦笑)

まー実際これを使うかというと疑問なのだけど (つーか言語全体に組み込まれているもののように一貫性があるワケで無く、gc管理のリソースはあくまでgc管理のオブジェクトだけで所有するという形連なるのでデータ構造のあり方そのものを規定してしまう事など、余りメンテナンス時にトリッキーになるのは良いものでは無い) 頭の体操程度には丁度良いので、皆さんもどーですか？みたいなカンジでつらつらと ;-)

# マルチスレッドでのコンカーレントgcとか考えるとリファレンスカウンタとのハイブリッドはちと難しいのが悩み、結果メモリの消費変動は結構大きくなるし、C++でよく使う粒度を考えるとリファレンスカウンタ型の即時解放は魅力的なのだけど、うーん.

# マルチスレッド対応の部分だけは標準に同期プリミティブが無いので正確には標準機能だけでは無理ですけどね(^^;;

確定申告完了、やっぱり気になっているものが消えると気分が良い(笑)

以前から気になっていた曲線の生成方式を試験的に変更、制御に難があるので実際には以前の方式との選択式になると思うが流石に結果は上々、難点は毎回巨大な (とは言っても未知数が数100個とか当たり前に出てくる所謂数値演算系の演算としてはごくごく小さなサイズだが(^^;;) 連立方程式を解かねばならない事だが、別段多重ループ内の話では無いので結構安直に書いても割といける、この辺りはやはりマシンの性能向上に感謝、ちなみに今回は例の行列処理言語大活躍、流石にこの計算のプロトタイプを色々検証する時に汎用言語で書こうとは思わなかったと思うし、C++に移す場合に変なブラックボックスが無く各計算が結局自前のライブラリで互換性が取れるのはやはり大きい ;-)

本当はこの言語で書いたものをそのままC++に変換、そのままリンクできるともっと良いのかもしれないのだが、、、動的言語的な性質が強いデザインになっているので今のままでは少々厳しい、MATX位まで硬い言語仕様ならいけるとは思うのだが、そもそもがその手の行列処理言語がプロトタイプであれこれやるには文法が独特で (あくまでプログラマの立場で補助的に使うには) 習得や (人間側の) 記憶、言語ごとの仕様の違いについて頭を切り替えるコスト高くつくのが、そこまで手はかけたくないという話だったり、文法が中括弧系でクセの少ないものでも試行錯誤するにはやや硬すぎたりで中々望み通りのものが無いという事もあって作っているという背景もあって、なかなか両立は難しい、、、ま、そんなこんなでちょいちょい続きます ;-)

ちょっと分かり難いかもしれないけどこーゆー特性になるワケですね、ええ.

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

そういえばJVM上で動くC言語って全く聞かないよなぁ、などふと思う. まー何の意味があるのかと言うとアレだが、ジョークや実験的試みとしてだけでも結構あっても良さそうな気もするのだが全然見た事が無い. 実装的には全ての変数などのアドレスが取得できる事が必要だから、関数アドレスまで含めると完全なCPUインタプリタみたいなものになってしまうし、変数&データのみに限定しても内部的にローカル変数まで含めてメモリを表す配列などの構造へのアクセスになるので、結構オーバーヘッドが馬鹿にならないのだとは思うのだけど.

、、、あっても良さそうなんだけどなぁ(笑)

ブリスル組み込み完了、何かブラシや色の混じりなどいじっているだけで結構楽しい、絵なんてそんなに構えなくても画材ってのはやっぱ面白いものなんだねーとか、メンタル的なセラピーとかにも使えるかもなぁ(笑)とかそんな具合で動作チェックの筈がついつい遊んでしまって時間が過ぎてしまったり.

他の機能と併用して出せる表情が割と増えた気がする、ただブラシエンジンの統合はマクロ的な挙動以外では仮想関数テーブルを介しての呼び出しなど論外、それどころか共通部分を関数にして括り出すことすら (一応inlineも試したが) オーバーヘッドが出るので辛い個所で、結局思いっきりマクロな挙動のみ仮想関数で定義して内部は本来継承処理などで隠蔽するのが普通な部分がフラットかつ個別派生クラス内にベタ書きされていたりと結構アレな事に、まーそういう世界もあるって事で、実際自分もペイントソフト作る前はもうマシン速いんだから多少贅沢に使っても設計優先でいーじゃんとか思ってたワケで、それだけが全てでは無いという乖離を実感できる体験を得られたのは良い事でありましょう (だからと言って逆が全てでも無く、こちらは一方の端でありその両方について正確に理解してちゃんと自分のものに出来ている必要があるワケで、どちらか片方しか実感せぬままそれを全てだと思い込み無様な主張をするような事は断じて許されるものでは無いとゆー事ですな、ええ)

まーちょいちょい再検討したい個所も出てきたのですが、取り敢えず銀行に頼んでた書類が出てきたので暫くは確定申告の作業に入ります.

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

TANEさんのページが英語版wikipediaのSAIの紹介からリンクされている模様、だからどうしたというワケでも無いのですが(^^;; 結構ひっそりやっているページという印象だっただけにwebって結構思いがけない所で繋がるものだねーと妙に感心、またある意味今更ながらにネットワーク社会の空恐ろしさ (色々な意味で) を感じる部分もアリにてというカンジ.

先日のものに色混合やら何やら付けて現行のブラシ・レイヤーで使っている演算と合わせるとこんな具合に

まぁ何とか実装検証としては落ち着いたカンジ、ただ問題は内部処理がほぼ別物になってしまい、なおかつ現行のブラシバッファ管理周りはかなり (速度的な都合などもあり) ガチガチの構成になっているので、これをどう入れ込むかなのだよなぁ、巨大なバッファも保有しているので完全に別物にもできないし、速度的にかなりシビアな部分なので下手に関数呼び出しの回数を増やす事すら憚られる個所だし、かといってフラットに入れ込むと後々スパゲッティになるし、どーしたものか :-<

# 余談だがブラシエンジン周りをいじっていると、延々試し書きをガリガリやっているので、タブレットペンの先が摩り減る摩り減る、更に様々に力をかけて具合を確認するので腕も痛くなる(苦笑)