ABC323 （2023/10/07）
〇A問題
Yuto.icon やるだけ１
TK.iconi%2 == 1のときだけ条件確認。サンプル試したらなぜが出力されない。breakのインデントがずれてた。気付くまでに時間がかかった; ;
おたふく.icon rangeの刻み値をいじる。
yuichang.icon超慎重にやる
Kaplam.icon変な設定に混乱してちょっと時間かかった
CarpDay.iconKaplam.iconさんと同じくちょっと混乱．（前回ともにA問題WAした）yuichang.iconさんと同じく慎重に解く
tako.icon おたふく.iconさんと同じです
kakip.iconスライスしてintに変えて判定
〇B問題
Yuto.icon やるだけ２
TK.icondictを使って勝ち数を管理して、同じ勝ち数の人たちはソートして出力
おたふく.icon 各チームの(勝った回数, ~チーム番号)をlistで管理して、ソートするだけ。
yuichang.icon勝ち数をメモしてソート
Kaplam.icon99勝から0勝と1人目からn人目まで*2で三重ループ
CarpDay.iconおたふく.iconさんみたいに(勝利数, チーム番号)をlistで管理して、逆順にソートするだけ，と思ったら，入力例2のように同点のときの順序が逆になる．Nの最大値100だったので，-100×勝利数＋チーム番号をキーにソートするように変更して対処．B問題なのに手ごわい（と感じた）
tako.icon多分yuichang.iconさんと同じです
kakip.icon(チーム番号, 勝利数)をlistで管理して、sort(key=lambda x: x[1], reverse=True)でなぜかできた。軽く検証してみたら、keyが同じ場合、ほかの要素に関係なく元の順番になるっぽいので、リストがチーム番号について昇順である必要がある。sort(key=lambda x: (x[<勝利数>], -x[<チーム番号>]), reverse=True)のほうが多分いい
CarpDay.icon(チーム番号, 勝利数)にしておけば良かったか！！なるほど！！
kakip.icon(勝利数, チーム番号)でも勝利数をkeyに指定すればできるはずです。sort()はおそらくkeyで比較して、等価なら（key以外の要素やreversedの値に関わらず）元の順番になるようです
〇C問題
Yuto.icon やるだけ３．制約が小さいので愚直に．解き方を決めてからの指の動きが鈍くて，衰えを感じる...
TK.icon現在の得点を計算。得点の最大値を取っておく。現在解いてない問題の得点をソートして持っておく。後は最大の得点を持っていない人たちは、まだ解いていない問題の最大のものから順に得点を与えていく。
yuichang.icon愚直。一生2ペナ出てて通らなくて発狂。(1問も解いてなくてもボーナス点入るんだ、、）
おたふく.icon 各チーム毎に解いていない問題のみで得点順に降順ソートして累積和を求めて、各チーム毎ににぶたん。色々考え漏れがあり、2WAの後にAC。
Kaplam.iconzipsortして得点の大きい問題から見ていく
Yuto.icon zipsortってなんですか？初めて聞きました。調べても出てこなかったんですが、どんなsortなんでしょう？
Kaplam.iconsortしたいlistと1ずつ大きくなっていくlistをzipでまとめてsortしてsort前の場所保持すること言ったつもりでしたが確かに検索しても殆ど出てこないですね...手元の自作メモが"zipソート"ってフォルダ名だったのでてっきり普遍的に使われてる名前と勘違いしてました
CarpDay.iconB問題でおたふく.iconさんや私が行ったような，元のデータとindexをタプルにしてソートする，という手法かな？その手法自体は特別な名前は付いていないだろうね．
Kaplam.iconそれです、今回初めて使ってみたんですが特に名前ないんですね
CarpDay.icon得点の大きい順に得点表も作り直して，最初に最高点を超えるまでの問題数をカウント．でもWA．原因が分からずシンプルな方法に一から作り直している途中で原因分かった．最初から1位の人の扱いが甘かったです．
tako.icon得点の高い順に解いたらイイと思って作ったら解いた問題のことを忘れててWA。それに気づくまでに時間がかかりすぎ
kakip.icon解いた問題の得点だけ抜き出してソート
〇D問題
Yuto.icon 優先度付きキューと辞書で愚直にシミュレーションしたら 11/33TLE．
yuichang.iconpythonでいうsortedsetと辞書で愚直したら2200msで通った。C++最強。
Yuto.icon _(:3 」∠)_
tako.iconJavaでもTLEだった
TK.icon最後のサンプルから、それぞれのサイズのスライムの個数を別の形式に変換すれば、そのサイズのスライムの合成後の数が求められることには気付いたが、その変換後の数字からもともと持っているサイズと干渉してしまう場合にどう対処すればいいかがわからなかった。
おたふく.icon とりあえず愚直に実装して提出するもWAとTLEの嵐。
Kaplam.iconzipsortして小さいスライムからくっつけて二分探索でlistの挿入場所探して追加してって感じで2719ms、危ない
CarpDay.icon2339ms．PyPyもまずまず．基本的にはheapqを使うが，同じサイズのスライムの個数を統合したい点がネック．そこで敢えて統合させず，heapqから異なるサイズが出るまで取り出し続けるようにして対処して無事AC．
kakip.icon小さい順に見る。サイズがすべて異なることが保証されているので、1つ先だけをチェックして統合する。コンテスト中はTLEだったが、SiとCiの組をlistからtupleに変えるとAC
CarpDay.iconへぇ～
〇E問題
Yuto.icon dpのテーブルどうしようかなーと考えたらコンテスト終わった
おたふく.icon 確率dpっぽいなあ...。コンテスト後に考えて無事AC。落ち着いて考えるとそこまで難しくなかっただけに本番に解けなかったのが悔しい。
TK.icon↑同じ感想を抱いてＦを見に行った
Kaplam.icon分数の逆元その内履修しないとかと思いつつやってなかったのでF行った
CarpDay.icon勉強会で講習しますので，ぜひご参加を！簡単だよ！
Kaplam.iconプロジェクト演習の後に体力が残ってたら行きます...
CarpDay.icon想像通りに実装．初めは敢えてMOD使わずに実際の確率のまま実装．実行例1の解答 7/27をスマホで計算したら，出力結果と合わずにプログラム作成し直し．．．の途中で，スマホの計算結果の方がおかしく，プログラムが正しいことに気付き，元のプログラムに戻す．MODを使う形にして無事AC．スマホスキル不足のために時間ロス．．
〇F問題
Yuto.icon 無理だろうなと思いつつ，場合分けして解いてみた．サンプルが通ったので提出してみる．17WA．．．はい．
TK.icon座標の配置のパターンわけを考えたりしたが、途方もない条件分岐が必要そうだと思い、Ｄへ帰る。
Kaplam.icon最初簡単に見えたので頑張って書いたらサンプル1個も通らず、原因ある程度わかったけど条件分岐大量に加えないとっぽくて諦め、AC9だからちょっとだけ合ってた
CarpDay.iconできるだけ場合分けが少なくなるように，荷物の位置を原点，荷物のゴールを第1象限になるようにして，高橋君の位置で場合分け．入力例2で既にWAだったが，終了間近だったので記念投稿．3点が一直線に並ぶ場合について考慮できず．無念．コンテスト後に挑戦．上の座標変換に加え，偏角45度以下になる変換も行う．荷物・高橋・ゴールがこの順にx軸上で並ぶ場合のみ注意して場合分けしてAC．
おたふく.icon 場合分けの鬼。凄い疲れた...。