TECHNERD::CAOSOUP 2.0

ここんとこPHPしか触っていない。PHP確かに便利だなぁ。しかし、全国郵便番号台帳を作ってて幾つかツボったので、ここにメモっておく。

・PHPのfgetcsvはマルチバイト環境下で正しく動かないケースがある。

どういう実装にしたらこうなるのか理解に苦しむが、一般的な半角ダブルクオーテーションで囲まれてる値が全角文字列でそれらに特定文字コードが存在している、という条件下のとき、正しく値を解釈してくれない時がある。動作確認したのは内部エンコーディングShift_JISでPHPのバージョンは4.3.9。

例えば、福島県田村郡小野町にある角十という地名がcsvの中に含まれていたらアウト。沖縄県八重山郡竹富町にある新城も同じくアウト。

おそらく全角文字の１バイト目に0xF8のコードがあればアウト。これはまずいと思う。結局自作のcsv解釈関数で対処。

・郵政公社配布の郵便番号データをそのままDBに投入するのは用途によってはよろしくない。

これは郵便番号の採番がよくないとは思うんだが、所謂「平成の大合併」でやたら増えた地名に対応しきれていない感じ。

例えば徳島県美馬市の一部地域。郵便番号で言うと777-0301。

余談だけど、美馬市、っつーか徳島県、吉野川流域は江戸時代に藍の栽培がヒッジョーに盛んで全国で９割超えるようなシェアを握ってたところだ。だから藍取引で財を成した大商人の邸宅後なんかが有名史跡。「うだつがあがる」の「うだつ」語源とかがソレ。

で、問題なのは郵政公社配布の郵便番号データのうち、同一郵便番号で複数行にわたっているデータだ。

郵便番号データはJIS自治体コード、７ケタ郵便番号、県名、市区郡町村名、地名…などと並んでいるのだが、例えばgooでの検索結果では市区郡町村名と地名を連結して表示している。

1． 777-0301 徳島県美馬市木屋平（市初、今丸、尾山、カゴミ、樫原、木中、桑柄、ケヤキヒラ、小日浦、
2． 777-0301 徳島県美馬市地神滝、菅蔵、杖谷、葛尾、ハジコノ、ビヤガイチ、二戸、三ツ木、貢、
3． 777-0301 徳島県美馬市南張、向樫原）

これ、正しくはこう表示されるべき。

777-0301 徳島県美馬市木屋平（市初、今丸、尾山、カゴミ、樫原、木中、桑柄、ケヤキヒラ、小日浦、 地神滝、菅蔵、杖谷、葛尾、ハジコノ、ビヤガイチ、二戸、三ツ木、貢、 南張、向樫原）

そりゃー些細なことかもしれんが、少なくとも正しくないし、僕の感覚でいけば「絶対許せない」表示になってしまうわけ。データベース投入前データを加工するのはよくないので、郵便番号検索プログラム側で対処する予定。この問題は木屋平に限らず、全国各地のおそらく人口密度低めのところで頻出するはず。

「木屋平なんて旧で言う村だしそこのエリアの人口何人よ」とか絶対言わないように。調べてみたら1200人ちょいだったけど気にしたら負けだ。

山の中なのにもかかわらず地名に「平」があるからヘンだと思って調べてみたら、案の定、平家の落人が拓いたとこだったのね。ちなみに四国、それも山の中方面出身で名字に「平」の字がある人は平氏の末裔なケースが多いです。もちろん「自称末裔」さんも含みますが。

で、この些細な問題のおかげで、全国ぶんの住所16万件に対して、データベースサーバが一時間に許可する問い合わせ回数が30万件。なのでデータ16万件を一括投入して、間違ったデータが含まれていることが判明したら１時間後にやり直すという斬新なゲームを十分に堪能しました。

・郵政公社配布の事業所の個別郵便番号が古い。
平成の大合併に対応してませんがな、このデータ。最新版が2006年7月末なのに。とはいえ置換するガッツが今のところないので、データが古い件は気づかなかったことにします。

郵便番号データを気前よくフリーで配ってくれるのは嬉しいんだけど、XML-RPCとかSOAPでアクセスできるAPI公開してくれませんかのう。郵政公社様。それがITってもんだと僕は思いますよ。

や、決して郵便番号データベースメンテナンスツール作るのがダルイとかじゃなくて。

オッス！　オラそろそろ手がヤバくなってきたぞ！

けど、あまりにも衝撃的だったので書いとく。

マインスイーパー自動処理マシン

実装は余裕で想像ついたけど、これ実際に作るのは結構手間です。もう何のためのゲームかよくわからなくなってきましたが、画期的プログラムに変わりはありません。

DirectX10はかなりの難産みたいだなぁ。

DirectX８、９と触ったことはあるんだけど、個人的な意見としてはどっちも失敗。ただ僕は3Dバリバリのプログラミングなんてやってなく、2Dプログラマとして意見。８のほうは3D表面から文字描画に必須のデバイスコンテキストが適正な速度で引っ張れない時点でカスだと思いました。CJKV言語族ナメんな、と声を大にして言ってみたい。

