[過去ﾛｸﾞ]
Rust part15 (1002ﾚｽ)
Rust part15 http://mevius.5ch.net/test/read.cgi/tech/1652347700/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
189: デフォルトの名無しさん [sage] 2022/05/20(金) 09:03:09.77 ID:SXN+DpBP >>182 mapのネストが苦手と言うならば mapを使わないバージョンも用意したのでどうぞ fn fibonacci_iter() -> impl Iterator<Item=usize> { let mut op: Option<usize> = Some(0); let mut oq: Option<usize> = Some(1); std::iter::from_fn(move || { let p = op.take()?; op = (|| { let q = oq.take()?; oq = q.checked_add(p); Some(q) })(); Some(p) }) } http://mevius.5ch.net/test/read.cgi/tech/1652347700/189
191: デフォルトの名無しさん [sage] 2022/05/20(金) 10:35:37.22 ID:t0eTe6yv >>189 さらに汚くしてどうすんのw http://mevius.5ch.net/test/read.cgi/tech/1652347700/191
197: デフォルトの名無しさん [sage] 2022/05/20(金) 11:26:17.74 ID:SXN+DpBP >>195 その通りだよ だから汚くなく、簡素でわかりやすく、無駄をせずに効率も良いコードを>>189に出した 同じ動作と同じ効率でもっと簡素に書けるのならばコードを出してごらん http://mevius.5ch.net/test/read.cgi/tech/1652347700/197
295: デフォルトの名無しさん [sage] 2022/05/23(月) 19:27:40.26 ID:qJLEBqNZ >>189 おまえら全員そうだがフィボナッチ数列でusize固定はおかしいだろ コード自体は問題ないが <T: Zero + One + CheckedAdd> を付けろ あとは0と1をT::zero()とT::one()へ置き換えればi8型からBigUintまで何でも動作するようになる https://play.rust-lang.org/?edition=2021&gist=929f3df48db39182558dfad6fe8d1cda さらに今回はfrom_fn()利用をそのままsuccessors()利用へ変換できるので見やすくなる fn fibonacci_iter<T: Zero + One + CheckedAdd>() -> impl Iterator<Item = T> { let mut oq = Some(T::one()); iter::successors(Some(T::zero()), move |p| { let q = oq.take()?; oq = q.checked_add(p); Some(q) }) } ちなみにCloneを要求しないためBigIntなどでも無駄なコスト増とならない >>202 そのコードは暗黙のコピーが発生している from_fn()使用版のコードはcurrがキャプチャ変数なので「let n = curr?;」でコピー発生 successors()使用版のコードはクロージャ引数「|&curr: &usize|」の「&」でコピー発生 usizeならば問題はないがBigIntなどでそのコードは動かないので劣る http://mevius.5ch.net/test/read.cgi/tech/1652347700/295
323: デフォルトの名無しさん [sage] 2022/05/24(火) 19:12:35.28 ID:VR6742Ui >>202のlet n = curr?;の部分を >>189はlet n = curr.take()?;としてコピーになるのを回避しているだけかと思ったら 両者が全く異なるアルゴリズムを採用していることに気付いた >>202のアルゴリズムだとどうやってもコピーを避けられないから詰んでるね http://mevius.5ch.net/test/read.cgi/tech/1652347700/323
325: デフォルトの名無しさん [sage] 2022/05/24(火) 22:24:27.19 ID:LZzc/1GO アルゴリズムというほど大げさな話ではないだろ f(n)を求めるnext()が呼ばれた時に >>189は内部にf(n)とf(n+1)を持っていて、足し算してf(n+2)を作る そして内部にf(n+1)とf(n+2)を残して、f(n)を返す >>202は内部にf(n-1)とf(n)を持っていて、足し算してf(n+1)を作る そして内部にf(n)とf(n+1)を残して、f(n-1)は捨てて、f(n)をコピーして返す つまりムダ >>324 同意 http://mevius.5ch.net/test/read.cgi/tech/1652347700/325
469: デフォルトの名無しさん [sage] 2022/06/05(日) 17:36:49.26 ID:kdHlti+w 可読性や汎用性を犠牲にしてもfindがpositionより優位に速いとか ユースケース次第ではデメリットを補うだけのメリットがあるなら多少汚くても受け入れられる フィボナッチの>>202と比較対象の>>181や>>189も同様 http://mevius.5ch.net/test/read.cgi/tech/1652347700/469
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.044s