作ることができない」と結論される。フラグが立っているときは真の全数検索ではなく、厳密性にきずがある。未定義なら、これは簡易検索の結果である。等しいか、またはそれより小さい。作れる」という可能性が残る。得られなかった場合は、検索失敗。未定義と同じ扱いになる。スクリプトの実行時間が長過ぎて強制的に中断されるか、メモリー確保に失敗して(捕捉可能な)例外が発生するだろう。純粋に説明のためのもので、現実のコードでは、もっとましな出力をページ上に書き出せばいい。「2015を作るには27が13個必要」という検証は、バージョン1では5.8秒もかかったが、バージョン2を使うと、0.1秒未満になった。実行時間は環境によって異なるが、相対的に速度が約170倍になった。フラグが立ってしまうが、15個では作れないことは検証可能なので、解16は確定的)。「2117を作るには129が17個必要」という解については、フラグが立ってしまうものの、簡易検索0.5秒、全数検索2.4秒だった。それが実用的な時間で解けるようになった。チューニングやアルゴリズムの改善により、さらなる高速化も可能だろう。使うと、0.4秒/1.6秒に短縮された(付録参照)。不可能」とも思われる形のパズルだが、50~100行程度のシンプルなスクリプトによって、数秒で(多くは1秒以内に)全数検索が実行される。確かに計算量が壁になるが、地味な工夫をいくつか積み上げることで、結果的にブレークスルーが生じた。式を出力しないと、パズルが解けた気がしない。処理を少し変えて、データベースには、各キーごとに「どういう二項演算でその数を作れたのか」というレシピを登録すればいい。「2通り以上の分解ができる場合に、どの分解をデータベースに書くのか」という点(レシピの優劣判定)は、また別の問題となる。それらと合わせて、ブラウザ上から試せるデモを公開するべきだろう。フラグが立ってしまうケースにおいて、厳密性を保証するのは容易ではない。理想は、数学的考察により上界の評価を改善し、巨大な数を極力排除すること。次善の策は、64ビット整数をサポートしている言語を使い、扱える整数の上限を上げること。やるとなれば、53ビット以上の演算を自分で実装するか、その種のライブラリを使う必要がある。作れて...」と帰納的に考えることもできる。状況によっては、その方が速いこともあるはずだ。:以前にも似た問題を何度か紹介したことがあるが、そのときは「ラムダ関数」「文字列を作ってそれを動的に式として評価する方法」「関数を要素とする配列」といった技巧的な方法に走ってしまった。それはそれでワクワクするが、実はそんな面倒なことをしなくても、普通に+−×÷の計算をすればいい。技巧の探求も楽しいけれど、単純なやり方がかえって速ければ、実用上はそれが一番だろう。サポートされる環境では、次のようにすると速くなる。