全ての素数の積は偶数だと思ったんだけど

数日前に、『全ての素数の積が偶数なのが納得がいかない人たち』というのが話題になりまして。
「2×3×5×7×11×…が偶数か奇数か」という問題で、2を掛けてるんだから偶数に決まってるじゃん、と思ったんだけど、そうとは言えないんだそうで。

この話題の過程で自分が知らなかったことを教えてもらったんで、面白いので書いておきたい。

そもそも、数学的帰納法を使えば、n-1番目までの素数の積が偶数なら、それとn番目の素数を掛けた値は偶数だし、先頭は2だから、全部偶数じゃん。
と思ったんだけど、数学的帰納法は、無限に対しては使えないんだそうだ。
数学的帰納法自体は学校でも教わることだけど、そんな制限は聞いたことが無かったので、驚いた次第。

何故かと言うと、有限であればどんな大きな数になっても満たされる性質があったとしても、無限になった時もその性質を満たすとは限らないんだそうだ。
例えば、四角形の２辺を階段状に細かくしていくと、長さは１辺の2倍のままだが、無限までいくと対角線と等しくなる、という話がある。（→「√2 = 2の証明」あるいは「斜面と階段のナゾ」）（これはちょっと違う話か？）
今回の素数の積では、n番目の素数までの積は偶数だけれども、「無限になった場合でも偶数であると言うことは出来ない」ということになるようだ。

また、∞（無限大）は、“数”ではない。
2にどんな整数を掛けても偶数になるが、∞は数（整数）ではないので、掛けても偶数とは言えない。
というより、∞は数ではないので、掛け算が出来ない。
これをプログラミング言語で例えると、整数はInteger型であり、∞は無限型とでも言うべき別の型である。この異なる型同士の掛け算が定義されていない限り、そんな演算は出来ない。
この比喩はプログラマーである自分には非常に分かりやすかった(笑)
（Javaだと、+∞を表すPOSITIVE_INFINITYという値がDoubleクラスに定義されているが、便宜上Double内に定義されているだけ。
ちなみにdoubleでは∞に対する演算は定義されている。2で割った余りが0なら偶数、1なら奇数だが、「POSITIVE_INFINITY % 2」の結果はNaNであり、どちらでも無かったｗ）

---

ちなみに自分は数学家ではないので、厳密な話をされても分かりません。
厳密な話をしたければ、cocoatomoさんに振って下さい(爆)

追記：cocoatomoさんによる解説→Adventures in Wonder-infinite-land

DQ10 スキル上限140到達（ネタばれ有り）

DQ10でスキル140クエストのボスを倒した！

自分以外はサポで、構成は武闘家＋僧侶＋僧侶＋僧侶（自分）。
特筆すべきは、全員混乱耐性100％にしたこと。
なんか、今回のボスの攻撃をくらうと、たまに混乱するので。行動が奪われるのはつらいし、キラキラポーンをかける手間を省きたかったので。

武闘家のHPは450あったけど、僧侶は全員400未満（360～390）。
HPは450くらい無いとどうせ一撃死するので、僧侶のHPはそんなに重要じゃない。酒場でHP450なんてそうそう雇えないし。
むしろ聖女で生き残ることを考えると、多すぎても無駄になりそう。

雇った武闘家に無念無想（MPを回復する130スキル）があったのがラッキーだった。
今回のボスは戦っていると中盤くらいでMPが枯渇するので、それを乗り切るのがポイント。
武闘家の作戦を「バッチリ」にしておけば勝手にMP回復してくれるし、僧侶も余裕があればマホトラの衣を使ってくれるので、魔法の聖水を配る頻度が少なくて済むのはありがたい。
魔法の聖水を使えるのはプレイヤーだけなので、全員がMP枯渇してくると立て直しが難しいので。
（ちなみに10回くらい挑戦して、魔法使い＋賢者＋僧侶＋僧侶（自分）という構成も試したけど、MPが枯渇してからあっという間に全滅した＾＾；）
そういう意味では、1戦目は普通に勝てるので、どれだけMPを消費しないかというのも地味なポイント。魔法の小瓶を配って節約したｗ

武闘家の一喝も効くので、アタッカーは武闘家で良かった。攻撃力が低めなので、倒すまで22分もかかったけど＾＾；

行動指針としては、僧侶はホイミ・ザオラルが一番。ただ、2人がそれをやれば残り1人は別のことが出来るので、聖女・天使をかけていくのが良い。全員に聖女が付いた状態を維持できれば、かなり安定する。
自分が狙われた時は、走って逃げる。そうすると他のキャラが行動する時間が稼げるし。
で、攻撃を当てられそうになったら（まだ聖女をかけていなかったら）自分に聖女をかける。聖女はかなり短時間でかけられるので、これで生き残れる。

