夢じゃ 夢じゃ 夢じゃ

夢じゃ

夢じゃ夢じゃ夢じゃ夢じゃ

夢じゃ夢じゃ

各々がた お騒ぎあるな

お騒ぎあるな お騒ぎあるな

夢じゃ

夢じゃ ゆ夢じゃ

夢でござぁぁぁぁるぅぅぅぅぅぅぅぅぅ

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

やべぇ、超ツボった(笑) リメイクらしいからオリジナルも観たくなったよ.

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

ふと以前友人と飲みに行った時に同一スレッド内でWindowメッセージを使うのはどうかというネタがあったのだが、酔っぱらっていてイマイチ正確に答えたかどうか定かでは無いので改めて書いてみる.

自分の経験内の主観的な話になってしまうが、クラスメソッドなどを直呼びしてしまうとC++の場合Windowの構成を後から親子関係まで含めて組替えた時に柔軟性を欠くという理由からむしろ直接他Windowのメソッドを呼び出す事は稀で殆どをメッセージベースで構築しているカンジ、例外としては単に完結したコンポーネントとして「使われるだけ」のものについてはクラスに閉じ込めてメソッドやメンバ変数をアクセスしている、但しあくまでそのクラスを所有する側からの操作のみで、所有される側から親への通知はメッセージを使う事が多い、デリゲートのような柔軟な結合が不可能なC++の場合Javaと同様にListenerを別途定義して扱う形だとメンテナンスや変更時に書き換える個所が多くなってしまう為、可能な限り疎結合でパーツはライブラリ化する方針を取っている、また内部的にクラスで実装してても、(内部遷移パターンが少ないクラスについては) 外の口はハンドルに全てカプセル化してしまって関数にしてしまうケースもある、少々細かい部分かもしれないが拡張可能なフルセットのデータ型を提供するよりも完全に隠蔽してしまって必要な時だけ呼び出しそれ以上何も考えないというモデルの方が規模が大きくなった時 (自分にとっては) より把握する部分やコード自体がシンプルになるケースがある場合などに適用する、またWindowコントロールの場合は操作の基本単位をhwndにしておいた方が (巨大な全てをラップするライブラリを構築するので無ければ) 他の機能と組み合わせ易いという側面もある.

なお最近の実感としては (あくまでクライアントアプリ分野のような横に広くよりも縦に深くなる傾向が強い分野でのサンプルになるが) ある一定規模まではメソッド単位のイベントコールバックの方が分かり易いのだが、それ以上の規模になるとメッセージベースの方が、例えば思ったパフォーマンスが出ない為呼び出しのフローを変更したり、GUIの構成を変える場合や、複数のツールの遷移状態を保持する場合に、総合的なソースのマネジメントコストが少なく済む気がしているとまぁそんな印象、というかメソッド単位だと変更の時に書き直す個所が多くてただでさえコードは書きたくない不精者の僕としては無理(笑)

何故今更な話題なのだが、実は現在Javaの自主(笑)集中学習をやってて自前のライブラリを充実させるとガチでイベントクラスを各々定義しなければならない辺りに結構不便さを感じててふと思い出したという所. 実際にはC#とJavaで同じGUIを実装した場合の比較など交えて進めてるのでちょっとペースは遅め、それでも大分Javaも (自分の分野での) 特性は見えてきた感があるので、1週間程度の規模の簡単なGUIソフトを1本書いてみて取り合えずの区切りとする予定、もう少し続きます ;-)

PHPが面白く無くなった (データアクセスするクラス作ったら後作業だね、どうせ全部シーケンシャルだし(暴言)) ので昨日からはJavaでGUIアプリを作る可能性について色々、SWTなどもあるが、ソフトウェアの保守コストを考慮すると常に依存関係は少ない方が良い (例え車輪の再発明であっても外部ライブラリのバックボーンが細いもしくは不安定な場合は選択肢に入れる事はリスクになり得るし、また安定したものであっても常に動向をチェックする分のコスト及び致命的fix時のリスクを考慮しなければならない) がポリシーである為標準機能のSwingをあれやこれや.

現時点でJavaでクライアントアプリを想定するメリットはサーバの管理コンソールのようなUnix上でも動作する点でメリットになり得るソフトに限定される (Macについてはユーザーサイドである可能性が高い為、GUIの一貫性が若干であっても犠牲になる事を考慮すればJavaは選択肢では無い) のだが、その領域においてどの程度の可能性 (せいぜい良くあるダイアログアプリ程度のもの(※1)かあるいはもう少し複雑なものを想定可能か)を見極める為.

