yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2018/06 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
阪神大侵災
2006/05/05(Fri)23:36:05
 今度は阪神が結構大変なことになっています。村上ファンドに取締役の変更を申し入れられているのですが、阪神側は断固反対とか。
 私にとって野球などどうでも構わないのですが、村上ファンドが阪神の株を売り抜けるにしても、阪神を支配して資産を売り払うにしても、どちらにせよ極めて腹立たしい行為です。仮に村上側の提案が受け入れられれば、取締役は村上側9人、阪神側7人。村上側のうち1人はやや阪神サイドに近いとはいいますが、さてどうでしょう。
 ともかく恐ろしいのは、阪神は一応電鉄会社です。こういう公共インフラがやすやすと卑怯な成金ファンドに資産目当てに支配され、資産を切り売りされるようでは大変なことですし、仮に経営にまでかかわってきたらなおさら大変です。ああいう他人のことを何とも考えぬファンドが公共機関を支配しようものなら、また福知山のようなことを起こす可能性すらあります。
 最悪のシナリオは、阪神が消滅することでもなければ、村上氏が球団を操ることでもありません。土地を切り売りされることでもありません。おそらく村上氏としては、とっとと株なり土地なりを売り抜ければそれで良いのでしょうから可能性はかなり低いですが、これが電鉄の経営にかかわって大事故を起こすのが最悪のシナリオなのです。
 米国で仮にこういうことをすれば、そうしたファンドは袋叩きの目にあいます。そして、その後はもう誰からも支持してもらえないそうです。日本でもそういう機運はできつつありますし、特に村上氏はTBSを売り抜けたり、阪神に手を出したりと、注目度の高い行為を連発しています。誰もが村上ファンドを嫌うのは当然というものです。
 ところが、米国と違って日本はまだ「最低ファンドは即時消滅」とはいかないようで。「ライブドア被害者の会」の方は「日本は当然のことが認められない国」と称していましたが、要するにそういうことです。詐欺によって株主が損害を受けても、立証その他の責任は株主が持たねばならず、さらに他者を何とも考えぬ最低ファンドは市場から駆逐されないのです。
 しかし、望みがないわけではありません。経済を少しでも理解している人なら、村上ファンドに対して怒りを抱くのは当然ですが、そういう機運が高まれば企業や政治家も村上ファンドと関係が持ちづらくなります。さらに、法改正によるファンド規制も進むでしょう。こうしてジリジリと締め上げていけば、村上ファンドといえども消失することになります。
 それと、取締役の洗い替えですが、村上側に1人「阪神寄り」の人が混ざっており、仮に村上サイドが自己都合で何かを決議しようとしても、この人が反対すると決議は成立しない仕組みです。その本人も「私は村上サイドではない」と自称しているようです。
 では、この提案は受け入れるべきなのか。それがそうとも言い切れないのです。仮に村上ファンドが国民からの批判を和らげるために「暴走防止」を組み入れたのだとしても、不正スレスレの方法による株の買い占めや売りぬけなど、村上ファンドが暴挙を行っているのに変わりはありません。
 さらに、この人が実は村上側の人間であり、阪神を懐柔させて提案を受け入れさせるための「道具」なのだとすれば、提案が採用された直後から村上氏が腕を振るうことがあり得るのです。あらゆる可能性を考えるなら、これを安易に受け入れるのは危険性が高い行為です。何といっても鉄道は公共インフラですから、利用者に迷惑をかける方法だけは採ってはいけません。

 JavaのJDBCにはDate及びTime、Timestamp型があり、それぞれjava.util.Date型を継承しています。つまり、java.util.Dateに定義されたメソッド(getTime()など)を呼ぶことができるわけですが、何でもミリ秒まで扱うことができるとのこと。
 ミリ秒まで使えるとは初耳です。というのも、Servlet Chat企画ではミリ秒まで保存する精度が欲しかったため、時間データをVARCHARで保存するハメになりました(別にBIGINTでも構わないのですが、チャット内部ではデータをStringで扱っているため)。しかし、ミリ秒まで扱えるのであれば、DATETIME型を使わない理由はありません。
 そんなこんなで、まずは使い方の習得からです。DATE型をjava.sql.Dateに読み込むJSPを書いてみました。
