日々、吾ハ習ヒ試シ違ヒ試スナリ: .NET Framework のDictionaryの弱点
この記事の話ですが、
よくよく調べるとDictionaryEntryの配列が存在しました。
こいつは、PropertyがKey,ValueともにGetSetなので、
期待しているSerializeの働きを行うのに適合します。
これによってデータがSerialize、Deserializeされることが
確認できましたので、覚書ですが、ここに記します。
3/29/2009
一国の総理の地力
【ニコニコ動画】字幕つき【音声のみ】麻生太郎の健全な日本の話【2008.1.26】
これを聞いてもなお、彼の人が物を知らないという人がいるのなら、ぜひその発言を公にしてほしいなぁとおもいました。
一国の総理になるってすげーことだ。
これを聞いてもなお、彼の人が物を知らないという人がいるのなら、ぜひその発言を公にしてほしいなぁとおもいました。
一国の総理になるってすげーことだ。
3/27/2009
ゲームレビュー『セブンスドラゴン』
セブンスドラゴンのレビュー
このゲームは、ひさしぶりに長いことそれほどのストレスを感じずにやることができました。
キャラクターのかわいらしさについては言うことありません。ドラゴンのデザインもいい感じでした。システム的な面では王道といわれるターン制バトルでよかったと思いました。しかしバトルに関して、エグゾースト能力については使いどころに困ることが多くあり、またこれを有効に使える局面が限られすぎていました。またダンジョンではＭＡＮＡやゲージの温存を基本とするので結果的に使わないことが多いです。
ついでにいうと、ヒーラーのクラフトマナというスキルが尋常ではないほどの有用性をもっているのでこれによってダンジョン攻略のしやすさが格段に違います。またローグの小銭集めスキル、メイジのアイテム拾いスキルが有用すぎてアイテムがあふれて仕方がありません。倉庫がほしかったです。
自分は侍姫忍僧でやっていたのですが、姫の補助能力の有用性が半端じゃなかったです。侍の攻撃力の高さが群を抜いていたのも驚きました。ローグの吸血スキルは後半ダメージ合戦になるとほぼ無敵なのがバランスを著しく欠いている気もしました。そしてあまりジョブ間の連携攻撃を行うよりも、単純にバトルでの効率を重視したパーティ設計をしたほうが簡単だと思いました。
ちなみに最初期にはメイジが入っていたのでしたが、途中からヒーラーと交代しました。ヒーラーのクラフトマナとメイジの魔法攻撃力、明らかにヒーラーが有能です。そして後半、侍の攻撃力が強化後で大抵500でるので、正直メイジは空気でした。ローグも吸血で自動回復しながら戦闘をすることが通常化すると回復不要でＭＡＮＡの供給さえあればぜんぜん問題がなかったです。若干姫が空気ですが、補助詠唱と回復スキルで後列で攻撃をしのぎながら前列を補助し続けるという戦闘スタイルがとても効率的でした。
シナリオは、ご都合主義の某大作ＲＰＧに比べると残酷さを含んでいたので、個人的には満足でした。
システム的な面ではいくつかの問題があると思いましたが、全体的には我慢できるレベルでしたので、問題なし。ただキャラごとのスキル性能の差がありすぎるのが気になりました。とりあえずヒーラーのクラフトマナは根本的にずるいと思いました。
ただ2週目やりたくないです。もうすでに50時間超で最終盤です。
このゲームは、ひさしぶりに長いことそれほどのストレスを感じずにやることができました。
キャラクターのかわいらしさについては言うことありません。ドラゴンのデザインもいい感じでした。システム的な面では王道といわれるターン制バトルでよかったと思いました。しかしバトルに関して、エグゾースト能力については使いどころに困ることが多くあり、またこれを有効に使える局面が限られすぎていました。またダンジョンではＭＡＮＡやゲージの温存を基本とするので結果的に使わないことが多いです。
ついでにいうと、ヒーラーのクラフトマナというスキルが尋常ではないほどの有用性をもっているのでこれによってダンジョン攻略のしやすさが格段に違います。またローグの小銭集めスキル、メイジのアイテム拾いスキルが有用すぎてアイテムがあふれて仕方がありません。倉庫がほしかったです。
自分は侍姫忍僧でやっていたのですが、姫の補助能力の有用性が半端じゃなかったです。侍の攻撃力の高さが群を抜いていたのも驚きました。ローグの吸血スキルは後半ダメージ合戦になるとほぼ無敵なのがバランスを著しく欠いている気もしました。そしてあまりジョブ間の連携攻撃を行うよりも、単純にバトルでの効率を重視したパーティ設計をしたほうが簡単だと思いました。
ちなみに最初期にはメイジが入っていたのでしたが、途中からヒーラーと交代しました。ヒーラーのクラフトマナとメイジの魔法攻撃力、明らかにヒーラーが有能です。そして後半、侍の攻撃力が強化後で大抵500でるので、正直メイジは空気でした。ローグも吸血で自動回復しながら戦闘をすることが通常化すると回復不要でＭＡＮＡの供給さえあればぜんぜん問題がなかったです。若干姫が空気ですが、補助詠唱と回復スキルで後列で攻撃をしのぎながら前列を補助し続けるという戦闘スタイルがとても効率的でした。
シナリオは、ご都合主義の某大作ＲＰＧに比べると残酷さを含んでいたので、個人的には満足でした。
システム的な面ではいくつかの問題があると思いましたが、全体的には我慢できるレベルでしたので、問題なし。ただキャラごとのスキル性能の差がありすぎるのが気になりました。とりあえずヒーラーのクラフトマナは根本的にずるいと思いました。
ただ2週目やりたくないです。もうすでに50時間超で最終盤です。
画像処理
日々、吾ハ習ヒ試シ違ヒ試スナリ: 画像の補正
その後、該当するアルゴリズムを探す視点を変更。
すでに適応されている画像編集ソフトのフィルタの作者を探しに回った。
ＧＩＭＰ，Ｐａｉｎｔ．ＮＥＴにはＬｅｎｓＤｉｓｔｏｒｔｉｏｎというまさに探していたフィルタが存在する。
これらの作者を探して待っているとソースコードが出てきた。
今回見つけたのは、Ｐａｉｎｔ．ＮＥＴ用のフィルタです。
http://paintdotnet.forumer.com/viewtopic.php?f=16&t=21624
この掲示板の後半のほうにソースコードとＤＬＬを配っている方がいらっしゃいます。
この人が変数ｋを与えられたパラメータから生成してデータテーブル化して使っています。
これによって前回問題してしていた行列内の変数に対応していました。
今は、このソースを勉強し、自分のアプリケーションに合致するものに読み替えています。
この場合はソースコードをコピーしたことになるのでしょうか？
そもそも数式が存在するものに占有権を主張できるのかなぁ。
そしてぶっちゃけプログラミングは八割は誰かの模倣で成り立っていると思っています。
つまり占有権を認めてもらうと困ります。
ただアプリケーションになっているものについてはこの限りではないと考えます。
ブラックボックスになったものを解析するのはいいけど、
これを複製して自分のもののように主張してはいけないと思います。
その後、該当するアルゴリズムを探す視点を変更。
すでに適応されている画像編集ソフトのフィルタの作者を探しに回った。
ＧＩＭＰ，Ｐａｉｎｔ．ＮＥＴにはＬｅｎｓＤｉｓｔｏｒｔｉｏｎというまさに探していたフィルタが存在する。
これらの作者を探して待っているとソースコードが出てきた。
今回見つけたのは、Ｐａｉｎｔ．ＮＥＴ用のフィルタです。
http://paintdotnet.forumer.com/viewtopic.php?f=16&t=21624
この掲示板の後半のほうにソースコードとＤＬＬを配っている方がいらっしゃいます。
この人が変数ｋを与えられたパラメータから生成してデータテーブル化して使っています。
これによって前回問題してしていた行列内の変数に対応していました。
今は、このソースを勉強し、自分のアプリケーションに合致するものに読み替えています。
この場合はソースコードをコピーしたことになるのでしょうか？
そもそも数式が存在するものに占有権を主張できるのかなぁ。
そしてぶっちゃけプログラミングは八割は誰かの模倣で成り立っていると思っています。
つまり占有権を認めてもらうと困ります。
ただアプリケーションになっているものについてはこの限りではないと考えます。
ブラックボックスになったものを解析するのはいいけど、
これを複製して自分のもののように主張してはいけないと思います。
画像の補正
歪んでしまったカメラ画像を変換して、歪みねぇ画像にしないといけないのだが、ぜんぜんうまくいかない。カメラモデルによる理想的な変換行列については関連したところを見つけることは簡単だが、ただ画像を補正するものはなかなかない。そもそも歪曲収差のような変換は行列的には逆変換が存在しないっぽい？のでただ変換行列を逆行列に無理やり換えてもうまくいかないという罠。ちなみに理想的な変換行列に関してはそれぞれのパラメータを取得するに際して最大で１６変数だかで、計算して求めるには、大変な計算量になるらしい。またパラメータのいくつかにべき乗数が存在するので、数値が拡大されてしまうので、数値が大変なことになるっぽい。
そもそもこの行列をつくるときに面倒な点は、中心点からの距離によって使用されるパラメータが変化することである。単純に定数を入れるのではうまくいかない。いくつかのパラメータは変数である。カメラモデルでのパラメータとしてみると理想的な撮像モデルと実際のモデルでは、境界を形成する線が曲線になる。どのような曲線かはよく分からない。ただゆがんでいるのだ。
各点に対して変化するこの行列はｎで表現される式になっている必要性がある。というか、そうでないと扱いにくい。
そもそもこの行列をつくるときに面倒な点は、中心点からの距離によって使用されるパラメータが変化することである。単純に定数を入れるのではうまくいかない。いくつかのパラメータは変数である。カメラモデルでのパラメータとしてみると理想的な撮像モデルと実際のモデルでは、境界を形成する線が曲線になる。どのような曲線かはよく分からない。ただゆがんでいるのだ。
各点に対して変化するこの行列はｎで表現される式になっている必要性がある。というか、そうでないと扱いにくい。
3/23/2009
ダフ屋
http://jp.techcrunch.com/archives/20090317hypocritical-artists-and-secondary-ticket-sales/trackback/
ここに掲載されている日本語訳の記事はとてもまっとうなことを言っていると思う。
世間でのチケットに関しての奇妙な公正さの主張はとても気分の悪いものだ。違和感を感じる。
時間を割くことのできないファンはファンではないかのような物言いにいつも私は不思議な感覚になる。
もしダフ屋を完全に消し去りたいのなら、すべてのチケットをオークション制で売るがよい。ファンは自らの愛するアーティストへ多額の援助金(笑)を進呈することができる。だが人々は金で愛を測るのか、と問う。逆に問えるのは、時間で愛を測るのか、ということだ。一度市井に流出した商品がどのような経緯をたどろうとも、正直提供者は関心を持たない。ただ同じ商品を手に入れたものが、他人の取得方法に関して関心をもち、論争を行うだけだ。長い時間並んで買ったチケットに愛着をもつのはかまわないが、それと同様の品をあなたが購入したときの値段よりも高く買っただけの人をなじる権利をもつのか？それを斡旋した人をなじれるのか？それは時間をかけないで手に入れた誰かを見ることによって、自らがみじめになっているからではないのか？自らの愛が否定されたようでみじめなのだろう。では、それで減じるようなものを至高のもののようにしたがるのは、それが嘘だと思っているからだろう。
売買の仲介をしているものを不必要に悪く言うこともいい加減にしたほうがいいだろう。仲介人は仲介する際に自分がこうむるリスクの分は最低限確保したいものだ。自らが直接買い付けができたからといって、できなかったものへ分配を行う仲介人を悪くいえるのか？彼らがやりすぎるように見るときもあるが、彼らを破滅させたいのなら買わなければいい。実際それほどのうまみがでるわけではない。水物のような商品を儲けるために大量に購入すれば、潜在的な在庫の山が発生するだけだ。
自分の信条や信心に反するからといって牙をむいて吠え立てるのは、弱者である。むしろ吠え立てるのは、大抵弱者である。しかし本人たちは本来的に勝っていると考えているのに、なぜ牙をむくのか？それが私の違和感なのだと思う。
ここに掲載されている日本語訳の記事はとてもまっとうなことを言っていると思う。
世間でのチケットに関しての奇妙な公正さの主張はとても気分の悪いものだ。違和感を感じる。
時間を割くことのできないファンはファンではないかのような物言いにいつも私は不思議な感覚になる。
もしダフ屋を完全に消し去りたいのなら、すべてのチケットをオークション制で売るがよい。ファンは自らの愛するアーティストへ多額の援助金(笑)を進呈することができる。だが人々は金で愛を測るのか、と問う。逆に問えるのは、時間で愛を測るのか、ということだ。一度市井に流出した商品がどのような経緯をたどろうとも、正直提供者は関心を持たない。ただ同じ商品を手に入れたものが、他人の取得方法に関して関心をもち、論争を行うだけだ。長い時間並んで買ったチケットに愛着をもつのはかまわないが、それと同様の品をあなたが購入したときの値段よりも高く買っただけの人をなじる権利をもつのか？それを斡旋した人をなじれるのか？それは時間をかけないで手に入れた誰かを見ることによって、自らがみじめになっているからではないのか？自らの愛が否定されたようでみじめなのだろう。では、それで減じるようなものを至高のもののようにしたがるのは、それが嘘だと思っているからだろう。
売買の仲介をしているものを不必要に悪く言うこともいい加減にしたほうがいいだろう。仲介人は仲介する際に自分がこうむるリスクの分は最低限確保したいものだ。自らが直接買い付けができたからといって、できなかったものへ分配を行う仲介人を悪くいえるのか？彼らがやりすぎるように見るときもあるが、彼らを破滅させたいのなら買わなければいい。実際それほどのうまみがでるわけではない。水物のような商品を儲けるために大量に購入すれば、潜在的な在庫の山が発生するだけだ。
自分の信条や信心に反するからといって牙をむいて吠え立てるのは、弱者である。むしろ吠え立てるのは、大抵弱者である。しかし本人たちは本来的に勝っていると考えているのに、なぜ牙をむくのか？それが私の違和感なのだと思う。
3/22/2009
mac bookとの生活
とりあえずいえるのは、アルミボディは冷たいし、熱い。
またＢｏｏｔＣａｍｐを使用しようと考えているときには、かならず付属のＤＶＤを忘れずに用意しましょう。ＤｒｉｖｅｒのはいっていないWindowsは最低です。ちなみにＥｔｈｅｒ ｎｅｔもないので、Ｕｐｄａｔｅすらままならないので注意しましょう。
WindowsがＭａｃＢｏｏｋで動く必要性は本当はないのですが、動けば便利です。
あー、ちょっと気がついたのですが、Windowsでリムーバブル設定されているデバイスは任意のタイミングで抜き差しできるのですが、ＭａｃＯＳではそうではなくてまぁかならず所定の動作をするしかないです。
Ｍａｃでの操作は慣れると楽なのですが、机の上で使うことが前提なので、寝転がったり、床に直に置いて使うときには、なかなか使いづらいですねー。とりあえずタッチパッドの使用感はいい感じです。
それでまだiPhoneの開発に入っていません(汗）そうこうしているうちにiPhoneは3.0になってます。コピペや横向きでの入力ができるようになったらしいですね。まだしっかり文書を読んでいないので分からないのですが、頻繁にＯＳがＶｅｒＵｐされるのもちょっと考え物な気がします。
3/17/2009
システムの外
システムの外へ落ちたときには、何も保護してくれるものはない。
そしてシステムの内にいるときにそれを実感することが可能なのは、それを見ようと努めるときだけである。
自らが属するシステムがシステムの外を見ることを可能にする、しないということは国家でいうならば報道規制の有無がそれにあたる。ただし報道規制がなくても、報道を行う側がそれを見せ続けることを努力することが必要になる。これは不自然な働きなのでこれは努力するしかない。意志して行うほかない。これの時の自分は「自由」であるということもある。
さまざまな流れに逆らっているときに自由である。
また従いながらも、従うことを選択することが自由である。
そして自由であることを自らに任じるならばそれは意志して行うことに他ならないので、責任が発生しないことがない。逆に言うとこれを自らに任じていないのならば、その人には責任はないのだろう。
そもそも予見できないものに責任をもつことは無限の責任を負わせることに繋がるだろう。
もっともこれを言い出すと責任からはたやすく逃れることができるだろう。
しかしこれから逃れることはすなわち意思することを放棄することである。
この放棄を躊躇させるのは、システム外へ落とされることの恐怖でしかない。
システムの外へ落ちることをいとわないものはあらゆる責任からも逃げることを選択しうるのでないだろうか？またシステムの外をよく知るものはそれを選択しうるのではないだろうか？また恐怖を感じなければ、何でもできるのはないだろうか？結局恐怖がないときには躊躇させる強制力がないのではないか？これでいくと、身体的な罰則は根源的に強制力がありそうだ。拷問はそう考えると合理的な責任を負わせる方法なのかもしれない。まぁそれを行う時点でシステムの外の存在の扱いになっていて、責任を負うことによってシステムの中に回帰できるのか？
3/04/2009
.NET Framework のDictionaryの弱点
Dictionaryの弱点というか、クラスの設計上の弱点という盲点だと思うけど。
Serializeすることができない。
答えは復元することができないからだ。
KeyValuePairでのKey、ValueのそれぞれはGetしかできないので、その後の復元ができないのだ。しかし辞書クラスは外部にデータを取り出したい、ときもある。
しかもややこしいことに大体この一対一のペアになるようなデータ構造のものは結構あるという罠。
かといって、このために新たに構造体を作るのもなにか負けた気がする。
解決策は...わかりません。
さらに問題なのは、IFormatConverterとかいうSerializeのための変換インタフェイスがあるのですが、実装しなおさなければならないということ。GenericClassなんだから最初から実装してよ、って思いました。
PS.
もうどうしようもないので、拡張してしまった先の話
PS.2
このようなTopicに関する議論。ところどころ
冗長だと思うけど。
構文解析
数式の解析はだいたい正しく組めるようになった。
重要なのは、スタックの優先度が低いものから高いものへの再起構成かなぁ･･･
あとはOutOfIndex（ｗ
ただこの数式の解析については基本の演算子のみサポート
代入"="と等号不等号の演算子には非対応。
これらに関しては、数式とは別のレベルでの解析が必要になる。
代入と成否判定はもっと単純に表現すると、
X=AとA==Bなどの形式に変換されて、Xは変数、A、Bはそれぞれが数式である。
このときの記号はVerb（動詞）として振舞う。
そして動詞の振る舞いも自動詞、他動詞がある。
自動詞ならば X（arg1,arg2,...argN）
他動詞ならば A？B
だなぁ。
？は予約された記号で対応できそうだな･･･
まぁ、変数の宣言機能はつけなければどうでもいいかもなぁ。
自動詞と他動詞のたとえだと若干混乱するけど、言いたいのは記号の動詞的振る舞いだから、そこに注意。
3/03/2009
おもしろい関連性の高い語句の表示方法
http://www.fresheye.com/
ここのサービスのコトバノウチュウ
なかなかおもしろい表示法です。
ただの関連語句の表示よりはほかの語が目に付きやすくていいですね。
これに似たサービスを行っているところがほかにもあったと思いますが思い出せません。
確か検索語句との関連性を元に3次元に表示する『情報の海』のような表現方法もありましたなぁ。
3/02/2009
数式エンジン
どうもJudaです。
数式エンジンをようやく作れました。
計算は逆ポーランド記法にしたがって記述しなおしながら行いました。
変数の取得と代入もIronPythonの方式で行えるようにしました。
ただし新規に登録できる機構がついていないので、使い方は大体Shaderみたいな感じ。
これによって一列の数式なら計算可能になりました。
あとは構文解析を行ってIfStatementによる条件分岐が行えるようになれば、簡易のスクリプトエンジンとしては十分かなぁっと。
そのときには変数の宣言が必要になると思うし、また例外処理の厳密化が問題になると思う。
ちょっと思ったのですが、計算の演算子の優先順位で％と＾の優先順位がどのようになっているのか。
今回のエンジンは () > ＾ > */% > +- > = の順番で優先順位がついているのですが、これであっているのでしょうか？
まぁ ＾ が今回特別に必要なので追加しましたが、これでいいのだろうか？
登録:
投稿 (Atom)