今の所Swing標準コントロールについては全てラップし直してやれば何とか使えるかなーという具合で、見た目もある程度UIManagerを全部設定しなおしてやれば許せるかなぁ (それでもフォーカス周りは常にWinのダイアログマネージャ相当のものが起動している為Winの標準コントロールにも増してグダグダだが:-<) Listenerモデルはちとコントロール粒度がバラけ過ぎる為、イベント通知周りも自前で再整理すれば何とか、という具合なのだが、、、何処調べてもキーボードステートの問い合わせ(GetAsyncKeyState/GetKeyState相当)とマウスキャプチャに関する機能が見つからない、、、何か既に挫折気味 orz

しかしFlexにもやっぱりその手の機能無いんだよねぇ、、、.NETはキャプチャだけはあるけど、キーステートはWin32APIに逃げるしか無かったと思うし (まぁそれでも逃げ道があるだけ良いが) X-<

※1) 暴言を承知で言えばこの程度なら何で作っても同じだと思ってます、ええ :-P (まぁそれでもWeb系の実装については画面切り替えのユーザーに対する心理コストと「戻る」ボタンのミスリードの影響は無視し難い部分もあるけど)

※2) 追記、MouseMotionListenerのmouseDraggedでできるっぽい、押されたらそのまま自動的にSetCaptureになる動作をしている模様

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

ま、良くある逃避、ちゃんとモノを形に成すよりは技術のつまみ食いをやっている方がはるかに楽なんであります(半分皮肉、半分自戒を込めて ;-)

特に思う所があるで無いが、ここ数日PHPをいじっているがまぁ酷いもの、言語実装の話になってしまうが、自分がかつて自作言語にクラス機能を乗っけた時に 「この程度に機能を限定できれば実装が楽なのに (でも駄目だろう)」 と思った部分が全てものの見事に最も安易な実装になっているという印象、大体中身も含め想像がついてしまい、クラス周りに限らずスコープ制御や関数管理など含め言語の基本構造の全域の実装について大体そんな印象なのは最早見事と言う他無し.

まぁ具体的に色々書くとやたら長くなるのでその辺は割愛 :-P ただ言語の細かい所は置いておいて「単なる道具」(※1)として見るとそのバランス感覚は悪くない印象で、分野外の人間が適当にwebサイトをでっち上げると言う目的においては非常に良いものだと思う、随分前にあったRuby vs HSPネタの時と同様の印象 (コンセプトの重点が一方が言語、一方が道具) なので、付き合い方としてはまぁそんなに本気に使うべきじゃないという所かもしれない.

まぁ普及インフラ上でWebをでっち上げると考えてもコスト的効果 (但し個人程度の用途想定で、メンテナンスに関する考察は除く) はかなり高い位置にあると思う反面、少々「柔らかすぎる」気がして余り好みでは無いのは確か、気軽に書くスクリプト想定の開発規模での硬さはPython位が好みではあるのだが、あれはselfがうっとおしいし、Rubyは変数前の記号が好きじゃない、Perlは硬さとしてはPHPと似たようなものであるのでやはり除外、Javaは環境導入まで考慮して想定スケールがもう少し大きい想定になるのでそも分野としては同じ土俵では無い、結構思い通りにはならぬものだなぁというカンジ :-<