Context ct = new InitialContext();
DataSource ds = (DataSource)ct.lookup("java:/comp/env/jdbc/MySQLJSP");

Connection c = ds.getConnection();
Statement s = c.createStatement();
s.executeUpdate("CREATE TEMPORARY TABLE ttime(dt DATETIME)");

c.setAutoCommit(false);

PreparedStatement ps = c.prepareStatement("INSERT INTO ttime VALUES(NOW())");
ps.executeUpdate();

ResultSet rs = s.executeQuery("SELECT * FROM ttime");
while(rs.next()){
	Date d = rs.getDate(1);
	out.println(d.toString() + " " + d.getTime());
}

s.executeUpdate("DROP TABLE ttime");
s.close();
c.close();

// Result
2006-05-05 1146754800000
 1146754800000とは、これまたキリのいい数字だことで。しかも、何度読み込んでもこの数値です。試しに60*60*1000で割った余剰を求めたところ、あまりはゼロでした。どうやら、少なくとも1時間単位または1日単位の精度しかないようです。これでは話になりません。
 そんなこんなで、次はTime型を試してみました。とはいえ、SQLのテーブル型をDATETIME型にしたままではエラーが出るため、こちらもTIME型としました。
s.executeUpdate("CREATE TEMPORARY TABLE ttime(dt TIME)");

c.setAutoCommit(false);

PreparedStatement ps = c.prepareStatement("INSERT INTO ttime VALUES(NOW())");
ps.executeUpdate();

ResultSet rs = s.executeQuery("SELECT * FROM ttime");
while(rs.next()){
	Time t = rs.getTime(1);
	out.println(t.toString() + " " + t.getTime());
}

// Result
22:47:46 49666000
 こちらの精度は秒単位。やはりMySQLでミリ秒は使えないようです。ミリ秒を使いたければ、BIGINTかVARCHAR、DECを使いましょう、ということで。例えばBIGINTならlongで取得してjava.util.Date型にセットすればOKですし、VARCHARならLong.parseLongで。
 しかし、ここで問題が1つ。これではSQL DATETIME型が扱えないのです。JavaのDate型では値の精度が低くなりますし、かといってTime型を使うとエラーが出てしまいます。仕方がないので、私らしい小細工を使ってみました。
s.executeUpdate("CREATE TEMPORARY TABLE ttime(dt DATETIME)");

c.setAutoCommit(false);

PreparedStatement ps = c.prepareStatement("INSERT INTO ttime VALUES(NOW())");
ps.executeUpdate();

ResultSet rs = s.executeQuery("SELECT * FROM ttime");
while(rs.next()){
	Object t = rs.getObject(1);
	out.println(t.getClass().getName() + " " + 
		((java.util.Date)t).getTime());
}

