MatsuTaku

どなたでもご意見いただけると幸いです． このデザインを提案した気持ちとしては， 私の認識だとRecommendationは結構人気コンテンツで，ここに表示される問題をどんどん解いていく精進をされている方が多いように思います． Recommendationが人気たる所以は，「なんかいい感じの問題が提案されてる」ことだと思います． この仕組みには「正答率50%となるレートの値」とか「正答するまでの推定時間」といった情報は必ずしも必要ではなく（むしろ先入観を抱いてしまうことを煩わしいと感じる人もいるかもしれません(n=1)），もっとシンプルなデザインで十分なのではないかと考えました． さらに提案を加えると，デフォルトのデザイン設定をどちらにするかという部分も一考してもよいかなと思います．

- 複数の`Problem.id`からMyListを操作するAPIが現状ないので，作成する必要がある？ - `ProblemId[]` -> *VirtualContest*という導線を作ることだけを考えるならば， GET requestにProblemId[]を付加し，*ContestCreatePage*の`initialProblems`をリクエストから展開したProblemId[]でセットできるようにすれば良い．

> - ProblemId[] -> VirtualContestという導線を作ることだけを考えるならば， GET requestにProblemId[]を付加し，ContestCreatePageのinitialProblemsをリクエストから展開したProblemId[]でセットできるようにすれば良い． は，別Issueに切り出します． #865

上記の提案を形にしたものをDraftに挙げました #787 既存の`Recommendation`タブの隣に以下のページを仮置きしました   - 問題の情報量はあえて減らしています `？`ボタンをクリックすると詳細を確認できます - 問題の並びはランダムです 現在は簡単な実装のため、ページをリフレッシュするたびにシャッフルされます 使い勝手が悪ければ、フィルタ設定ごとの問題リストのキャッシュ等を検討します - 問題の推定正解率に基づいて問題を分類します 各難易度の分け方は以下の画像と対応します 推定正解率の下限は0.03としました（適当です） (y: Predicted solve probability, x: Meaning of problem difficulty)  https://www.desmos.com/calculator/iuc0sjckze

# 推薦する問題の選び方について このページを利用するユーザに以下のニーズを仮定しました ``` ユーザーは、実力の向上を目的としてこのページを利用する ``` ここで、AtCoderのレート表記は、99.9%の確率でそのレート以上の実力があることを保証する数字になるように設定されています( [AtCoderのレート計算式 - レートとパフォーマンス](https://qiita.com/anqooqie/items/92005e337a0d2569bdbd#%E3%83%AC%E3%83%BC%E3%83%88%E3%81%A8%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9) , https://twitter.com/chokudai/status/829601624502919168 ) したがって、ユーザの実力向上に寄与する問題の難易度は、実際のレートに対する評価よりも難しい側（上の画像で言う中心より右側）にある可能性が高いです このような思考の元、推薦する問題の範囲をユーザのレートに対する推定正解率が低い範囲に対してリッチな情報量になるように設定しました この設計に関しては主観が強く反映されていますので、ご意見いただけると幸いです

> 情報量が多いので、問題の選び方と問題の見せ方の2つに分けたほうが良いと思います。 その通りですね。まず選び方から話を進めようと思います。 > > AtCoderのレート表記は、99.9%の確率でそのレート以上の実力があることを保証する数字 > > というのは、コンテストによるパフォーマンス測定にはばらつきがあるという前提のもとで、たくさんコンテストに出てないうちはレーティングの推定量には大きなばらつきがあるのでそのばらつきのぶんだけ割り引こうという話で、実はこれはいわゆるリセマラ排除補正のことです。これを取り除くには単に内部レーティングを使用すればよく、Recommendationではすでにそのようにしているので、この点だけを持ってより難しい問題に寄せたほうがいいという結論にはなりません。 ご指摘ありがとうございます。仮説の不備に納得しました。 ## 個人的な推定正解率に対する印象 - 90%以上: 確実に解ける - 80%付近: レート維持のために確実に解けるようになりたい - 50%付近: ここは解釈が広いが、丁寧に考えれば解ける - 20%付近: コンテスト中に解けることもある。私の精進のホットスポットはここ - 10ー3%: 稀に手足が届く - 以下: ほぼ不可能...

選び方には、ユーザに必要十分な選択肢を与えることが重要かなと思いますので、どの範囲と分類数が必要十分かで議論したいです。 名前の付け方も肝になってくると思います。 以下のような分け方ではどうでしょうか。 1. 右寄り4区間 https://github.com/kenkoooo/AtCoderProblems/compare/master...MatsuTaku:classify-idea1  2. 右寄り3区間 https://github.com/kenkoooo/AtCoderProblems/compare/master...MatsuTaku:classify-idea2  3. 中央3区間 https://github.com/kenkoooo/AtCoderProblems/compare/master...MatsuTaku:classify-idea3 

プログラミングを学びたての人から見ると，54-147-400 は難易度的に違いを感じるのではないかと思います（主観です） 例えば，以下のような問題で差が出る気がします． ## 54-146 ループの実装，数学的工夫, etc. - [B. Gentle Pairs](https://atcoder.jp/contests/abc187/tasks/abc187_b) (68): 2重for，割り算を使わないグラフ傾き計算 - [C. Step](https://atcoder.jp/contests/abc176/tasks/abc176_c) (72): forの実装，貪欲な更新 - [B. Smartphone Addiction](https://atcoder.jp/contests/abc185/tasks/abc185_b) (93): 比較的ややこしい実装(ループの実装，判定) ## 147-399 列挙の応用，データ構造，計算量の知識, etc. - [C....

このIssueの問題の本質は、 AtcoderProblemsのトップページで、空ユーザのTableコンテンツを表示している仕様にあると思います。 適当な改善方法としては、 1. ログイン時のトップページをTableカラム選択状態にする（つまり、`/table/`へリダイレクト） 2. 適当なトップページを表示する 現時点のサイトのフローや挙動（Tableタブを押すことでログイン情報が反映される）は分かりにくいと思うので、何かしらの改善は欲しいなと思いますが 1. はとりあえずの対応はできますが、現状の仕様に最適化した対応なので、本質的な改善にはならないと思います。 2. は要はサイトフローの見直しになるので、トップページの内容の議論含めコストが高いです。

- `Difficulty Pies`と`Point Pies(仮)`は、 `List/(Difficulty, Point) Status` と内容が同じなので、どちらかに整理した方がよいかもしれません。 - 単純にPointごとにPiesをつくると、Pieが多すぎる(100:2400:100)という問題があります。