未知の問題への取り組み方モデル
未知の問題への取り組み方モデル
ここでいう問題とは
競技プログラミングのAtCoder_Beginner_Contestで提示される問題などもそう。
全てにおいて有効というわけでは無いが、未知の問題に対抗するために有力な取り組み方とはなる。
振る舞いがすでに見えている場合にはこの段階をスキップできることもある。
1. 性質が見えない時・そもそも実験が困難な時は
a. 実験する規模を部分的・矮小にする
b. 問題で起こっている現象が何を述べているかについて、論理式として理解する
c. さらに簡単な形にすることを狙う
限界
性質の捉え方・フレームワークが備わっていない
大量に実験を行うことで捉え方を見出すこともできるが....
そのような知識がない状態では時間を大量に消費することは避けられない。
学んで、その時間を短縮することも大事
そもそも論理式として理解できていない
ここの方針立てにはさまざまな方法が使える
3. 解答の方針に最も適した形で問題を書き下す
その方針が正しいか証明することにも繋がる。
競技プログラミングだと特に正しいかどうかを考えずに実装に移れてしまう
その方針が正しいか？を確認しないと、後でバグに苦しむことに。
しかし、時間が迫っていると、わたわたとして何をしたらいいかわからなくなりがち
自分が試験系のものが苦手な理由
ここでやることを明確にする。
わたわたしている時は、そもそも問題がどうなっているかわかっていないことが多い。
例
全ての解答・入力パターン・戦略などを数学的に扱いやすい方式で表現する。
線図・グラフ・表など
そうすれば、とっかかりをもって議論しやすくなる。
そもそも「置き換えやすい形」が思い浮かばなければ...先人の知識を頼ろう。
4. その方針で正しそうかを実際にやってみる
プログラムで実装する部分であれば、競技プログラミングでバグった時のためのチェックリストを参考にしながら。
5. if その解法で困難が生じた
ここでいう困難
代数的にうまくいかなさそう
うまく行っても解法がとても汚くなりそう
今までの自分はここがうまくできていなかった。
5-1. なぜこの困難が生じたか言語化する。
2024-03-31の自分は、ここが難しいと感じている。
この部分を練習したい。
5-2. 1.に立ち戻り、この困難を回避するように性質を理解する。
6. うまく行けたら万々歳
演習問題に取り組んでいて、解答例がある場合には？
基本的には10分経っても1か2で止まっている場合は解答を見た方がいい
実験をしても、問題を解くのに有用な法則を抜き出しにくい問題もある。
そもそも実験しづらいことも。
自分の知識量、バイアスなどもあり、正しいモデルを探し出すのには多大な時間がかかる。
c.f. ABC335 D -- Pylamid
自力で思いつくことも大事
二次関数的なんじゃ無いかと思っている
--> 例をたくさん学んで考え方のフレームワークを抽出して、より多くのものに応用できるようにすることが大事になる。
4. で止まっている場合は、開始してから15分経つまでそのまま続けてみる
バグ取りとか
ただし、埒が開かないと思ったら困難だとみなして回答を見てみる。
4.で15分以上経ってたら諦めて回答を見るのがいい。
4.で、自分の思いもよらない楽な方法がある可能性がある
そもそも「困難」だと認識できていない可能性もある
ここの記述に影響を受けている
> 基本へさかのぼって考える．(i.e. 「定義」に立脚して解く．)
> 現象そのものをあるがままに見つめる．（i.e. 実験する）
> 計算を合理的に行う．
前のモデルからの改善
しかし、それでも問題が解けない...それはなぜか？
高校の友達「困難を捉えようとしていないのが原因では」
典型問題ならともかく、世の中で実際に出会う問題は一発目で編み出した手法がうまくいかないことも多々ある。
一発目から良い方法を編み出すことはとても難しい
困難を「無理やり」乗り越えるものではなく、うまく避けるものとして捉え直した姿勢を強めたモデルへと考え直した。
実践例
単純な具体例をまず試して方針を得て、
そこから行き着いた変数変換から本質を理解しようとしたけどうまくいかなさそうだった
これを「困難」と捉え諦めて
もう一度単純な具体例をもとに話を進めてみた結果
単純な具体例をもとに一般の例においても議論できることに気づいた
問題が完全に解決した