// Result
java.sql.Timestamp 1146837168000
 この通り、正しい精度が得られました(ミリ秒が使えないのは残念ですが)。どうやらDATETIME型はjava.sql.Timestamp型で処理するようです。これには気づきませんでした。というのも、MySQLのTIMESTAMPは非常に限定的なものであり、所要領域は小さくて済むものの、2037年問題を回避できませんので、今から使うようなものではありません。2037年までテーブルを使う気がないとしても、もしSQLのベンダが2037年問題をクリアできるようにTIMESTAMPの動作を拡張すれば、不整合が起きる危険性すらあります。
 その点DATETIMEは9999年まで使うことができますので、2037年問題は回避できます。ですから私はこちらを好んで使うのですが、上記の通りSQLではDATETIMEとTIMESTAMPは厳密に区別されたものですから、Javaでは混乱を招きます。しかし、JavaのTimestamp型はしっかり2037年以後の日付を表せるのでしょうか。
 そんなこんなで'4096/03/17 00:00:00'をセットしてみた結果、JavaのTimestampで正しく扱うことができました。ついでに、java.util.Dateに定義されているgetYear()に1900を足してみたところ、しっかり4096が返ってきました。SQLのDATETIMEで扱えるのは9999年までで、Java Date型で扱える年数は理論上3000億年弱になりますから、当分は年号の不安を抱く必要はなさそうです。

 ついでに「続・素早さ考」。先に「素早さは相対的に評価するものである」と述べましたが、なかなか難しいのです、これが。
 例えば、行動の基準値が100であるとします(素早さを加算していき、これに達すると行動できる)。そして、素早さ20のキャラと10のキャラがいるとします。すると、20のキャラは10のキャラの2倍行動ができることになります。ここまでは良いのです。
 ところが、素早さの基準が100なのに、キャラの素早さが1000や500になったらどうしましょうか。行動後には素早さの加算値がゼロにリセットされるのであれば、両者とも同じだけしか行動できないことになり、素早さシステムが破綻します。かといって、行動するたびに加算値から基準値分(100)を減算するのでは、一見上手くいきそうですが、これもまた破綻します。
 例えば魔道士イリアスの素早さ加算値が1000、騎士サーラが500とします。基準値が100であるなら、両者とも行動できることになります。この場合、加算値のより高い魔道士イリアスの方を先に行動させるとしましょう。すると魔道士イリアスの加算値は100減って900、騎士サーラは変わらず500。また魔道士イリアスが行動できます。そうすると800と500になり、また魔道士イリアスが行動できます。素早さが2倍しか違わないのに5回も連続行動されようものなら、これではゲームバランスもへったくれもないです。
 これを回避する手段としては、基準値を十二分な値にしておくなどの方法がありますが、やり込むようなゲームなら素早さが何十万、何百万まで上昇してもおかしくありません(ちなみにTactical Revolutionでは正規の手段ではレベルは99までしか上がりませんが、intの範囲内なら100だろうが1億だろうが2^31-1の範囲までプログラマーが好きなように設定できます)。ということで、これではループに時間がかかってしまうなど、弊害が目立つようになります。
 となると、やはり素早さは相対評価でなければならないのです。そこで私が実装したのが、最も素早いキャラの素早さを基準値とするプログラムです。基準値に矛盾が生じる理由は、要するに「素早さが基準値を上回るから」なのですが、この方法なら絶対に素早さは基準値を上回りません。
 が、ここで問題になるのが「素早さが変化した場合」。最も素早さの高いキャラの素早さが、ステータス変化によって増減したり、そのキャラが消失したり、またはもっと素早さの高いキャラが現れたり、といったことはあり得る話です。この場合は素早さの基準値も修正しなければなりませんが、ただ単に修正するだけでは問題が出ます。
 例えば素早さが100のキャラと10のキャラがいるとします。この場合、基準値は100です。が、素早さ10のキャラが加算値90まで行ったところで、素早さ100のキャラの素早さが5になってしまいました。この場合、基準値は10に設定し直されますが、そうすると素早さ10のキャラには加算値が90あるわけですから、9回連続行動ができてしまいます。
 かといって調整しなければ、例えば素早さ100のキャラと50のキャラがいたとして、両者が加速してそれぞれ600と200になったとすれば、基準値が100のままなのに素早さが600という状況になってしまい、やはり破綻します。
 というわけで、こうした問題を解決し、素早さの変化があっても対応できるようにするための実装をちまちまと。不毛ではありますが、こういうのを考えるのもなかなか面白いものです。

 SQL.32。最近少しばかり疲れているようです。SQLに限らず。

 どういうわけか本日は皆さん大憤慨。その矛先は・・・。

