ここ数日。123456789を分けるプログラムを組んでいた。
頭の体操で
abcde-fghi=33333
となる数字は？という問題があり、紙とペンを使えば1分もかからず解けはするのだが、これをコンピュータに計算させるならどう組むのがいいのか。ということばかり考えていた。


よくわからなかったので、9桁の数字をばらして入れて、それを各々判定するという方法。
最初は30分くらいかかっていたが、判定方法や数字を9の倍数にするといった工夫で最終的に6分半を切るまで早くなった。
が、他の方法もありそうな感じがしたので、別アプローチを何とか組み上げてみたら3秒で終わった。ビビった。
計算式量自体そう変わらんのではと思っていただけに、予想外の早さに驚く。
数字をばらして入れる部分が結構な負荷だったのだろうか。
判定式のループ部分自体の構造はむしろ前の方がシンプルだと思ったのだが。
中身的にはゼロ判定も普通に入れているし。

配列変数の無効やcntの位置などでかなり頭を使う。cntは使いやすいがrepeatを挟みにくいからな。1zだとだめでz1だと変数として大丈夫だったり、久々なのもあるが結構大変だった。
組み合わせ番号をそろえる工夫が上手くいったが、その分だけ式量は結構増えているはずなんだけどな。
3秒プログラムでも無駄な計算はしているはずで、前のは6分以上無駄な計算をしていたことになるのだが、なんかやっぱり腑に落ちないな。
でも8000万の数字を判定して362880の組み合わせを抽出するのが380秒くらいだったので、ピンポイントで判定できたとしても、0.45%だから2秒弱か。だとしたらアルゴリズムがよっぽど良かったのか。6分での数々の工夫は無駄もいいところだったわけだが、それなりに楽しめた。
結局は枝葉をどれだけ省略できるかなのか。そこが一番の工夫のしどころでもあるし。
6分はなんだかんだ言って総当たりだからな。そうかぁ。
でも本職の人が組むと数行、1秒で済んだりするんだろうか。