Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part12
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

**デフォルトの名無しさん** · 2021/12/14(火) 15:30:19.02

>>302
そうだったんですね・・・
時間は掛かるかもしれませんが、色んなものを試して自分に合う物を探すことにします

**デフォルトの名無しさん** · 2021/12/15(水) 07:48:40.06

技術を高める目的なら windows-rs や wgpu-rs みたいな一段下から積み上げるのも楽しいよ。

ゲーム作る道のりは遠くなるけど、画面に三角形出したり、キーの入力受け付けたりするだけで達成感が出てくる。

**デフォルトの名無しさん** · 2021/12/17(金) 12:43:03.76

https://forest-watch-impress-co-jp.cdn.ampproject.org/c/s/forest.watch.impress.co.jp/docs/serial/yajiuma/1374/986/amp.index.html
エディタ自体はvscodeに勝つの難しそうだがGPUIとやらが定番GUIフレームワークにならないか期待

**デフォルトの名無しさん** · 2021/12/17(金) 16:39:33.05

既出だったらすいません
前から疑問だったのですが、出力におけるprint!マクロのような入力用マクロが標準ライブラリに用意されていない理由ってなんですか？

**デフォルトの名無しさん** · 2021/12/17(金) 18:11:01.90

>>297
1対多で、broadcast するチャットルームのバックエンドなら、
Ruby on Rails 6 のAction Cable(WebSocket)が基本

JavaScript は、React, Phaser とか

【Rails】（送信時のリロード無し！）Action CableでSlack風チャットアプリを作成、2019/12
https://www.youtube.com/watch?v=o6PuxDr8Meg

**デフォルトの名無しさん** · 2021/12/17(金) 18:36:09.20

>>306
この辺読んで
https://github.com/rust-lang/rust/pull/75435
https://github.com/rust-lang/rfcs/pull/3196

**デフォルトの名無しさん** · 2021/12/17(金) 23:52:56.58

>>308
熟読させていただきました。
私としてはたった数十行のコードであること且つ他のほとんどの言語に存在しているものなのであっても良いのかなと思ったのですが、Rustの基本理念を考えると慎重になる理由も理解出来ました。
Rustの経験が浅い私目線ではあまり腑に落ちませんでしたが、皆さんはどう考えていますか？

**デフォルトの名無しさん** · 2021/12/18(土) 15:05:52.37

熟読はしてないけど、外部ライブラリで簡単に実現可能であるなら
直感的には、本体メンテナの苦労を増やすほど価値があると思えないし別にいらんかな

こういうIOとかCLIプロンプトらへんの機能ってどうしても好みが分かれるというか、
ユースケースによって必要な機能がかなり違ってきちゃうと思うし

**デフォルトの名無しさん** · 2021/12/18(土) 20:46:47.80

C++のiostreamが失敗作だから慎重になるのもわかる笑

**デフォルトの名無しさん** · 2021/12/18(土) 23:17:58.09

>>306
C言語でのprintf相当はあるのにscanf相当がstdにないのはなぜか？ですね
逆になぜprintf相当がRustの標準ライブラリにあるのか？を考えてみると

(1) 読み書きの非対称性
人間が読むためにプログラムが書くことはエラー表示を含めて利用必須かつ頻出
一方で人間が書いたものをプログラムが読むことはレア
ファイルや通信相手への読み書きは各プロトコル/各API/シリアライズ等で対象外

(2) コンパイラサポート
print!やformat!等は頻出するので効率面からコンパイラサポートが効率的
実際にそれらが利用しているformat_args!はコンパイラ内蔵マクロ

(3) 標準ライブラリ採用
外部ライブラリで実現可能なものは採用しないが基本
今回はコンパイラ内蔵マクロだから採用

つまり出力は頻度と効率化で採用がクリアされたけど
入力は外部ライブラリで十分かなと

**デフォルトの名無しさん** · 2021/12/19(日) 02:25:28.05

しかし競プロでみんなproconioとかいう謎の専用ライブラリ使ってるの見た目悪すぎて笑える

**デフォルトの名無しさん** · 2021/12/19(日) 04:21:35.56

競プロ全然知らないけどstdinに入力数値がくるからか