９は９で８の不満点が解消されたと思ったら、パッチが沢山出る始末。落ち着いてライブラリ化できねーと思いまして。や、８で一端中断してたんです。自作ラッパーライブラリ。友人からは「そうやってずーっとネジをこしらえてろ」と言われたこともありました…

で、結局、色々考えてOpenGLを触るようになったんだけど。こっちもこっちで色々問題あるっぽいけど、DirectXよりさらに歩みが遅いので僕にピッタリかしら。

大変興味深い確率の問題があった。

中学数学教材研究ノート++

サイコロが二つあります。そのサイコロは当然立方体です。当然６つ面があります。

その２つのさいころは、６つの面のうち、

３つの面が○マーク。

２つの面が△マーク。

１つの面が×マークが書かれているとします。

この二つのサイコロを同時に振ります。

何マークと何マークの組み合わせが、一番確率が高いですか？

直観で答えてから、自分で調べてみてください。

というわけで自分の中で答えを出してみてください。僕も直感で答えを出してみた上で、20分くらいで検証プログラムを書いてみました。だって僕の算数のセンスは絶対に信じられないのでー。

続きを読むと答えと解説が出ます。けどこれは大変面白い問題なので、本当に１回、自分で答えを出してみてください。でないと損するよ。マジでマジで。

昨日の続き

自分なりに色々調べてみた。
他所の処理系がどうなのかは知らないけれど、Visual Stdio .net 2003付属のC/C++にもπの定数があった。しかもmath.hに定義してやがんのな。しかしそれは_USE_MATH_DEFINESをインクルード前に定義しなければ利用できないわけで。

arctan(1)×4≒π
については、僕が理解した範囲で二種類の解き方がある。

１つめ。
arctan(1)というのは、内角がそれぞれ90度、45度、45度で構成された二等辺直角三角形のことだ。
なので、arctan(1)というのは、角度単位系で言えば45度のこと。
45度×4で180度＝πラジアン＝3.141592…という帰結。

２つめ。
arctan(x)をテイラー展開する。
このxに1を代入するとπ/4の近似値になる。それに4を掛けることでπだけを取り出せる。
パソコンで無理数を扱うことは出来ないので、sin、cosなんかもテイラー展開やそれに類する式で実現していることは想像に難くない。(ソースコードやANSIの定義書を探すのがダルイのでここでは追求しない)
ちなみに僕が先に理解できたのは、こっちのほうでした。

よって、arctan(1)×4≒π
と言える。C++の倍精度浮動小数点型で計算したところ、得られたπの値は小数点以下15桁まで有効な値でした。16桁目で誤差が出ちゃってた。

この検証によって判ったのは
・僕の頭は非常に飲み込みが悪い上、数学のセンスが著しく欠けている
・もうarctan(1)×4≒πは死ぬまで忘れないだろう
ということ。

お、なんか博士の愛した数式みたいになってきました。読んでないけど。あと、タイトルの読みは気にしなくてよろしい。

いきてまーす。

ついでに、忘れないようにメモ。

僕がメインで使ってるC/C++には円周率定数が無いしそれが正しい言語のありかただと思う。
有効桁数なんてのは実装と求める値次第で変わるわけで、道具であるところのプログラミング言語が無理数である円周率を勝手に桁切り飛ばした上で静的に定義していいなんて話は無い。
というわけで、僕は確実に暗記している範囲の値である
3.14159265
を毎回定義していたわけだ。これで宇宙の物理法則が乱れても大丈夫！あ、けど物理法則かわっても数の概念は変わらないか。

瀬戸内に浮かぶ瀬戸大橋や明石大橋は地球の丸さなんかも計算ずくで施工してるわけだけども、僕の場合はせいぜい描画まわりに使う程度だし。

ところが、プログラムで円周率定数を切るのは時代遅れっぽい？むしろ僕だけ遅れてた？

atan(1)×4≒π

逆正接に１ラジアンを与えたのち、４を掛ける。

これで算出できるらしい。

（煙草２本分くらいの計算時間）

…わからん。わかるひとはこの原理を高校一年生レベルが理解できるよーにメールで解説してください。

結局、プログラミング環境がうまくいってないので、あらかじめ用意されていたロボに意思決定ルールを設定しておき、放置することにしました。

今、９日目なんですが、結構面白い結果です。
僕が設定したロボ

えらいこと儲けてます。なんかランクインしてるし。売買記録を見る感じスイングをかけてるっぽい。

年利換算370%とかステキ成績です。

しかし、あんまり嬉しくないのは現金がびた一文動いてないし、何より自作プログラムじゃない、というのがあるんだろうなぁ。こういうのは自作してナンボだ。

結果を見てぼんやり思ったのは「トレードに人間要らなくね？」という極論。あくまで個人的に。

デイトレードでしたっけ？端末の前に張り付いて数値の動きをチェックして、売り買いの指示をする人とか。やってることが機械的なわけだから、自動化できる部分を手動でやってるわけで、効率わりー、と思っちゃうよねぇ。このロボの成績みると。

もちろん、株式市場がライブドアがらみ以外は安定上昇傾向という要素があってこういう結果になってるわけだし、仮想市場だからこれらロボットの売り買い結果は反映されてないし、手数料もかかってないわけで。

けど、これ本格的に勉強してロボ自作すれば、お金儲けできそうな気がするなぁ。