できないときは、何ができないのかを人形とか壁に向けて説明してみろってばっちゃが言ってた。

あと、デバッグルール - 永字八法も見直すこと。
さて。
「NScripterでメルセンヌ・ツイスターをネイティブで実装する」と言う命題に取りかかっている訳だが、これは言いかえると、「NScripterでビット演算をネイティブで実装する」となる。
と言うのも、メルセンヌ・ツイスターのプログラムの基本的な仕組みは、625個だかそこらの相互に関連する数値（一つが変わったら残り全部がぐにゃりと変わる。ツイスト！　ツイスト！）を用意し、それらの中から順番に一つを選んでコピーし、そのコピーをさらにぐにゃぐにゃとひねり（ツイストして）それを乱数として返すと言うものだ。
その「ぐにゃぐにゃした処理」は、大量のビット演算とちょっとの四則演算で成り立っているので、実現するにはまずビット演算ができなければならない。そういう訳だ。
このビット演算と言うのは、控え目に言ってプログラマや数学者（特にブール代数専門）以外の人間の頭脳には理解しがたい演算方法であり、恐らくそれができるだけでできない人間からは変態呼ばわりされることは間違いない。（そして俺は、たどたどしくもできてしまうのだ。残念ながら）
ただ、そんなものが何故存在するかと言えば、今のコンピュータは、根本のところでこのビット演算でもって情報を扱っているからだ。二進数しか扱えないはずのコンピュータが、画面に十進数の数字を表示しているのは、中でものすごい量の二進数による計算を行った結果である。コンピュータは人間には扱いづらい？　馬鹿な。ENIACが発明された時のことを考えたら、今現在どれだけコンピュータの方から人間に近づいてきたか、その遙かな道程は三蔵玄奘もかくやと言う険しさだ。
そうとも、PerlやJavaやRubyと言った言語では、この桁数が制限された上にマイナスも小数点以下もそのままでは表現できないnビット型変数を、プログラムで何重にもくるんで、人間的な「数値」として扱えるようにパッケージングしているのだ。ここまでやってもらっておいてまだわからないとかぬかすかこの怠け者め！（誰？）
メルセンヌ・ツイスターの話に戻ると、このアルゴリズムは、だいたいにおいて「32bitの符号なし整数」をメインに使うことを想定している。0から40億とちょいまでの整数が扱えれば問題ないわけで、しかもこれは現在の32bitCPUではもっともネイティブな、恐らくはもっとも速く計算できる形式で、しかも低級言語（C言語とか）の方が向いている。
さて、NScripter（やPerl）では、これをくるんでしまって「32bit符号あり整数」としてしか扱えなくなってしまった。マイナス20億ちょいからプラス20億ちょいまでの範囲である。速さを犠牲にして人間的な直感によりそった結果である。
しかしこうすることで、根本は32bitの整数であると言うのに、それを意識した数値操作ができなくなってしまったのだ。
と、言う訳でパッケージングして手が出なくなったビット型とそれらのビット演算を、パッケージングした数値形式でもってエミュレーションしなければならないと言うことだ。
なんと言うか、よく切れるナイフを手に入れてそれでもってペーパーナイフを削って、ペーパーナイフがよく切れないとぼやくような、あるいはリトル・ビッグ・プラネットでグラディウスを実装してみたり、あるいは名CPU・Z80Aをウィンドウズ上にプログラムで構築して昔のゲームを吸いだしてちっちゃなドットでプレイしてみたりとか、そんなもどかしさである。
結局うまくいっていないのは、アルゴリズムの記述部分ではなく（それはほんと10分でできるんだが）、その記述部分を支えるビット演算の部分がうまくいかないからだ。それも感覚的に言うと、ビット形式のデータ同士の「掛け算」部分にバグが潜んでいるような気がする。
ま、それをおいかけるのはまた明日にするとして、どうでもいいが、unsignedって「アンサインド」なの？　それとももしかして「アンシグネド」とか読んじゃう？　気になって夜もぐっすりだ。