NyaanNyaan
NyaanNyaan
- クエリ5がない方が自然というのに同意します。ただ、個人的には実用の観点からrange sumまでverifyしたいというのと、動的木のrange sumのためだけに別の問題を追加するよりは一緒にしてしまいたいという気持ちもあり入れてしまいました。(yosupoさんの方針に反するなら入れないつもりですが、出来れば入れたいです) - Ordered Dictionary、了解です
https://stackoverflow.com/questions/49845474/why-does-gcc-diagnose-a-unused-variable-for-structured-bindings-while-clang-does This seems to be bug in gcc and has been fixed in the latest version.
実装したが string の長さがバッファの長さを超えるときにバグってる気がするな 気が向いたら直す
ご指摘ありがとうございます。Library Checker の方にもうすぐ問題が追加されそうなので、その際に verify しつつ修正しようと思います > グラフを表す型の制約 難しい問題ですね… たぶん自分のライブラリは全体的に `vector` をグラフ型として使用するときの動作を保証していないのと、`UnweightedGraph` は `vector` のエイリアスなので、 > `UnweightedGraph、StaticGraph` のように書いても良いのではないかと思います。
ほんとですね (勘違いしていた…) 情報ありがとうございます。
普通に $(変数名)$ で問題ないです、他の変数と文字がかぶって読みづらそうだったら $\mathrm{変数名}$ とかでお願いします
辺上の端点以外の点は外す方が一般的だと思っています。(が、たまに含める方を要求する問題があり、そちらも欲しいため少し悩ましい…) 同じ位置に複数はあった方がよさそう。 index は(辺上の点と違って)必要になったら map で復元可能だと思うのでどちらでもよさそうに感じました。
あまり詳しくはないんですが検索した感じ "Bivariate Formal Power Series" という表現の方がよく使われているようです。 多変数 FPS を持っていれば確かに 2 変数に限定する必要は無いですが、 - 多変数 FPS を 2 変数以外で使った記憶がほとんど無い - 2 変数に特化した高速化がありそう などの理由から 2 変数で準備してよさそうに思いました。
「(無視した場合の解, エラーの有無) を両方出力する」に 1 票入れたいです。 フローを使用した実装であればエラーの有無は容易にわかるので、両方の出力を要求されても困らないと思っています。(他の実装ではどうなんだろう…) 最終結果は sum に 1 票です。