| 入力は以下の形式で標準入力から数値が与えられる。
| a b c d e
| 積が奇数なら Odd と、偶数なら Even と出力せよ。

標準ライブラリだけ使うと毎回こんなの書くのは面倒だもんな

| use std::io::{stdin, BufRead, BufReader};
| println!("{}", if BufReader::new(stdin()).lines().next().unwrap().unwrap().split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0) { "Even" } else { "Odd" });

>>313
そのproconioを使うとこうなるようだ

| proconio::input! { v: [isize; 5] }
| println!("{}", if v.into_iter().any(|n| n & 1 == 0) { "Even" } else { "Odd" });

**デフォルトの名無しさん** · 2021/12/19(日) 06:54:36.03

>>314
ワンライナー大好きかよ

**デフォルトの名無しさん** · 2021/12/19(日) 07:00:31.55

>>315
マルチラインだと標準ライブラリだけでもわかりやすくなる？

**デフォルトの名無しさん** · 2021/12/19(日) 08:28:47.39

>>316
あいやごめん。proconioのところはどうあがいてもプロコン専用のproconioが一番見やすいよ。それ用に特化されたライブラリだし
俺が大好きかよって言ったのは
println!("{}", if v.into_iter().any(|n| n & 1 == 0) { "Even" } else { "Odd" });
の部分

**デフォルトの名無しさん** · 2021/12/19(日) 09:08:15.26

どの言語でも三項演算子(相当)はワンライナーで書くんじゃね？

**デフォルトの名無しさん** · 2021/12/19(日) 09:36:51.21

見た目汚いなw

**デフォルトの名無しさん** · 2021/12/19(日) 09:42:08.31

これでいいかね？
println!("{}", if v.into_iter().any(|n| n & 1 == 0) {
　"Even"
} else {
　"Odd"
});

**デフォルトの名無しさん** · 2021/12/19(日) 09:57:56.98

俺ならこんな感じかなあ
俺は頭悪いから、途中結果に一つ一つ名前つけないとわかんなくなっちゃうわ
まあワンライナー見た時に「グエー」って思っただけだからごめん。「大好きかよ」とかいっておいてなんだけどあんま気にしないで

use proconio::input;

fn main() {
input!(v: [usize; 5]);
let is_even = v.iter().any(|x| x % 2 == 0);
let result = if is_even {
"Even"
} else {
"Odd"
};
println!("{}", result);
}

**デフォルトの名無しさん** · 2021/12/19(日) 10:13:36.41

>>321
なるほど
じゃあ最初の標準ライブラリのみはどのように分けるのかな
println!("{}", if BufReader::new(stdin()).lines().next().unwrap().unwrap().split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0) { "Even" } else { "Odd" });

**デフォルトの名無しさん** · 2021/12/19(日) 10:17:01.07

>>322
proconio使うｗ
Rustで競プロするにはIOごときに専用ライブラリ使うことになってなんかなあって思うけど、そう思いながら使う

**デフォルトの名無しさん** · 2021/12/19(日) 12:54:53.29

>>315
ワンライナーやクロージャでまとめて書くと所有権やライフタイムの問題が出にくいんだよ
他の言語と違ってRustで適切に分割して読みやすく書くのは初心者には難しい

**デフォルトの名無しさん** · 2021/12/19(日) 13:44:27.43

わけわからんくてビビってたらよく見るとPythonスレじゃなかった

**デフォルトの名無しさん** · 2021/12/19(日) 15:04:40.83

rustfmt使うでしょ普通

**デフォルトの名無しさん** · 2021/12/19(日) 21:36:12.89

>>326
println全体が改行されてしまった

println!(
　"{}",
　if BufReader::new(stdin())
　　.lines()
　　.next()
　　.unwrap()
　　.unwrap()
　　.split(' ')
　　.any(|s| s.parse::<isize>().unwrap() & 1 == 0)
　{
　　"Even"
　} else {
　　"Odd"
　}
);

一方で分割するとこうなった

let cond = BufReader::new(stdin())
　.lines()
　.next()
　.unwrap()
　.unwrap()
　.split(' ')
　.any(|s| s.parse::<isize>().unwrap() & 1 == 0);
println!("{}", if cond { "Even" } else { "Odd" });