全般的に、サポを雇うのでなくプレイヤー同士でパーティーを組んでいれば、比較的簡単に倒せそうなボスであった。
それでも自分のようなライト層でも現時点で倒せたので、キツイけれどもけっこう良いバランスだったのかも？（リプレイする気にはならないけどｗ）

---

それにしても、魔法使い系の140スキルは寂し過ぎる＾＾；
僧侶の「たまにHP1で生き残る」は、ありがたいけどどれくらいの割合で発動するのか…。
スティックの「ティンクルバトン」も、テンションが2～3段階上がるとか仲間全員が上がるとかチャージタイム無しとかならまだ良かったんだけど。つーか、オーガ男が使えるもんじゃないだろ、これｗ（スティックはそういうモーションが多いが＾＾；）
魔法使いの「たまにMPを消費しない」も僧侶と同様。
賢者の「むげんのさとり」も、2段階アップなら最初に使いたいけど、チャージタイムがあるからなぁ。
両手杖の「復活の杖」くらいじゃん、魔法使い系の140スキルで喜んだのはｗ
あ、盾の「スキルガード」は魔法を使ってくるボスには有効そうなので、いいね！

AsakusaFW0.7.1 スモールジョブ実行エンジン

Asakusa Framework0.7.1が出た！
→リリースノート

今回の目玉は「スモールジョブ実行エンジン」のみだが、この影響はすごく大きい。

Asakusaアプリケーションは複数のHadoopジョブとして実行されるが、ジョブの入力データ量が少ない場合に「スモールジョブ実行エンジン」で実行することにより、通常のHadoopジョブより速く実行できる。
スモールジョブ実行エンジンにはHadoopジョブの起動時間（いわゆるHadoop税）が無いので、実行が速い。（JavaVMの起動時間、いわばJavaVM税はかかるけど＾＾；）
スモールジョブ実行エンジンと通常のHadoopとの切り替えは、各ジョブ毎に、実行時のデータ量に応じて自動的に行われる。

Asakusaアプリケーションを作成すると いくつかの小さいジョブが生成されることがあり、小さなジョブは実行時間のほとんどがHadoop税となって、無駄が大きかった。
こういった「スモールジョブ問題」への対処として、今までにもYAESS JobQueue等があったが、環境構築が大変だった。

スモールジョブ実行エンジンを有効にするには、実行環境のASAKUSA_HOME/core/conf/asakusa-resources.xmlに以下のような設定を追加するだけでよい。
（『Hadoopタスクの最適化設定』を参照）

    <property>
        <name>com.asakusafw.inprocess.limit</name>
        <value>10485760</value>
    </property>

ジョブの入力ファイルの合計サイズがこの指定（10485760＝10MB）以下の場合はスモールジョブ実行エンジンで実行される。
（なお、このサイズを大きくし過ぎても逆効果で、OutOfMemoryErrorになったり、Hadoopで分散した方が速くなったりする）

実際、スモールジョブ実行エンジンを使用するだけで、実行時間が短縮されたバッチがあった。

未使用	使用	総ジョブ数	スモールジョブ数
約50分	約15分	約184	約180
約8分	約3分	約20	約17
約65分	約52分	約60	約10

上2つはかなり極端な例で、ほとんどがスモールジョブ＾＾；なので、3倍くらい速くなっている。
一番下のバッチはほとんどが大きなジョブだが、それでも20％くらい速くなっている。特にこの環境はAmazon EMRなので、1時間を切ると嬉しいらしいｗ（課金が1時間単位なので）

バッチ全体でなくスモールジョブだけで見ると、だいたい5倍くらい速くなりそうとのこと。 

---

それと、スモールジョブ実行エンジンをフローのテストの実行にも使用することにより、テストの実行時間も短縮できる。
（テストデータはたいてい小さいだろうから、効果覿面ｗ） 

フローのテストでスモールジョブ実行エンジンを使うには、build.gradleのdependenciesにasakusa-test-inprocess-extの設定を追加する。
（『スモールジョブ実行エンジンを利用したエミュレーションモードの有効化』を参照） 

dependencies {
～
    testRuntime group: 'com.asakusafw', name: 'asakusa-test-inprocess-ext', version: asakusafw.asakusafwVersion
～
}

（build.gradleを修正したら、念のため「./gradlew installAsakusafw」（ASAKUSA_HOMEの下に実行環境を構築するコマンド）を実行しておこう）

---

実行時のデータ量に応じてHadoopクラスターとそれ以外（スモールジョブ実行エンジン）をAsakusaFWが自動的に切り替えてくれるといいなーと思っていたので、今回の対応はとても嬉しい(笑)