剣聖ハードゥン「サーラ君、これはどうなっているのだ?」
騎士サーラ「え?何がですか?」
剣聖ハードゥン「実はな・・・。私がまとめておいた我が国と周辺国の軍事力データが、イリアス君のアカウントによって消失させられたのだ。幸いバックアップはあったが、数日分の作業がパーだ。これでは我が国の保安上、重大な結果を招きかねない」
騎士サーラ「えっ、ハードゥンさんもですか?」
剣聖ハードゥン「どういう意味だ?」
騎士サーラ「実は私も、ノートに理力の計算をしていまして、とんでもないことになったのです」
剣聖ハードゥン「とんでもない・・・?」
騎士サーラ「さほど大きな力は生じない計算のはずが、物質750mgの質量エネルギーに相当するジュール値が得られまして・・・。こんな原爆のような力が生じるわけがないと考えて、資料を見直したところ、ノートの数字が1箇所だけ書き換えられていたのです。力の計算では、一部の数値を変更するだけで、大きく内容が変わってしまうことがあります」
剣聖ハードゥン「何かの間違いではないか?」
騎士サーラ「いえ、間違いありません。よく見るとその部分だけ、用いている鉛筆の芯の種類が違いました。それに、あれはイリアスさんの筆跡です」
イリスのシェリー「サーラさん、おられますか?」
騎士サーラ「シェリーさん、血相を変えてどうされたのですか?」
イリスのシェリー「誰ですか、師団の所有する建物の玄関部分が火災で消失したのを”減価償却”として仕訳たのは。その上ご丁寧にも、受取手形の増加を全部貸方に書いて・・・。世にも珍しい、受取手形による債務超過ですよ。おかげで検証に数時間・・・」
騎士サーラ「・・・これは、イリアスさんの字ですね・・・」
イリスのシェリー「しかも、保存しておいた”マクロ経済原論”の文書まで書き換えられて、大問題になるところでした。もしとっさに気づかなかったら、グレーナイトどころかデフレとデノミの区別もつかない人間呼ばわりをされかねませんでした」
弓兵アマンダ「イリアスはどこ?」
騎士サーラ「今度はアマンダさん、どうされたのですか?」
弓兵アマンダ「私の友人の結婚式にイリアスが現れて、”別れの予感”を熱唱して行って、後から私がとりなすのにどんなに苦労したか・・・。衣装がギンギラだったから、顔までは見えなかったけど、あの声は確かに・・・」
聖騎士シェイン「イリアスさんはどちらですか?作業中、何かおかしいと考えて調べてみたところ、統計の母集団が改変されていたのですが・・・。おかげで分散から何からやり直しです」

 とまあ、この通り、なかなか大変な状況になってまいりました。が、タイミングがいいのか悪いのか、そこに現れたのが魔道士イリアス。しかもなぜか傷だらけです。

魔道士イリアス「みんなそろって、一体何事なのよ?」
騎士サーラ「イリアスさん、どうされたのですか、そのケガは・・・」
魔道士イリアス「緊急の用があってね。本当はサーラに声をかけようとしたけど、理力の計算で大変そうだったから、近くにいた師団の仲間と出撃してたのよ。一言くらい伝えておくべきだったわね」
騎士サーラ「・・・とすると、イリアスさんはしばらく、外出しておられたのですね」
魔道士イリアス「ええ。ちゃんとした時間まで覚えてはいないけど、詳しくは師団のシオドアとフランシスが知ってるはずよ。それで、一体何ごとなの?」
騎士サーラ「実は・・・」
魔道士イリアス「ええっ!?私が?あのねぇ、理力の値を的確に書き直したり、帳簿や経済論をいじったり、統計を変えたり、そんな高度なことが私にできるように見える?大体みんな、私がやってるのを直接見たわけじゃないし、第一私は外出してたわよ」
騎士サーラ「とすると・・・師団の誰かが犯人、ということですか?」
魔道士イリアス「そういうことね。部外者が私の筆跡をマネしたりはできないし、この建物で堂々と行動して見つからないはずがないわ」

 それらしい人物を集めたところ、犯人候補はアリス、シャル、ミカエル、リサの4人でした。それぞれの供述は以下の通りです。

師団のアリス「私はやってないわ。ただ、最近シャルとリサがどうにもおかしいから・・・。犯人がいるとすればこの2人ね」
師団のシャル「私は無関係だ。もしこの中に犯人がいるとすれば、アリスとミカエルではないか」
師団のミカエル「全くの事実無根、私は何も存じません。ただ、アリスが犯人とは考えられません。私が考えるに、リサが犯人では・・・」
師団のリサ「えっ、私は知りませんよ。しかし、犯人はミカエル、シャルなのでは・・・」

魔道士イリアス「うーん・・・。私が考えるに犯人は3人以上じゃないわね。手口からして」
騎士サーラ「しかし、普通に考えても話が合わないのでは・・・」
魔道士イリアス「だから、今回の犯人は知能犯ね。犯人でない人は言っていることは全部正しいけど、犯人の場合は時に嘘の場合もあるわ。無論、嘘じゃない場合もあるわ。全く、厄介よね」

 さあ、誰が犯人なのでしょうか。迷宮入りになりそうですが、SQLさえあればそうはいきません。名探偵イリアスに代わって犯人を当ててください。