if式自体はワンライナーーで正解とrustfmtはおっしゃってる

**デフォルトの名無しさん** · 2021/12/19(日) 21:50:26.03

ワンライナー云々はフォーマットの話ではないやろ

**デフォルトの名無しさん** · 2021/12/19(日) 22:05:50.34

例えば>>321がif式を5行に分割しているが
それもrustfmtにより1行に修正された

Rust標準ライブラリのソースでもワンライナー
bool.rs: if self { Some(t) } else { None }
result.rs: let n = if self.inner.is_some() { 1 } else { 0 };
time.rs: let prefix = if f.sign_plus() { "+" } else { "" };

>>328
では何の話かね？

**デフォルトの名無しさん** · 2021/12/19(日) 22:37:44.04

構造と書式を区別できんのはヤバイで

**デフォルトの名無しさん** · 2021/12/19(日) 23:10:30.41

心底どうでもいい。
保守性に貢献するどころかマイナスになるようなクソプライドコードの導入すんなよ。

**デフォルトの名無しさん** · 2021/12/19(日) 23:14:48.39

また性懲りもなくコードべたべた書いてんのか

**デフォルトの名無しさん** · 2021/12/19(日) 23:21:45.51

rustfmtだから書式の話やで

**デフォルトの名無しさん** · 2021/12/19(日) 23:25:17.24

区別できなかったからrustfmtを持ち出したんやろ
どこに改行入れるべきかって話だと思ったんだろなww

**デフォルトの名無しさん** · 2021/12/19(日) 23:41:46.15

rustfmtを持ち出したのは俺じゃないぜ
あと今回のケースならここは分割するよな
let reader = BufReader::new(stdin());
let line = reader.lines().next().unwrap().unwrap();
let is_even = line.split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0);

**デフォルトの名無しさん** · 2021/12/19(日) 23:48:52.91

汚コード

**デフォルトの名無しさん** · 2021/12/19(日) 23:59:56.43

問題文が>>314でこうなってるから
>> | 入力は以下の形式で標準入力から数値が与えられる。
>> | a b c d e