余談だがweb周りのコントロール粒度はパッケージ系のそれとは全く違う、確かにこの粒度なら巷に溢れるメソドロジー論にも結構当てはめ易いなぁなどと思ってみたり (とゆーかマジ深刻なんで誰かクライアントサイド主眼のパッケージ分野にも使えるそういう「メソドロジー」教えてくれないかしらん、最低sai程度の規模 (所謂ツールでは無くアプリね) の開発を前提に、良くある「こうあるべし」議論 (事実を提示せず主観によって論じられる議論はおしなべて不毛だ) では無く、ちゃんと適用結果の分析まで含め効果を客観的に観測できるデータと一緒に、ね. 一応saiでのモデルケースはあるが余りにもピーキー過ぎて一般化し難い、、、(涙)

# 追記 (ほぼ私信) Python, Ruby(※2), PHPと一通り真面目に触ってみたが、やはり僕のフォーカスする分野でスクリプトに求めるものとしてはちと違うわ、「プログラムを書く」というフェーズではその程度思考に滞りがあっても問題無いけど、考えをまとめる上での「文房具」として捉えるならやっぱり自前で言語一個作ってしまう方が多分楽だと思う、鉛筆を使う時に鉛筆の使い方に引っかかったり思い悩むなんてそんな馬鹿な話は無いしね ;-) (その言語は)そういうものとして使ってしまうという話も、(自分の体験上) 一回何の引っ掛かりも無く全てが自分の思い通りになる状況を体験してみると、その快適さからはもう戻れなくなると思います、実際体験してみ？全然違うから(笑) という事でマジ自分用に特化した言語の作成お勧めというカンジで ;-)＞友人プログラマ各位

※1) まぁこれについても色々議論はあると思うけど (プログラムの場合生産フェーズが無いので必ずしも当てはまるとは限らないが) 例えば工業製品の場合品質を上げるにはとにかく良いものを作るのでは無く、品質のバラツキを押さえる事を主眼にする方が重要という話もある、前提条件を明確にしないとこの手の議論は各自が「こう思う」というものの応酬になるだけの実に不毛なものにしかならないというカンジで :-P

※2) 余談だけどたまにPython vs Rubyみたいな構図があるけど、確かに出来る事は大体似通っているんだけど、言語の根底にある発想としてはこの2つって正反対のベクトルにあって比較するものでも無い気がするのは僕だけだろうか、、、余りそういう議論は見ない気もするが、、、

相変わらずdecimal、意外と長引いてしまっている :-<

自前ライブラリで計算した10万桁の階乗結果を眺めて微妙に複雑な気分になったので、この辺りで切り上げたい所、まだ少々「もやもや」するものがあるのは確かだが、取り敢えずは先日のWin32APIでのdecimalを自前のスクリプトに組み込んで長期的に様子見を予定. ちなみにVarDec〜系列で提供されるdecimalは細かい丸めの挙動や内部のバイナリ表現などほぼ.NETのdecimalと同様と見て良い模様、留意すべきは無理数や桁あふれの場合演算単位でBanker's roundにより丸められるという所、演算過程の誤差なのでBanker's roundは統計的にはまぁ妥当であるし、無理数が出てくる時点でdecimalを使用する想定に何かしら問題もある可能性があるのでという所か.

分野的にも今までdecimalのような型を扱う事は無かったが、エンドユーザー向けとしてはdecimalの方が直感的であるので、C++でも家計簿ソフトなんかを作る時には考えても良いかもしれない、、、作るかどうか知らんが :-P

ちなみにこれに絡んでExcelの丸めを改めて色々いじってみたのだが、2進表現であるにも関わらずセル単位で近似値に丸められ、一気に式を書くと結果が変わるなど、凄まじく気持ち悪い仕様になっているなぁなどと改めて痛感. 結構Excelって金額計算にも使われているんだよなーなどと苦笑する事しきり、まぁ実際複雑な計算で無ければそれ程顕在化しないのかもしれないけど、本来ならアプリケーション側で技術計算モードと事務計算モードを分けて持つのが妥当な実装の気もしたり、ASP系の言語やVBAなどに代表される「アプリケーション言語」もどうせ複雑な計算しないならそっちのほーが良いのかもしれないね、などとも思ってみたり、まー色々 (COBOLを除くメジャー言語の殆どがプリミティブとしての10進型(※1)をサポートしてないというのは非常に面白い気もする、javaなんかは当初の構想とは分野が違うけど最近使われている分野を考えるとあった方が良いような気もするが)

※1) .NETのdecimalは一般的な意味で使われているbcdでは無く、内部的には10^nの下駄を持った整数演算という方が正確な表現になる ;-)

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

つらつらと半日かけてdecimal用の数学関数を色々書いてみたが、どれだけ工夫しても内部演算精度をdecimal以上に上げない限りそのまま使っていると最低でも最下位の桁に誤差が出る、当たり前と言えば当たり前の話、下手に値域に誤差を含むよりは有効数字15桁 (一般的なdoubleのおよその桁精度: 52*log(2)/log(10)) として通常のmath.h内の関数に渡してdecimalに与える場合に有効桁以下は切り落としとする方が妥当かもしれない、、、あるいは同一の演算で更に桁数の多いdecimal互換のものを内部演算用として自前で作るか、、、だが :-<