模範解答
 今回は、犯人は全員「知能犯」ですから、今回のテーブル構造は「1 = まっとう」「0 = 知能犯」で大丈夫でしょう。それにしても、いよいよもって全員知能犯とは。犯罪も進化したものです。最初は3人の中から犯人を暴くだけだったというのに。ついでに、最初から人数条項は盛り込んでおきます。
CREATE TABLE lie(lie BOOLEAN) ENGINE=HEAP;
INSERT INTO lie VALUES(TRUE) , (FALSE);

CREATE TABLE mem ENGINE=HEAP 
SELECT l1.lie AS 'alice' , l2.lie AS 'shall' , l3.lie AS 'michael' , 
l4.lie AS 'lisa' FROM lie l1 , lie l2 , lie l3 , lie l4 
WHERE !l1.lie + !l2.lie + !l3.lie + !l4.lie < 3;
 知能犯ばかりということで、話だけ見ると難しそうですが、人間があれこれ考えなくて良いのがSQLというものです。知能犯というのは要するに「ペテンのプロ」であり、嘘を見抜くには最初からその言葉を信用しない、つまり犯人の言葉は無視して考えるほかありません。相手が師団の不正犯だろうが、堀江だろうが、上祐だろうが。
SELECT * FROM mem WHERE (!alice OR (!shall AND !lisa)) AND 
(!shall OR (!alice AND !michael)) AND (!michael OR (alice AND !lisa)) AND 
(!lisa OR (!michael AND !shall));

// Result
alice	shall	michael	lisa
1	0	1	0
 おやおや、あっという間に出てしまいました。すなわち、犯人はシャルとリサであることが分かります。恐るべしシークェル。
 その後、師団のアリスの「シャルとリサはおかしい」という証言により、ある時点でこの2人が混乱をもくろむ別人と摩り替わっていたことが分かりました。

魔道士イリアス「ふーん、グレーナイトって本当にあるのね」
イリスのシェリー「ありますよ。ホワイトナイトは友好的、ブラックナイトは敵対的、グレーナイトはその中間というわけです」
魔道士イリアス「ホワイトナイトといったらサーラよね。カッコいいし。じゃあ、750mgの質量エネルギーって?」
騎士サーラ「物質375mgと反物質375mgを衝突させた際に生じる膨大なエネルギーです。それらの存在が消失する代わりに、質量として存在していた分のエネルギーを放出します」
魔道士イリアス「良く分からないけど・・・まあいいわ。じゃあ、統計って?」
聖騎士シェイン「母集団に対する集合と分散の値としては、SQLの各関数でも求めることができ、その際は母集団が仮に5、値が4.5、5.2・・・であるなら・・・」
魔道士イリアス「ああ、もういいわ。頭痛いわね」
騎士サーラ「シェインさん、分散から得られる経験的な平均として、256が・・・で・・・それが・・・」
聖騎士シェイン「その場合、経験上の平均値は・・・で・・・といったところですね」
騎士サーラ「・・・とすると、理力の影響力は・・・と、大体この辺りに・・・」
剣聖ハードゥン「シェリー君、例のことだが、調べてくれたか?」
イリスのシェリー「はい。B/Sの結果次第でPBRが・・・だから・・・毒薬条項が・・・筆頭がグレーナイトに・・・」
剣聖ハードゥン「なるほど。しかしそれだと・・・キャッシュフローはどうだ?」
魔道士イリアス「な、な、何よ。どうしてみんな、そう意味不明な言語をしゃべるのよ」
弓兵アマンダ「あ、イリアス。ちょっと聞きたかったんだけど。この場合のクラスモデルとして、このクラスの値をこっちに渡して、これを・・・」
魔道士イリアス「いや、その場合はそれを抽象にして、オーバーライドした方が効率がいいわね。そっちはスタティックにするといいわ。クラスのデータは関係ないから」
師団のアリス「何、このかみ合わない会話・・・。この師団、どうやって今まで続いてたのか、不思議でならないわ・・・」

 このように、SQLは知能犯発見にも極めて強い威力を発揮する逸品なのです。
カテゴリ [開発魔法][社会問題][ゲーム開発] [トラックバック 0][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

- Blog by yamicha.com -