if let [a, b, c, d, e] = line
　.splitn(5, ' ')
　.map(|s| s.parse::<isize>().unwrap())
　.collect::<ArrayVec<_, 5>>()[..] {

あとこれでいい
let is_even = a & b & c & d & e & 1 == 0;

**デフォルトの名無しさん** · 2021/12/20(月) 05:23:59.31

そういえばいつの間にか
let variable = 3;
println!("{variable}");
みたいな書き方が出来るんだけどこれ前からだっけ？

**デフォルトの名無しさん** · 2021/12/20(月) 05:50:08.07

>>338
それはまだnightlyだけですよ
来月の1.58からstableになって使えるようになる予定

**デフォルトの名無しさん** · 2021/12/20(月) 11:31:40.46

>>335
構造化の基本を学びましょう

**デフォルトの名無しさん** · 2021/12/20(月) 18:38:24.90

どちらのコードも正解

**デフォルトの名無しさん** · 2021/12/20(月) 18:57:17.41

コードに「間違い」はあっても「正解」はない

**デフォルトの名無しさん** · 2021/12/20(月) 19:04:29.92

間違っているコードは出ていないような
問題視してる人は具体的に何を問題にしているの？

**デフォルトの名無しさん** · 2021/12/20(月) 20:55:59.37

アスぺ思考はこれだから

**デフォルトの名無しさん** · 2021/12/21(火) 11:25:19.41

https://doc.rust-jp.rs/book-ja/ch18-03-pattern-syntax.html#%E3%83%9E%E3%83%83%E3%83%81%E3%82%AC%E3%83%BC%E3%83%89%E3%81%A7%E8%BF%BD%E5%8A%A0%E3%81%AE%E6%9D%A1%E4%BB%B6%E5%BC%8F
ここの最後のところに

パターンと関わるマッチガードの優先度は、以下のように振る舞います:
(4 | 5 | 6) if y => ...
以下のようにではありません:
4 | 5 | (6 if y) => ...

とあるんですが、後者のようになってほしい場合は4|5と6 if yを別々に書くしか無いですか？

**デフォルトの名無しさん** · 2021/12/21(火) 11:56:47.99

>>345
ガード構文がこう「『Pattern』 if 『Expression』」なのでそうなりますね

**デフォルトの名無しさん** · 2021/12/22(水) 20:44:35.79

sixtyfpsってどう？

**デフォルトの名無しさん** · 2021/12/22(水) 22:58:00.27

> しかし競プロでみんなproconioとかいう謎の専用ライブラリ使ってるの見た目悪すぎて笑える
いや、ほぼ公認のクレートなんだが・・・
謎の専用ライブラリとかいってる時点で、お察しか？

あと、見た目悪いってどういうことなんかね
includeしたら見た目悪すぎなわけ？

**デフォルトの名無しさん** · 2021/12/22(水) 23:53:48.10

Rust bookの以下の記述について質問です

https://doc.rust-jp.rs/book-ja/ch19-05-advanced-functions-and-closures.html#クロージャを返却する
> 以下のコードは、クロージャを直接返そうとしていますが、コンパイルできません:
>
> fn returns_closure() -> Fn(i32) -> i32 {
> |x| x + 1
> }
> コンパイラには、クロージャを格納するのに必要なスペースがどれくらいかわからないのです。
> この問題の解決策は先ほど見かけました。
>
> fn returns_closure() -> Box<Fn(i32) -> i32> {
> Box::new(|x| x + 1)
> }

とBox化しなさいと書かれているのですが
以下のようにimplを付けるとBoxを使わなくてもコンパイルが通り動きました

fn make_closure_add1() -> impl Fn(i32) -> i32 {
|x| x + 1
}

このimpl付加は暗に自動的にBox化されているということなのでしょうか？

**デフォルトの名無しさん** · 2021/12/23(木) 00:23:38.98

ここを読む
https://doc.rust-lang.org/book/ch19-05-advanced-functions-and-closures.html#returning-closures

**デフォルトの名無しさん** · 2021/12/23(木) 07:21:11.33

>>348
そりゃあcratesio に上がったものは空っぽでもゴミでも全部公認だわなｗ

**デフォルトの名無しさん** · 2021/12/23(木) 15:17:54.33

>>342
逆だ、コードは常に「正解」で動いていて「間違い」ない。

あんたの書いたバグもコンピューターにとっては一部の隙もなく正解であり、書かれたその通りに動き、無慈悲である。
同じ目的で、多数、あるいは二人の人が書いたコードで違いが出るのは「表現の違い」であり「間違い」と決めつける
のは人間の主観や嗜好でしかなく、仮にコードへ正誤を求めるなら明確に表現できていなればならず、矛盾が生じる

**デフォルトの名無しさん** · 2021/12/23(木) 15:32:21.87

コンパイルが通らないコードも正解なのかい？

**デフォルトの名無しさん** · 2021/12/23(木) 15:39:30.16

えらいポエミーやな

**デフォルトの名無しさん** · 2021/12/23(木) 18:55:13.24

”動いていて”と言っているからコンパイルは通ってる前提だろう、”コードへ正誤を求める”といっているから
仮にコンパイルが通らないコードは明確にそれ（誤り・間違い）が表現できている
ポエミーなのはその通りだろう

**デフォルトの名無しさん** · 2021/12/23(木) 21:22:53.78

>>349
Boxとはヒープを使うということです
Rustではコードで明示的に指定しない限り勝手にヒープが使われることはないです
(もちろんBox以外にもVecやStringなどヒープを使うものを使ってもそれは明示的に指定したことになります)

その Box<Fn(i32) -> i32> は今は Box<dyn Fn(i32) -> i32> と書く必要があります
では本題の impl Fn(i32) -> i32 と書いた場合はどうなるのでしょうか？
以下のように3種類のクロージャを作ってサイズや型を表示させてみると
fn main() {
　let direct_closure = |x: i32| x + 1;
　let impl_closure = make_impl_closure();
　let box_closure = make_box_closure();
　println!("{} {}", std::mem::size_of_val(&direct_closure), type_of(&direct_closure));
　println!("{} {}", std::mem::size_of_val(&impl_closure), type_of(&impl_closure));
　println!("{} {}", std::mem::size_of_val(&box_closure), type_of(&box_closure));
}
fn make_impl_closure() -> impl Fn(i32) -> i32 {
　|x| x + 1
}
fn make_box_closure() -> Box<dyn Fn(i32) -> i32> {
　Box::new(|x| x + 1)
}
fn type_of<T>(_: &T) -> &'static str {
　std::any::type_name::<T>()
}

