(edit) saturating_mulでfoldしたほうがよほど綺麗なので無し!!!

ABC169 - B - Multiplication 2

itertools::iterateを使う例その2。 今回は「途中で打ち切れるfold」として用いる。 具体的には

(1, [a, b, c])
(a, [b, c])
(ab, [c])
(abc, [])

という遷移を(状態, impl FnMut(&状態) -> 状態)という形式にあてはめ、.take_while(..).nth(_)とすることで途中で10^18を超過したらNoneになるようにする。

ただし、(std::iter::successorsもそうだけど)lastの一つ先まで評価されるため、ダミーの値をVec<u128>にpushする。 どの道0への対処のためにソートする必要があるしそこまで無理矢理感は出ないはず。

東京海上日動 プログラミングコンテスト2020: A - Nickname

AsciiStr/AsciiStringはstrと[u8]の両方を持つのだけど、肝心のリテラルを記述するのが面倒。

let c = AsciiChar::A;
let c = AsciiChar::from_ascii('A').unwrap();
let s = AsciiStr::from_ascii("abc").unwrap();

なのでbyte (string) literalがある[u8]と比べると(競技プログラミングでは)微妙なのだが、

let c = b'a';
let s = b"abc";

この問題では AsciiCharを扱わずに

• [u8]のように[..3]で部分文字列を得ることができる (strだと.chars().take(3).collect::<String>())
• strのようにそのままprintln!できる ([u8]だとstd::str::from_utf8(_).unwrap())

という長所を生かすことができる。

東京海上日動 プログラミングコンテスト2020: C - Lamps

シンプルな1次元0次いもす法をItertoolsNum::cumsomで復号するだけ。

S と A をusizeで持ち、usize::saturating_subを使うことでnumeric castを一箇所に抑えた。

下手にstruct Imos1(Vec<i64>)のようなライブラリとして持つとas地獄に陥いるタイプの問題なのでこのような使い方の紹介をするのもいいんじゃないかなと思い追加した。 あとこのexamplesはRust入門者が読むだろうからC++やPythonには無いRust独自のイディオムを織り交ぜた方が良いのかなとも思ったので。

https://github.com/rust-lang-ja/atcoder-rust-base/pull/64/checks?check_run_id=769219266

マクロ(input!)が生み出す変数にclippy::many_single_char_namesが反応するようになったっぽいです。

AtCoderはしばらく1.42.0で固定だろうしrust-toolchainもあるからbeta(とstable)は外しても良いのではと思います。

ありがとうございます。なるほど、今までその clippy の warning はマクロで展開される変数には効いていなかったのですね。

今回のこの警告に関しては無視するのでよいと思います。この警告は Rust 的ではない点の指摘というよりは単に可読性についてのアドバイスと思われるので、問題文に合わせたほうがむしろ可読性が高まる競プロの文脈では構わないと個人的に思うからです。ただこの場合 input!() マクロを使わず普通に変数宣言をすれば現行の clippy でも同様の警告が出ますので、たとえ警告が出ないとしても強い意志表示として main() に #[allow(clippy::many_single_char_names)] をつけるというのも悪くはないかも知れません (べつにしなくても良いとは思います) 。

確かにこのプロジェクトのターゲットは stable, nightly ではなく 1.42.0 になるので、外してもいいかもしれませんね。例えば、将来に代替物ができて非推奨になった機能に対して warning が出るなどとなっても本質的に邪魔なだけですし...。