しかし無理数の誤差を上手く閉じ込める上では相対桁数 (一応decimalも「浮動」小数だが、あくまで整数1の桁が含まれる形で範囲が縛られる為NG) の方が何かと便利な事もあるものだなぁ、とか周期関数 (というか三角関数だが) の実装など色々調べてて思うのも結構楽しい.

# 対数関数や三角関数の実装なんて10年ぶり位かなぁなどと色々誤差や収束の調整周りをいじりつつ、ふと (確か) 浮動小数プロセッサのエミュレータを書いていたという人がいた事を思い出す、「もう2度とやりたくない」と言っていた気がしたが、さもありなんなどと思ってみたり、どーでも良いけどSSEは高階関数命令はサポートしてないとの事、ちと残念だが、これをハードで実装するのは色々大変なんだろうなぁと以前聞いたハード屋さんの話なども思い返し考えることしきり、ソフト屋としては最低atanは欲しいとか好き勝手言うのだけどねー(笑)

先日decimalをいじってから久しぶりに多倍長演算についてあれこれ考えている、以前RSAを実装する為多倍長の「整数」演算については実装したのだが小数以下を扱えないのが少々気になっていた、とは言え固定小数 (正確には小数以下10^nの固定桁数) なら特殊扱いは乗算のみで他は整数と変わらず、そんなに実装は難しくない事もあり昔のRSAのソースを引っ張り出して色々眺める. ただ多倍長にしても有限桁しか扱えない上での憂鬱がある、よくdoubleに関する議論で0.01を100回足しこんで誤差があると示すサンプルがあるが、似たような例は一般的な多くの多倍長やbcd表現でもある事で(※1)

bignum a=1;
bignum b=3;
a=a/3;
print(a); -> 大抵の多倍長処理系では0.999999...のように表示される.

実際には演算単位で最終桁の丸めなどは処理系に依るので完全に一致する訳ではない.
例え丸めが入っても演算によっては例えばa=5の場合など出力結果は 5.00000000000001
などのようになるケースもありこの手の問題を抜本的に回避し得る問題ではない.

分数表記をサポートするのも手ではあるが、以前テストした所では演算の累積で極めて容易に莫大な桁数になり、今度はRSAの根拠にもなっている最大公約数の問題が浮上する. 更にどのような演算についてもとなると結局完全を期するには数式処理系に相当するものを実装しなければならない、そして世の中には「完全にどのような式も集約・簡略化可能な」数式処理系は存在していない、解析的に作れるものでも無い為.

まぁ結局の所doubleの演算も、昨日の(C#なども含めた)decimalも、より桁数の多い多倍長の演算も、そのデータ表現の特性ごとに気を使う個所というのは必ず出てくるものではあり、複雑な演算を行う場合の計算自体の解析を免れ得るものでもない、まぁあえて言うならdecimal等の方がそういう臨界の部分が人間にとって「まだ」分かり易いという程度か.

まぁそんな具合で実装に意味あり哉無し哉などあれこれ考える. まぁ数値と計算というカテゴリは人間にとってコンピュータがどのように道具足り得るかの一番プリミティブな個所として結構楽しくはある ;-)

※1) こういった紹介無しに0.01を足しこむ例だけを示しdoubleに誤差があると論ずるのは余り適切な例とは言い難い気がするが如何？:-P

# まーもっと突き詰めると結局doubleというのは現実世界の「量」をコンピュータ上で扱う為の道具であり、decimalに代表されるのは人間が現実においてUtil化している「数」の概念をコンピュータに落とし込む道具であるとも言える (少々分かり難い例えかもしれないが) そういった意味においてはそもそも全く「素性」として別物とも言えるのだが ;-)

ペイントソフトを色々いじりながらMSDNを見ていた所 VarDecAdd (oleaut32.dll内) というAPIを見つける、Webで検索してみても殆ど言及が無いのだがつまりはVB6の内部演算や.NET Frameworkで実装される128bit decimal型 (符合 + 96bit整数 + 10の累乗(0〜-28)による10進浮動小数表現、整数部+小数部合計で有効精度28桁) に対する演算と同等のものである模様.