実行結果は以下のように表示されます
0 tmp::main::{{closure}}
0 tmp::make_impl_closure::{{closure}}
16 alloc::boxed::Box<dyn core::ops::function::Fn<(i32,)>+Output = i32>
つまりimplでは直接クロージャ指定したのと全く同じです
(上記では定義した関数名だけが異なる)

**デフォルトの名無しさん** · 2021/12/23(木) 21:33:09.04

今日はポエマー多いなw

**デフォルトの名無しさん** · 2021/12/23(木) 22:34:57.88

では常に impl を使えばよいのかというと
以下のような条件によって異なるクロージャを返す時
ここで Box を使わず impl Fn(i32) -> i32 にしようとすると
2つのクロージャの型が違うとコンパイラに怒られます

fn make_closure(curry: Option<i32>) -> Box<dyn Fn(i32) -> i32> {
　if let Some(curry) = curry {
　　Box::new(move |x| x + curry)
　} else {
　　Box::new(|x| x + 1)
　}
}

結局クロージャでない場合と同じ話で
同じトレイトでも型が異なるものが同居する時にBox化します
>>349のRust bookの例はBox化が不要なケースでBox化だから混乱しますね

**デフォルトの名無しさん** · 2021/12/24(金) 11:53:17.86

コンパイル通ってれば全て正解とかバカ丸出し。
厳密な定義でも使えない定義があるってことすら理解してなさそう。

**デフォルトの名無しさん** · 2021/12/24(金) 12:05:46.49

型安全だったらコンパイル通れば実行時エラーにならないという点で全て正解っていうのは別に間違ってないと思うけど？
これにケチつけるのは流石にどうかと

**デフォルトの名無しさん** · 2021/12/24(金) 12:44:01.96

バカ丸出しにお前バカだろとわざわさ言うのもバカなんじゃなかろうか

**デフォルトの名無しさん** · 2021/12/24(金) 15:42:15.21

>>360
実行時エラーにならないなんて最低限のところだっつーの。だからバカだっていうんだよ。

**デフォルトの名無しさん** · 2021/12/24(金) 16:05:46.66

もしかしてrustはlinuxに取り込まれるわけねーだろって言い張っていた人？
予言外していたよね。お疲れ様です。

**デフォルトの名無しさん** · 2021/12/24(金) 16:08:19.93

バカをスルーできないバカっているよねー

>>364
お前の事な

**デフォルトの名無しさん** · 2021/12/24(金) 16:10:39.10

なんか草

**デフォルトの名無しさん** · 2021/12/24(金) 16:20:12.59

25 デフォルトの名無しさん sage 2021/04/27(火) 08:00:23.09 ID:/+bIFNU8
>>23
あのね。。書けばそうなるってものじゃなくてそれを実装しなきゃならんのよ。。
コンパイラにそういったコンテクストを判断させるのがめちゃくちゃ難しいっていってるでしょ？
なんでそんなに読み取れないの？

27 デフォルトの名無しさん sage 2021/04/27(火) 16:10:45.63 ID:/+bIFNU8
>>26
だからそのコードじゃpanic捉えきれねーからカーネルに入れるわけねーだろって
言ってんじゃん。。何読んでんだよ。

28 デフォルトの名無しさん sage 2021/04/27(火) 18:23:48.67 ID:n/AWrch2
まあ半年後どうなるかで誰が正しかったかは分かるわな

29 デフォルトの名無しさん sage 2021/04/27(火) 20:32:29.92 ID:/+bIFNU8
半年も経たなくてももうわかってるっつーの。。だからちゃんと英語の勉強しましょうね。

