TIM Labs

2013年8月アーカイブ

Azure SQLは便利ですがオンプレミスとは違うので不便な点もあります
そのうちの一つが(そして大きいのが)自動バックアップです

Azureの管理画面を通してのバックアップならできるのですが(保存先はBLOBも使用できます)それをバッチで実行するのが大変でした
大変というか事実上ツール頼りで、うちでは以下のようなツールを検討していました
http://www.idera.com/productssolutions/freetools/azuresqldatabasebackup

しかしついにAzure SQL 標準の機能として自動バックアップが実装されました(まだプレビューですが)

AzureSQLBackup.png

久しぶりにマジで得した気分です

1月31日の3ヶ月後は何月何日だろう?
C#で書くとこうなります

 DateTime d = DateTime.Parse("2012/1/31");
 d = d.AddMonths(3);

まあ皆さんの想像の通り4月30日になるわけですが少し前にこれが困った事態を引き起こしました。
図書館システムで返却日は貸出日の3ヶ月後というルールがあって、その通り計算していたのですが、それが上記のケースだったわけです。現場の感覚としては貸出期間が3か月未満になっておかしいということでした。

正直AddMonthsがありえない日を計算(上記では4月31日)を計算したときにどうなるのか全く知りませんでした。

ちょっと調べると(まあ調べるまでもないですが)表現可能なように日にち部分が削られるのが仕様なようです。まあデフォルトの動作はそんなものかな?と思って、じゃあこのようなケースで5月1日を返すようなオプションがあるのだろう、と探してみましたが... 見当たらない。あってもよさそうなものだけどなと思いながら、しょうがないので自分でルーチンを組みました。

組んでみて納得。AddMonthsの引数がマイナスの場合(さかのぼる)場合には「表現可能なように日にち部分が削られる」という今の仕様でないとうまくいかないですね。勝手に次の月にしたいケースは思いつきません。自作のルーチンではマイナスの場合は普通のAddMonthを呼ぶようにしました。

たぶんほかの言語でも同じだと思います。調べるの面倒なので調べませんが。
まあしょうもないネタですがDateTimeなんてありきたりのクラスにもまだまだ未知の部分があると知ってフレームワークの偉大さを再確認しました。


しばらく前に買って積読されていたので再度読み始めました
ゲーデルの定理を大学時代に知ったときは「結論はわかる。でもどうして証明可能であるという概念が実際に算術上の命題として表現できるのか?」を理解することができなませんでした。論文ではこの部分を丁寧に大量の中間概念を導入しながら証明していくのですが、個々が抽象的すぎてすぐに眠くなってしまうからです。

100年前にヒルベルトが目指した数学の完全な形式化、そしてその無矛盾性の証明は当時は高度に抽象的なものであったと思います。
しかし現在プログラミングを生業にしているとこの概念は極めて具体的で明瞭です。
なんせコンピュータとは形式的な記号の羅列をルールに従って操作しているだけなのですから。
ゲーデル数の概念はアセンブリ(プログラミング言語)そのものがビットの羅列で表現できることと同値だし、定理や推論規則の算術的操作への置き換えはCPUがそのビット列に対してビット操作(演算だ)するだけで動いていることと同値です。

そう、今回は違います。ゲーデルの証明を一つずつプログラム言語で記述してしまえばいい!
そういうことならHaskellでしょう。だってHaskellのプログラムってそのまま数学の証明みたいだもんね!

まあそんな野望を抱いて最初の1章を読み終え、さてそろそろプログラムを書くか...とHaskellに詳しい同僚に相談してみました

「無理っすよ、Haskellは述語論理(∀とか∃とか)を表現できないですから!Haskellに述語論理をのっけたAgdaってのがあります」

うーんなるほどね。世の中には大抵先を行く人がいるもんだな。
すげぇと感心しつつ、Haskellさえちゃんとやったことのない身としては恐怖を覚えたのでした。

まあ今回は本当に証明したいわけではなく、ゲーデルの証明をプログラミング言語で表現したいだけなのでExistとかForAllとかの関数を書けば済みそうではあります。とさっそく言い訳を...