という事で寄り道してC++で演算子のオーバーロードなどを行うラッパを作成、公開されているVarDecRoundやVarDecIntなどの変換は基本的にVB類似の変換 (Banker's roundや負の無限大方向への切り落とし) を行う為、この辺りをWin上のCコンパイラ実装やC#における演算と一致させる(0方向切り落としや通常の四捨五入) など幾つかのUtilも作成、また精度に関係するのでfloor/ceilなど変換周りも自前実装になったが、一応自前実装しなくても安直に.NET標準程度のdecimalなら扱える模様、とは言っても自分の場合decimalが必要になったケースなどまず無いのだが、、、まぁ一応選択肢は多いに越した事はあるまい(笑)

まぁ実際こういうものは内部表記まで含めて限界も理解した上で使うものであり、安易に 「decimalならdoubleより精度が良い、誤差が出ない」 などといった理解で使うものでは無い為、各々が自前で作るべきものなのだろう、という所にてAPIの覚書きのみにて ;-)

※) なおdecimalもまた小数点位置が固定では無い為 (decimalを固定小数と説明している言及もあるが間違い) 演算される数どうしの相対範囲での精度を保証するだけで演算パターンによっては当たり前に情報落ちは発生するし、分数表現でもなく有限精度である為、無理数の丸め誤差や桁落ちなども立派に発生する. あくまでdecimalの表現領域での小数以下を持つ数の2進化誤差や整数領域での概算値になるのを防止する程度のものに過ぎないので、過信すべきものでは無い (これは世間一般の多倍長演算などについて言われる「幻想」についても同様) その辺の論説無く「誤差が出ない」などと (舐めきった内容が) 書かれているのを見ると妙にイラッとしてしまう (というか思いっきり (比喩ではなく実際に) 蹴りを入れたくなる) のだが :-P

※) ついでに (上の形式のdecimalは) 指数表現での概算値での表現を許容せず表現可能な値域が狭い為、doubleに比べ極端な定数や演算結果が発生し易い科学技術計算などには逆に全く向かない事にも注意が必要 (doubleをutilとして使う「ユーザー的な」演算だけでなくソルバ実装や高階関数近似のアルゴリズムなどに影響する場合もあるので注意). (開発で色々調べていた所decimalがあればdoubleいらないという発言を見かけて正直唖然としたのであります、ええ)

リハビリがてらPHP等のweb系周辺を色々いじっていたのだが、ふと思い立って自作言語に埋め込み形式のスクリプトを実装する、<% (or<%=) 〜 %>で囲まれたという良くあるアレ. とは言ってもこれでCGIを書くつもりは無いので (できなくは無いが、それ用のAPIセットを充実させる気は無いので;-) あくまでソースコードの自動生成用という所.

文字列やプリプロセッサの整合性の関係上、別プログラムにするよりは本体に実装する方がメンテナンス的に後々面倒が無いという事で実装したのだが、構文解析の初期ステートが違う事やプリプロセッサ機能との相性などで結構難儀する、実装は1日だったが、コードの破綻無く入れ込む事を考えていたら結局2日あれこれ考えてなので正味3日程、、、追加したコードは数百行程度なのだが(苦笑)

プリプロセッサ部の改修も必要であった事や行列処理言語と一部ソースを共有している個所の修正などを含むと意外と面倒な作業になった (両方合わせると既に10万行以上コードがある:-<) ちなみにこの自前言語、ロジックや計算モデルのプロトタイプに使うケースが殆どなので、今回の想定のようなソースの自動生成を使う頻度はせいぜい1ヶ月に1回程度、、、まーそんなものだろう(苦笑)

という事でリハビリ終了につきまたペイントソフトに戻ります、saiのバージョンアップもあった事ですし(笑)

# ま、しかし思うのは最近日記が実装の細かい話やその他思想的にも突っ込んだ内容が書いてなくて 「面白く無い」 事ですな. やってる事で細かいノウハウや社会・企業・人間観察の情報の蓄積は色々あるんだけど、逆に現在が面白い状況な為、その界隈をニヤニヤしながら見ている僕としては下手に手がかりは出さないでどう推移するかを観察するのが楽しいという事なんでまぁ勘弁して下さい(^^;;

以前からちょくちょく話題にはなっていたものの、ニュース番組を見ていた所、遂に「あの」ブラックホールをも生成し得るかもしれない加速器が稼動を開始したそうな、詳細記事はここ. ニュースのコメントではこのまま行くと年内にも人工のブラックホールが作成されるみたいなコメントであったのだが、結構この手の話題に対する番組のコメントはいい加減だったりするので、果たしてブラックホールを作る事が目的なのかは知らない、上の記事を見る限りではビックバン直後の高密度状態を再現する事でヒッグス粒子の検出などが目的っぽい気もするが、、、