完全に同一人物だよね

**デフォルトの名無しさん** · 2021/12/24(金) 16:26:02.78

https://lkml.org/lkml/2021/12/6/461

英語読めんならこれになんて書かれているのかわかるよね？

**デフォルトの名無しさん** · 2021/12/24(金) 16:31:02.04

予想が完全に外れたID:8qqh3vKrを晒し上げ♪♪♪
ここまで簡単な予想を外すとかバカ過ぎて生きていけなさそうｗｗｗ
馬鹿丸出しですねｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/24(金) 16:40:31.03

素でバカなんだな。。もうコンパイル通ったんで俺の仕事終わりとか現場で言ってろよ。。話にもならん。

**デフォルトの名無しさん** · 2021/12/24(金) 16:42:14.31

>>362
最低限の性質を満たしている⇔正解って言ってんじゃん。。何読んでんだよ。
なんでそんなに読み取れないの？
だからバカだっていうんだよ。
だからちゃんと日本語の勉強しましょうね。

**デフォルトの名無しさん** · 2021/12/24(金) 16:45:16.93

>>369
なお予言を外したことについては一貫してノータッチｗｗｗｗｗ
話をしたくないのは君だよねｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/24(金) 16:46:19.44

>>369
同一人物だってことはバレバレだっつーの。バカ丸出し。ｗｗｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/24(金) 17:12:05.04

どうでもええわRustの話しろ

**デフォルトの名無しさん** · 2021/12/24(金) 17:38:56.03

厳密な定義でも使えない定義？Rustに特定条件下でCのような未定義になる動作あったっけ？

**デフォルトの名無しさん** · 2021/12/24(金) 18:41:11.93

スレの文脈はしらんけど、
Rustではunsafeを使ってなければコンパイラが、未定義動作が起きないということや、データ競合がないことを保証をしてくれるよ

**デフォルトの名無しさん** · 2021/12/24(金) 19:10:24.57

>>369
予言外れましたよね？ｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/25(土) 15:28:33.08

Rustでフロントエンドしてる奴おる？

**デフォルトの名無しさん** · 2021/12/26(日) 12:56:45.57

Rustの勉強を昨日から開始した。後は構造体とかかな。

**デフォルトの名無しさん** · 2021/12/26(日) 17:26:13.09

コード貼ったら糞だボケだゴミだと自称上級者に罵倒されるから注意しろ

**デフォルトの名無しさん** · 2021/12/26(日) 19:27:36.42

Rustはこう謳っている
>なぜRustか？
>パフォーマンス
>信頼性
>生産性
真っ向から反するコードを貼ってりゃゴミ・クソ言われて当然なんだよなぁ

**デフォルトの名無しさん** · 2021/12/26(日) 19:29:23.79

すまんが、配列に入った数値の平均ってパッと出せないもんなの？
他言語でふにゃふにゃになった俺の頭でコードを書いたら、桁の溢れとか精度とか酷えことになりそう・・・・

**デフォルトの名無しさん** · 2021/12/26(日) 20:24:04.94

コードもゴミだったがそれ以上に考え方がゴミだったからな

**デフォルトの名無しさん** · 2021/12/26(日) 20:42:21.32

>>381
これ使ったらよいのでは
https://docs.rs/streaming-stats/0.2.3/stats/fn.mean.html

**デフォルトの名無しさん** · 2021/12/26(日) 22:30:25.75

>>381
普通に平均を求めるだけではダメなのでしょうか？

fn main() {
assert_eq!(5.5, (1..=10).average());
assert_eq!(6.8, [2.3, 8.7, 9.4].average());
}

use num::ToPrimitive;
trait Average {
fn average(self) -> f64;
}
impl<I> Average for I
where I: IntoIterator, <I as IntoIterator>::Item: ToPrimitive,
{
fn average(self: I) -> f64 {
self.into_iter().fold((0.0, 1.0), |(ave, size), n| (ave + (n.to_f64().unwrap() - ave) / size, size + 1.0)).0
}
}

**デフォルトの名無しさん** · 2021/12/27(月) 00:09:24.17

カハンの加算アルゴリズムというのがある

