計算・空間効率を追求する必要がありそう→言語自体の実行性能が高いこと。ある程度、内部の挙動を把握できる、かつ効率化のポイントを把握していること。上限値をもとに、前ステージで得られた答えを取捨選択する」ステージに分けました。アルゴリズム」と「双方向探索」を組み合わせた実装となりました。ページ内容をかなり参考にさせてもらっています。秒以下で計算可能)特徴があります。スローしてしまう可能性があります。今回のソルバーでは、展開される状態数に上限値を設けて、その上限値に達したところで解の計算を諦める制御ロジックを組み込んでいます。アルゴリズムのヒューリスティック関数には、「マンハッタン距離」を用いています。壁の存在があるため、実際には単純なマンハッタン距離ではなく、壁を回避してたどり着く最短経路での手数を距離としています。壁が一つもなければ、常にマンハッタン距離と等しくなります。算出された各問題の答えの集合から実際に提出する回答を選ぶ処理は、貪欲なロジックで実装しています。それぞれの利用が多い答えを捨てる仕組みとなっています。時間で獲得することができました。高いスコアを目指すために、これより先はひたすらアルゴリズム以外の最適化に手を尽くしました。バイト消費するようにしていました。ビットで表すことができます。つのパネルを表現するように実装を改めました。バイトで表現できるようになりました。ビット数値で効率よく表現するようにしました。パネルまとめて計算するようにしています。一度計算したハッシュ値はキャッシュすることで、ハッシュ値の計算コストを低く抑えるようにしています。とってそれなりにコストのかかる処理なので、いったん生成してすぐに不要になってしまったオブジェクトを再利用する(フィールドだけごそっと入れ替える)仕組みを組み入れました。したりと、あまり気持ちのいいものではないですが。簡略化したものを開番地法で実装しました。これにより計算効率と若干の空間効率の向上が達成できます。修飾子をつけてみたりしました。効果のほどは定かではないですが。物理メモリ+ページファイルのサイズ分、ヒープを確保することができるようになりました。ビット版に比べて心なしかよくなったように思います。してみたりと、試行錯誤してみました。ヒューリスティック関数は、通常のマンハッタン距離のものよりも早く答えを見つけ出せる(代わりに手数は多くなる...)など面白い結果が確認できたのですが、処理時間が遅くなるなどの理由で結局採用しませんでした。差し替えようと検討してみました。答えを出力するための履歴をどのように保持するべきかが把握できなかったのと時間的制約により、あえなく断念しました。バイトになっているようで、オブジェクトを大量に生成した場合にかなりの勢いでヒープを大量消費してしまう様子がうかがえました。いつかのバージョンからか、オブジェクトポインタを圧縮できる仕組みが備わったようで、それを有効化(-XX:+UseCompressedOops)してみましたが、結果は変わらず。仕方がないので、ページファイルを利用してヒープ領域の拡大する方向に突き進みました。一切有効活用せず、シングルコアでひたすら頑張る構成にしてしまったのがちょっと残念でした。時間ちょっとで解けるまでになりました。問全問解くのも難しくはなさそうです。メモリさえあれば...。この結果には満足しています。アリゴリズムとか、大学の講義で聞いただけで業務で使うことなんて今まで一度もありませんでしたが、実際に触れてみるとなかなか楽しいものです。