万一ブラックホールが出来たとして、多分ホーキングの放射仮説 (事象地平付近での真空の揺らぎにより対生成された反物質が流入する、だっけ?) の通り蒸発してしまうから安全という話なんだろうか、確かに小さい方が蒸発しやすいらしいけど正直計算した事も無いし(って普通無いけど) まぁはいそーですかとして見るしか無いワケであります(苦笑)

まぁ万一放射-蒸発のメカニズムが機能しない等で地球がブラックホールに飲み込まれたら、事象地平に飲まれる近くでどんどん時間がゆっくりに(外部から)見える等、我々の認識する4次元空間の極限に近い所を目の当たりにできると考えると、それはそれで価値のある事かもしれません(ヲイ

無知(※1)故にちょっと怖かったりもしますが、同時に楽しみでもありますという所でしょうか? (まぁブラックホールなんてセンセーショナルな事は置いといてもヒッグス粒子の検出は凄い事) さて(笑)

# これでマジで地球ごと滅んだらシャレにならんよなー、あはははは.

※1) あるいはハレー彗星の到来と同様後世に馬鹿話として語られるのか、はてさて(※2

※2) <9/11追記> 何でも自殺者まで出たそーな、やっぱり前世紀初頭のハレー彗星騒動のようだ、うーむ :-<

減色ルーチンをライブラリ化した時点で「何となく」煮詰まる、特に原因は無く気分の問題だけでたまにある事、潜在意識下では多分最近アンテナに「面白い」ものが引っかからずイライラするとかそんな所だろう、片手間にFlexなどやっていたのも逆に悪かったかもしれぬ. 暫く放っておけばまた無性にプログラム書きたくなると思うので暫し休息.

ペイント機能をいじりながら、やっぱり断然「下のレイヤーと混合」機能はあった方が良いよなぁなどと悩む、基本的にはレイヤー2枚で上のレイヤーに塗って定着を繰り返すカンジ、本当は表示イメージで混合できる方が良いのだが、これをやるには混合用の結合イメージをもう1枚内部的に用意するか、背景色&透明部分のチェッカー表示をオミットしなければならないので難しい所. しかし最大の問題はこれがデジタルにおけるワークフロー特有の考え方で分かり難いという所か :-<

ペイント機能で色々手法の検証をしながら 「(ペイントソフトに限らず) やはり最後は人次第という事だな」 などといつもの結論に行き着き凹むのも良くある事.

個人的メモ.

Chromeのプライバシー機能は穴だらけ？

つまりはChromeを通した幾つかのアプリケーションをユーザーを一意に特定するIDを付加してgoogle側でロギングしているという話、後関連した話でgmailを使ってはいないので知らなかったのだが、gmailはメールの内容を解析して広告を付加する機能もあるのだそーな、、、まぁちとgoogleの社員活動経由で出てくるモノに対する評価と製品を通した経営戦略に対する評価をもう少し下げた方が良いかもしれぬ:-<

まぁ別にアンチgoogle云々(※1)では無く、最近友人と技術と絡めた経営戦略の話をする事が多いので、その時の話題向け備忘録という所 ;-)

※1) 現状慣例的にはあまり良くない話だし、個人的に使いたいと思うものでは無いが、そのリスクを差し引いても普及するという見込みの賭けに出たのか、あるい戦略の一環としてどうしても必要であったか、または単なるweb系企業にありがちなwebを過大評価し過ぎる事によるマヌケ故の行動か、そして実際それが既存の文化に対しどのように作用するか、という部分にしか正直僕は関心が無いのですな:-P

減色処理、取り敢えず256色については納得が行くものができたカンジ、こんな具合. 若干弱点はあって色数を落とした時にパターンの影響が顕著な事が難点ではあるが (今回の検証の範囲内ではほぼいずれのソフトにおいても) 無作為の画像を「絵」として捉えるなら最低180色程度が元画像のイメージを破壊しない臨界点であるようなので、最重視は256色(8bit)としてそれ以下に関する微調整はまぁぼちぼち調整する形で行く.

前のエンジンはある程度自分の中で妥協があったのだが、今回自分の価値観を満足できるというのは実に気分の良い、まぁ実際上のエンジンはまだ使い道が定まってない部分もあるのだが(ヲイ

# そして大抵こういうプログラマーズハイというのは後で思いor読み返して赤面するものでもあるワケだ、そういった意味ではある意味無様也哉、まぁそれもまた良い :-P