**デフォルトの名無しさん** · 2021/12/27(月) 09:11:03.63

汚コードｷﾀ━！

**デフォルトの名無しさん** · 2021/12/27(月) 10:50:10.93

何でもトレイト化するアホ

**デフォルトの名無しさん** · 2021/12/27(月) 12:29:15.17

ゴミをゴミだといって何が悪い！

**デフォルトの名無しさん** · 2021/12/27(月) 12:32:52.22

ここの人たちってplaygroundとかなんで完全に動かせるコードで提示しないんだろ・・・？
アドバイス貰うにも回答するにも一生懸命スペース全角置換したり、まじ両方キモイｗ
trait Averageｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/27(月) 13:09:28.61

こう言う時って普通の関数にしちゃいかんの？

**デフォルトの名無しさん** · 2021/12/27(月) 14:19:38.18

普通の関数にすべきかどうかはメソッドチェーンにしたいかどうかで判断すればよろしい

**デフォルトの名無しさん** · 2021/12/27(月) 14:43:10.42

>>389
playgroundでは自己顕示欲が満たせないんだよw

まあplaygroundでは動かせないコードもあるけどな

**デフォルトの名無しさん** · 2021/12/27(月) 15:03:42.29

>>381
こういう子は、移動平均出したくなった時とかどうすんだろ…
愚直に毎回平均出す関数とか使っちゃうわけ？

**デフォルトの名無しさん** · 2021/12/27(月) 21:04:27.03

しょうがない、一応は専門家が書いているであろう他言語の実装を参考にしよう・・・・
https://source.dot.net/#System.Linq/System/Linq/Average.cs,2b4701af991d5425
俺様、信頼して使っていたメソッドの衝撃の事実を知る

**デフォルトの名無しさん** · 2021/12/27(月) 21:09:19.15

浮動小数点型ならそういう素直な実装で十分だよ

**デフォルトの名無しさん** · 2021/12/27(月) 21:53:06.04

>>384
それだと桁溢れは防止できているが誤差蓄積の対処ができていない
もう一つパラメタを増やしてこうしたほうがいい
fn average(self: I) -> f64 {
self.into_iter().fold((0.0, 1.0, 0.0), |(ave, size, fix), n| {
let diff = (n.to_f64().unwrap() - ave) / size - fix;
let new_ave = ave + diff;
(new_ave, size + 1.0, (new_ave - ave) - diff)
}).0
}

>>387
イテレータメソッド化するにはそのためのtrait宣言が必須
もしわからないならitertoolsなどのイテレータ拡張ライブラリを見よう

>>389
標準ライブラリのsum()がtrait Sumを使っているからtrait Averageでもまあいいとは思う
ただし今回はイテレータメソッド拡張のみに用いているようだからtrait IteratorExtなどの命名がわかりやすいとは思う

**デフォルトの名無しさん** · 2021/12/27(月) 21:56:50.25

IteratorExt大草原、まじに入院してほしいｗ

**デフォルトの名無しさん** · 2021/12/27(月) 22:01:57.73

イテレータメソッドにする必要ある？

**デフォルトの名無しさん** · 2021/12/27(月) 22:15:24.91

>>398
標準ライブラリにおいてsum()やproduct()
それを一般化したfold()やreduce()
さらにmax()やmin()など当然イテレータメソッドになっている
むしろ今回のaverage()だけをイテレータメソッドにしない理由が見当たらない

**デフォルトの名無しさん** · 2021/12/27(月) 22:20:18.56

>>399
じゃあなんで標準ライブラリにないの？

**デフォルトの名無しさん** · 2021/12/27(月) 22:25:16.01

カハンの加算使ったのか

**デフォルトの名無しさん** · 2021/12/27(月) 22:31:56.63

>>400
入力型と出力型で大量の組み合わせ(例:i32→f32)が用途に応じて要求されるのと
単純に合計をサイズで割った平均でよい用途もあれば
件数が多いと合計がオーバーフローするからその対策が欲しい用途もあれば
桁が大きく異なるデータ列の場合に浮動小数点の誤差改善が欲しい用途など多岐にわたる
だから平均を標準ライブラリで何か一つ用意は無理