AzureにはStickyセッションがない
なのでアプリケーション側でセッションサーバを用意することになるのだが、そのためにAzureが用意したのがAzure Cache Serviceです

ところでAzure管理ポータルの旧UIであるSilverlightバージョンの画面がとうとう廃止になるらしい

AzurePortal.png

しかし上記のようにAzure Cachingだけはなぜか新ポータルでサポートされません。よほど使われていないのか、黒い政治的な理由があるからなのか、技術的理由があるからなのかわかりませんが。

しかし問題はここからです。さっそくキャッシュサービスを管理してみましょう

AzureCaching.png
キャッシュで管理できる唯一の処理「キャッシュサイズの変更」を押します。
・・・何も反応がない、ただのしかばねのようだ

これ本当に焦りました。普段は小さめのキャッシュにしておいて費用を節約し、アクセスが増えそうな時に増やそうとしていたので
それがサイズを増やすことができない!

結局表示言語をEnglishにすることで無事キャッシュサイズの変更をすることができました。これが発生したのは4月なのでさすがに今は治っているだろうと思って(そしてこのブログのネタにするために)改めて試してみたのですが、いまだに日本語だとダメですね

日本でAzure Cachingを使っている人なんていないのか、みんなこのTIPSを知っているのか
何はともあれ、今後同じ問題にはまった人がこのエントリにたどり着ければいいなと思います
突然変異とは、文字通り、染色体のどこかを突然変更してしまうことである。

このパズルの場合には、ランダムに長方形を1つ選んで、その周囲を少々破壊して作り直すとかが考えられる。

しかし、これはほぼ確実にダメな染色体ができるだけに過ぎず、進化を促すような奇跡が起きることは極めて少なく、延々と計算が続き、欲しい結果が得られないまま終わることが非常に多い。

それで、少々工夫をしていみた。その工夫を以下の図にまとめてみた。

na-ga19.png

(1) まず、与えられた盤面をしっかり観察しよう。この問題を解くと、緑色の部分が確定し、右上の2、4、6の一部が決まる。

(2) ということで、どこでも適当に破壊するのではなく、ダメなところを破壊して作り直すことにしよう。ということで、候補は、この3つの長方形から選ぶことにしよう。

(3) どれを選んでも良いのだが、6を選択したとして説明を続ける。6の長方形と、それに隣接した長方形を破壊する、つまり白紙に戻すことにする。
ただし、隣接とは何かを決めないといけない。実は、あまりたくさん壊すと、悪影響の方が多くなる。少な過ぎると、意味がなくなる。それで、結局現在やっている方法は、選んだ長方形を上下または左右に±1だけ動かしてぶつかる長方形だけを白紙に戻すことにしている。それで、黄色で×をした3つの長方形を白紙に戻す。

(4) 白紙に戻してしまった状態である。この状態から、適当に長方形に切り直す。

(5) 適当に分割し直してみた結果である。

以上が、現在の突然変異の実装である。

白紙に戻した部分を再度分割しているが、この分割の方法次第で、どのように破壊するのが良いかが影響する。


さて、これで、交叉、突然変異ができたので、組み合わせれば遺伝的アルゴリズムが動くようになる。でも、現実はそんなに甘くないのである。動いて、一応問題は作れるようになるのだが、それほど良い問題が作れるようになる訳ではない。これは、このパズルの場合に限らず、遺伝的アルゴリズムは、対象分野毎に、いろいろな工夫をしないとさっぱり使い物にならないことが多い。

これについては、話が長くなるので、次回以降に説明しよう。


これまでのあらすじ

まともなオセロの対戦AIの作成を開始したものの、 「4手先を読む」だけでも検討にかかる時間が長く、 とても快適に遊べるとは言えない状態でした。 これでは肝心のAIの形勢判断を調整する以前の問題であり、 先読みする手数を増やしてAIの「腕前」を上げることも困難です。

Lv 4のAIとの対戦の様子

先読みする手数を減らせば快適に遊べるようにはなりますが、 それでは「目先のことしか考えない」弱いAIにしかなりません。 どうにかしてAIの動作速度を改善できないものでしょうか。

このアーカイブについて

このページには、2013年8月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2013年7月です。

次のアーカイブは2013年9月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。