C vs C++ vs Rust Part.2

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

競え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

たったぞ

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

C vs は余計だった

**デフォルトの名無しさん** · 2021/12/15(水) 13:56:40.08

Cに原点回帰しようよ

**デフォルトの名無しさん** · 2021/12/15(水) 13:57:35.77

GoはC++というよりCっぽいよな

**デフォルトの名無しさん** · 2021/12/15(水) 14:37:20.55

Goはモダン言語にアレルギー反応が出てしまうC老人のための言語

**デフォルトの名無しさん** · 2021/12/15(水) 16:01:42.93

顔真っ赤な怒り心頭Rustオジサンがなぜかスレタイに無いGoを粘着でディスり続ける

**デフォルトの名無しさん** · 2021/12/15(水) 16:09:17.23

言語仕様が優れてるとかなんとかはあるだろうけど
結局使いものになる言語は何かと言われればC/C++なんだよ

**デフォルトの名無しさん** · 2021/12/15(水) 16:23:40.38

Rustは流行りもの
C、C++は基本

**デフォルトの名無しさん** · 2021/12/15(水) 17:32:42.49

RustとC++が互いに馬鹿にし合うのをCが高みの見物するスレですか？

**デフォルトの名無しさん** · 2021/12/15(水) 18:10:14.36

CやC++なんて、UNIXかWindowsが成功してなきゃ流行ってたわけない
（そもそもUNIXがないなら、C言語も生まれてないけど）
結局は勝ち組プラットフォームにおんぶにだっこされてるだけよ

Rustも巨大企業に推されて採用されてるから、優れてる言語かどうかに関係なく流行る

流行は巨人が決めてる

**デフォルトの名無しさん** · 2021/12/15(水) 18:23:30.40

Rustンサーガ
パンツ一丁でオッサンが闘うヤツ

**デフォルトの名無しさん** · 2021/12/15(水) 18:49:53.25

本当のプログラマはPascalを使う

**デフォルトの名無しさん** · 2021/12/15(水) 19:02:30.51

May the FORTH be with you.

**デフォルトの名無しさん** · 2021/12/15(水) 19:10:44.73

いまだに組み込みはCオンリーですが、「UNIXがないなら、C言語も生まれてない」は間違いに近い
https://ja.wikipedia.org/wiki/C言語#歴史

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

>>8
でもチーム開発するならRustの安全性は100%じゃないとしても十分魅力的だなぁと思う。

**デフォルトの名無しさん** · 2021/12/15(水) 19:21:40.26

>>15
それ読んだら、
UNIXの *ために* C言語が作られたわけじゃないけど、UNIXが *なかったら * C言語も生まれてない、と読めるけど。

**デフォルトの名無しさん** · 2021/12/15(水) 19:59:26.95

>>9
C・・・ベーシックアイテム。
C++・・・おしゃれアイテム。
Rust・・・意識が高くなる壷。

**デフォルトの名無しさん** · 2021/12/15(水) 20:02:20.26

RustやRubyは、まず伝道師から始まるからな。
どういうわけか伝道師が大量発生する。

**デフォルトの名無しさん** · 2021/12/15(水) 20:03:30.36

C++使いがコード書いてる間、彼らは伝道する。
神の使いなのかもしれんな。
啓示があったんだろう。

**デフォルトの名無しさん** · 2021/12/15(水) 20:08:47.10

Rustは実用に主眼を置いた泥臭い言語なので
伝道師の言う美辞麗句は無視してよい

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

っつか、いくら伝道師わいたってRust自身がその敷居の高さで安易に手を出すやつを排除するからRubyみたいには使われないんじゃねーの？

**デフォルトの名無しさん** · 2021/12/16(木) 11:27:59.15

プログラミング勉強のため素数列を返すイテレータ関数を作ってみました
今回トレイト境界は0と1とoverflow防止足し算と比較演算子のみとなりました

use itertools::{unfold, Unfold};
fn prime<T>() -> Unfold<T, impl FnMut(&mut T) -> Option<T>>
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　unfold(T::one(), |a| {
　　unfold(*a, |b| { if let Some(c) = b.checked_add(&T::one()) { *b = c; Some(c) } else { None } }).map(|b| { *a = b; b })
　　.find(|b| !unfold(T::one(), |c| { if let Some(d) = c.checked_add(&T::one()) { *c = d; if d < *b { Some(d) } else { None } } else { None }})
　　.find(|c| unfold(T::zero(), |d| { if let Some(e) = d.checked_add(c) { *d = e; if e <= *b { Some(e) } else { None } } else { None } }).any(|d| d == *b)).is_some())
　})
}

型指定で『i8』(符号付き8bit整数)を与えて実行してみます

fn main() {
　for p in prime::<i8>() {
　　print!("{} ", p);
　}
}

出力結果
2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 103 107 109 113 127

i8型は127が上限値(2^7-1)なので上手く動作してるようです
コードが少し長くなってしまったので冗長なところや改善点など教えていただけると幸いです

**デフォルトの名無しさん** · 2021/12/16(木) 14:51:19.13

クソコード過ぎでこんなの誰も見ないよ

**デフォルトの名無しさん** · 2021/12/16(木) 15:20:11.27

>>24
良いコードをご教授していただけませんか？
普通にループは使わずに足し算と比較のみで素数をその型の上限まで返すイテレータ関数です
言語はCでもC++でもRustでも構いませんのでよろしくお願いします

**デフォルトの名無しさん** · 2021/12/16(木) 15:29:32.29

Playgroundでu16に変えたらTLEした

**デフォルトの名無しさん** · 2021/12/16(木) 15:30:55.42

>>25
>>23ですらループ使ってるじゃん
馬鹿そう

**デフォルトの名無しさん** · 2021/12/16(木) 15:38:05.88

>>27
どこにループが有りますか？
勉強不足でわからないので教えてください

**デフォルトの名無しさん** · 2021/12/16(木) 15:59:44.48

Rustのコードはなに見てもきたねぇな

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

>>29
それは私がプログラミング勉強中だからだと思います
あるいはCやC++ならば「ループを使わずに足し算と比較のみで素数をその型の上限まで返すイテレータ関数」を
綺麗にプログラミングできますか？
綺麗なコードをご教示していただけるとうれしいです

**デフォルトの名無しさん** · 2021/12/16(木) 17:08:55.09

>>23
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=3e0c372e78ce024307bd58c1f03df55e

.find(..).is_some() は .any() と書ける (これはclippyが指摘してくれる)
if let Some(x) = expr { .. } else { None } は let x = expr?; .. とした方がネストが浅くなる
類似の処理は名前をつけて関数に括りだした方がわかりやすい

**デフォルトの名無しさん** · 2021/12/16(木) 17:33:56.80

>>23
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=6d5f63ffe7c46236a0957017db33a0b9
もう少し改善できた
スレ汚しすまん

**デフォルトの名無しさん** · 2021/12/16(木) 17:35:37.19

>>31のコード見た後に>>23見るとゲロ吐きそうになるな

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

>>28
例えばfindはtry_foldを呼び出してるがこのメソッドはwhileを使って実装されている
どこかにループあるとわかりそうなもんなんやけどな

**デフォルトの名無しさん** · 2021/12/16(木) 18:19:05.42

rustのコードはc/c++以上に見苦しい
こんな言語を業界全体でプッシュしてるのは異常だよ

**デフォルトの名無しさん** · 2021/12/16(木) 18:37:24.71

>>35
どの業界の話だよ

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

日本のC++業界だよ

**デフォルトの名無しさん** · 2021/12/16(木) 19:06:28.01

なんでこいつRustの本スレでやらないんだろ、ほんまキモイ

**デフォルトの名無しさん** · 2021/12/16(木) 19:15:09.93

本スレで自己満足やられて本気でウザかったからここでいいよ

**デフォルトの名無しさん** · 2021/12/16(木) 19:40:56.05

だからここはガイジ隔離用のスレなんやで

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

>>31
色々とありがとうございます
返り型がOptionだから?を使うとif letを消せるとは気付いていませんでしたw
あとそのコードを見ると渡す値を変えないならmapよりinspectを使うといいのですね
さらにご指摘くださったfindとis_someを合わせてanyにしたり否定!と合わせてallへ変えたり
まだ類似部分の別関数への分離までは進められていないのですがようやくここまで来ました

fn prime<T>() -> Unfold<T, impl FnMut(&mut T) -> Option<T>>
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　unfold(T::one(), |a| {
　　unfold(*a, |b| {
　　　*b = b.checked_add(&T::one())?;
　　　Some(*b)})
　　.inspect(|b| *a = *b )
　　.find(|b| unfold(T::one(), |c| {
　　　*c = c.checked_add(&T::one())?;
　　　(*c < *b).then(|| *c)})
　　.all(|c| unfold(T::zero(), |d| {
　　　*d = d.checked_add(&c)?;
　　　(*d <= *b).then(|| *d)})
　　.all(|d| d != *b)))
　})
}

>>34
どうもありがとうございます
調べて勉強します

**デフォルトの名無しさん** · 2021/12/16(木) 20:07:32.48

字面だけみるとPerlとどっこいの汚さだな

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

>>35 >>42
これ全く同じ機能をC++だと美しく書けるんかいな？
前スレでもRustの動くコードは出ていたがC++の動くコードは全く出てこなかったよな
だから既にC++プログラマーは絶滅していてRust派とアンチRust派(数学100点マン等)だと思ってた

**デフォルトの名無しさん** · 2021/12/16(木) 20:25:07.71

unfold使ったこと無いから間違ってたら教えてほしいんだけど
これO(n^4)？

**デフォルトの名無しさん** · 2021/12/16(木) 20:34:01.51

ゲロのようだ

**デフォルトの名無しさん** · 2021/12/16(木) 20:37:46.92

さわやかな新宿の朝って感じですね。
ゲロの臭いでもらいゲロしそう。

**デフォルトの名無しさん** · 2021/12/16(木) 20:54:48.37

>>44
違うと思います
まずunfold自体はループするものではなくこれだけです
struct Unfold<S, F> { s: S, f: F }
fn unfold<S, F, R>(s: S, f: F) -> Unfold<S, F> where F: FnMut(&mut S) -> Option<R> {
　Unfold { s, f }
}
impl<S, F, R> Iterator for Unfold<S, F> where F: FnMut(&mut S) -> Option<R> {
　type Item = R;
　fn next(&mut self) -> Option<Self::Item> {
　　(self.f)(&mut self.s)
　}
}

次に今回のコードで使われているunfoldについてですが
一番外側のunfoldは上述の構造体を返すだけになります
次のunfoldは素数でない数をスキップするだけで残り2つがO(n^2)となるでしょうか
どの言語で書いても足し算のみ使用だとこれは避けられないかと思います

あとコードが汚いとおっしゃる方は同条件で綺麗なコードを示してくださるとありがたいです
CでもC++でもRustでも構いません

**デフォルトの名無しさん** · 2021/12/16(木) 22:36:01.50

そもそも
「ループを使わずに足し算と比較のみで素数をその型の上限まで返すイテレータ関数」
というのはどこからでてきたもんなんだ？
この条件になにか意味があるの？

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

>>48
まず素数なら列になるのでイテレータにするのはいいですよね
用いる型によって上限値が異なるから上限まで返すのも自然ですよね
足し算と比較は必要最低限として不可欠だと思います
どうしてもならばループは使ってもいいですよ
だから今回は可能ならばループを直接使わずに高階関数イテレータ使用でという話だけです
つまりそんな難しい話をしているわけではないと思います
他の言語のコードが出てこないのは難しいからなのでしょうか？

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

Rustのことは知らんのだけどsome, any, map, findって実質ループじゃないの？
Rubyっぽい構文も見られるけどブロックを毎度呼び出してもらってるだけだからループじゃないとかいうわけ？

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

>>50
登場していたSomeは値付きenumなのでデータの型です
mapは変換するだけなのでそれ自体にループ要素はないです
一方でfindなどはループを内包している高階関数になりますね
だから>>49にて「今回は可能ならばループを直接使わずに高階関数イテレータ使用」と書いたのです

宿題となっていた類似部分を別関数へ切り出しが出来ました
これでわかりやすくなったでしょうか？

fn prime<T>() -> Unfold<T, impl FnMut(&mut T) -> Option<T>>
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　unfold(T::one(), |a| {
　　inc(*a, T::one(), |x| x > T::zero()) // 無条件に+1していき次の素数を探す
　　.inspect(|b| *a = *b) // unfoldのため値更新
　　.find(|b| inc(T::one(), T::one(), |x| x < *b) // 自分より小さい数で+1していき約数を見つける
　　　.all(|c| inc(T::zero(), c, |x| x <= *b) // その約数の候補を自分以下で足し算していく
　　　　.all(|d| d != *b)))}) // 自分が倍数になっていなければOK
}

fn inc<T>(s: T, a: T, f: impl Fn(T) -> bool) -> Unfold<T, impl FnMut(&mut T) -> Option<T>>
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　unfold(s, move |x| { *x = x.checked_add(&a)?; f(*x).then(|| *x) })
}

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

>>49
人に読ませるためのコードを書いたことがないのかな？
アルゴリズム的にどうとかRustの書き方的にどうとか言う以前の問題

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

>>51
めっちゃ理解しやすくなったな
まるで宣言型論理プログラミングっぽい雰囲気だ
説明の日本語はこう書くとよい

//素数とは自分未満で次を満たす約数を見つけること
.find(|b| inc(T::one(), T::one(), |x| x < *b)
　// 条件は約数の倍数すべて(自分以下)が
　.all(|c| inc(T::zero(), c, |x| x <= *b)
　　// 自分と一致しないこと
　　.all(|d| d != *b)))})

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

恥ずかしい自演

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

ん？
あと変数名をわかりやすく変えたほうがいいぞ

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

本スレでクソコード連投してた奴だな
素数列挙をジェネリックにしてうれしがるセンスが厨二病っぽい

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

計算量悪くね？

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

>>17
DEC PDP-11で動かすUNIXを書くためにC言語が生まれたと思ったが？
C言語の方が後なら、最初のUNIXは何の言語で書いてあったの？

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

アセンブリ言語

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

>>58
Wikipediaにすら「当初はアセンブリ言語のみで開発されたが、1973年にほぼ全体をC言語で書き直した。」と書かれているんだけど。

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

>>18
要するに
Cはマック
C++はスタバ
Rustはブルーボトルって理解でおｋ？

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

>>55
ご指摘ありがとうございます
変数名を英語やローマ字にしてもわかりにくかったため日本語にしました
あとは無駄な部分を整理した結果シンプルになりました

fn 素数列<T>() -> impl Iterator<Item=T>
　where T: Copy + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　range(T::one(), |_| true)
　.filter(|&素数|
　　range(T::one(), |約数| 約数 < 素数)
　　.all(|約数|
　　　range(約数, |約数倍数| 約数倍数 <= 素数)
　　　.all(|約数倍数| 約数倍数 != 素数)))
}

fn range<T>(unit: T, cond: impl Fn(T) -> bool) -> impl Iterator<Item=T>
　where T: Copy + num::CheckedAdd,
{
　itertools::unfold(unit, move |x| {
　　*x = x.checked_add(&unit)?;
　　cond(*x).then(|| *x)
　})
}

fn main() {
　itertools::assert_equal(素数列::<i8>(),
　　[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79,83,89,97,101,103,107,109,113,127]);
　assert_eq!(素数列::<u8>().last(), Some(251));
}
コードが汚いとご批判くださっていた皆さま方
これでいかがでしょうか？

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

マジで何がしたいんだろこいつ

使えなさ加減は似たようなものだが
計算量を重視するだけ競プロ信者のほうがまだマシ

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

コードゴルフみたいなパズル感覚なんじゃね
知らんけど

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

rustの構文が本当に受け付けない

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

言語の構文が受け付けないというとこの話を思い出す
http://love-motif.com/article/art_13.shtml

rustの構文に対してこんな感じで生理的嫌悪覚えてるんですか？

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

rustが流行って、こういう素数なんて書く意識高い初心者が量産されて、汚ねぇコードを治すのかと思うと
今から頭痛がしてくる

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

>>61
Rustは晋三が飲んでる何とか還元水では？
意識タッケーーー！！！

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

>>65
今どきは他のプログラミング言語も似たようなものだぜ
例えば配列 [4, 9, 3, 7, 1, 8, 5] から文字列 "9-8-7-5-4-3-1" への変換

【Ruby】
a.sort().reverse().map{|x| x.to_s}.join('-')

【JavaScript】
a.sort().reverse().map(x => x.toString()).join('-')

【Rust】
a.iter().sorted().rev().map(|n| n.to_string()).join("-")

このように些細な違いのみでほとんど一緒
逆に古典的な記述法は以下のようにコードが読みにくい

【Python】
'-'.join(map(lambda x: str(x), reversed(sorted(a))))

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

>>69
FORTHの時代が来たな。

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

【Rust】
a.iter().sorted().rev().map(|n| n.to_string()).join("-")
これはどんなアセンブリコード吐くの？

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

>>71
元のコードコンパイル通らないので適当に変更してみた
https://godbolt.org/z/KTTcEccfz

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

>>72
Rustでは最小限しかstdに入れない方針
use itertools::Itertools; を付ければ>>69で通る

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

>>67
どう見てもめちゃくちゃ意識低いやつのコードなんですけど・・・
どこに意識高い系要素を見出だしたんだ？

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

>>71
Rustの各イテレータメソッドは全て各々の固有の構造体(struct)を返すだけです
アセンブリコードはスタック上に確保された構造体の大きさの領域にその値が入ることになるでしょう
そしてその構造体に対してnext()という関数が実装されています
後続の別のイテレータが自分に対してそのnext()を呼び出すことになります
そして他からnext()を呼ばれた側は自分の構造体のデータを利用して値を返します
これらのアセンブリコードは普通の関数呼び出しと同じでしょう

具体例を見たほうが早いと思います
例えばもう少し簡単な以下の例を動かしましょう
fn main() {
　let v = vec![5, 6, 7, 8, 9];
　v.my_iter().my_print();
}
このベクタvに対してmy_iter()さらにmy_print()とチェーンになっている例で説明します
多くの場合はライブラリにあるイテレータを使うので自分で実装しなくていいのですが
アセンブリコードが気になる(＝どう動作しているの？)とのことなのでゼロから実装します

このmy_iter()も構造体を返すだけの関数です
ここでは説明をわかりやすくするためジェネリックでなく
具体的な型『Vec<i32>』(符号付き32bit整数のベクタ)に対してmy_iter()を実装します

まずmy_iter()が返す構造体を定義します
struct MyIter {
　vec: Vec<i32>,
　index: usize,
}
ベクタの値を次々と返していけるようにベクタとそのインデックスを保有します
変数名と型の位置がC言語とRustでは逆なだけでわかると思います
インデックスのための型『usize』は符号なし整数です

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

そしてmy_iter()の関数をVec<i32>に対して実装します
まず以下のtraitの部分は今回おまじないとして無視していいです
trait MyIterTrait {
　fn my_iter(self) -> MyIter;
}
次が関数my_iter()のVec<i32>に対する実装(impl)です
impl MyIterTrait for Vec<i32> {
　fn my_iter(self) -> MyIter {
　　MyIter { vec: self, index: 0 }
　}
}
このように関数my_iter()は>>75で定義した構造体MyIterを返しているだけです
アセンブリコードはC言語などと同じになるでしょう
ただしC言語では構造体はポインタ返しのみだったと思いますが
Rustでは構造体をそのまま返せてこれはスタック領域にデータが返ります

あとは冒頭に説明しましたイテレータとして機能するためのnext()が必要です
構造体MyIterに対してイテレータの実装(impl)をします
impl Iterator for MyIter {
　type Item = i32;
　fn next(&mut self) -> Option<i32> {
　　if self.index < self.vec.len() {
　　　let ret = self.vec[self.index];
　　　self.index += 1;
　　　Some(ret)
　　} else {
　　　None
　　}
　}
}
ベクタの現在のインデックス値を Some(ret) と返しているだけです
インデックスがベクタの長さを超えたら None を返しています

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

ではこの>>76の構造体MyIterのnext()は誰がいつ呼ぶのでしょう？
ここではメソッドチェーンになっているので後続のイテレータが呼びます
具体的には>>75で v.my_iter().my_print(); でしたからmy_print()が呼び出します

そこで関数my_print()の定義です
今回もtraitの部分はおまじないと思って無視していいです
trait MyPrint {
　fn my_print(&mut self);
}
下記で任意のイテレータに対して関数my_print()を実装(impl)します
そのためこの部分だけはジェネリック指定『<I: Iterator>』のコードをご容赦ください
後ろのwhere以降の std::fmt::Display は表示を許可するためのおまじないと思ってください
impl<I: Iterator> MyPrint for I
　where I::Item: std::fmt::Display
{
　fn my_print(&mut self) {
　　while let Some(val) = self.next() {
　　　println!("{}", val);
　　}
　}
}
ここでmy_print()のselfというのはここでimpl対象＝先行するイテレータすなわちMyIterになります
もちろんMyIter以外の別のイテレータに対してもこのmy_print()は機能します
今回の使い方ではselfは構造体MyIterになりますから
whileのところにあるself.next()も先程定義したMyIterのnext()になります
next()の返り値が Some である限りprintln!で表示して None になるとwhileを抜けて終了です

以上で冒頭の以下の例の全てコードが実装されましたので動きます
fn main() {
　let v = vec![5, 6, 7, 8, 9];
　v.my_iter().my_print();
}

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

今回>>77のmy_print()はメソッドチェーンの最後なので構造体を返していません
だから正確にはmy_print()はイテレータではなくイテレータに実装されたメソッド(の一つ)という立場だけです
逆に言えばメソッドチェーンの途中の全てのイテレータメソッドは各々の固有の構造体を返します
そして後続のイテレータ(など)からnext()の値を要求されたらそれを返す動作のみするのがイテレータです

長いメソッドチェーンで一番最後がnext()を要求して連鎖的に最初のnext()が呼ばれるパターンもよく有ります
なぜなら多くのケースで途中のイテレータは自分のnext()実装で先行するイテレータのnext()を呼び出すからです
そして連鎖的にnext()呼び出しが生じても動作原理は多段の関数呼び出しと同じです

したがって元の質問>>71「どんなアセンブリコード吐くの？」も
「イテレータとして機能するメソッド呼び出しは単なる関数であって構造体を返すだけ」と
「あとで後続からその構造体に実装されてるnext()関数が呼ばれる」だけなのです
特別な仕組みとか裏でインタプリタやランタイムや魔法が密かに動いている、ってことはないです

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

文章を構造化できない人はコードを構造化することもできない

ひとりよがりが過ぎる

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

>>79
では修正点や改善点などをお待ちしておりますw

**デフォルトの名無しさん** · 2021/12/18(土) 01:55:26.24

ヒトに頼るな。

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

ワロタ

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

どんなアセンブリコード返すのという質問なんだから >>72 みたいにアセンブリ示せばよかろうに

**デフォルトの名無しさん** · 2021/12/18(土) 02:43:52.24

イテレータの作りを説明してくれた人ありがとう
それ自体は他の言語でもよくあるパターンだね
ただ聞きたかったのは効率を重視するはずの（と思っている）言語が
この書き方で効率のよいコードを吐けるかどうかってこと
>a.iter().sorted().rev().map(|n| n.to_string()).join("-")
Rustはimmutableが基本と言う話を聞いてるからもしかしたら
新しいオブジェクトを生成しまくってるんじゃないかと思ったんだよ
この書き方をしてC/C++と同レベルの効率のコードが吐けるのかなって

**デフォルトの名無しさん** · 2021/12/18(土) 02:56:00.48

>>84
そのコードは to_string() を要素数だけ呼んで最後に join してるからヒープアロケーションの回数が気になる場合は使うべきでないコードだね
だだrustのイテレーターのメソッドチェーン自体は不要なヒープアロケーション行わないしメソッドはインライン展開できるので
ある程度複雑なメソッドチェーンでもfor文と同じようなアセンブリになると言われているよ

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

>>84
例えばCのfor文などと比較すると、
その変化していく変数は構造体の中だが大元の関数のスタック上すなわちローカル変数と同じだからCと変わらん
あとinline展開指定されてるものなどで関数呼び出しオーバーヘッドも消えて前後のコードが繋がって最適化されるパターンもある
だから気にせずに使っても誤差範囲

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

RustってC++に似てるな
ゲロみたいな構文だ

**デフォルトの名無しさん** · 2021/12/18(土) 03:38:45.07

>>85
結局メソッドチェーンとは別問題として
一般的にVecやStringなどのヒープ使うものがループ内にあると注意やな
あとcollectでスタック使うArrayVecやArrayStringを指定する手もあるな

**デフォルトの名無しさん** · 2021/12/18(土) 04:55:38.30

>>69
> 配列 [4, 9, 3, 7, 1, 8, 5] から文字列 "9-8-7-5-4-3-1" への変換
> a.iter().sorted().rev().map(|n| n.to_string()).join("-")

このコード自体は他言語との類似比較のために冗長に書かれていて無駄がある
join("-")はDisplay実装あれば通るから事前のto_string()は不要
つまりa.iter().sorted().rev().join("-")でOK

さらにsorted()はヒープに結果Vecを確保する
もし元を書き換えていいならヒープ確保をjoin()でのString一つだけで済む

let mut a = [4, 9, 3, 7, 1, 8, 5];
a.sort();
assert_eq!("9-8-7-5-4-3-1", a.iter().rev().join("-"));

このrev()を無くすためにa.sort_by(|x, y| y.cmp(x))にするとcmp関数でやや不利
一方でrev()使用は配列やVec相手ならDoubleEndedIterator実装があるからコストかからない
現実にはこのコードが核心部分でなければそこまで気にしなくていいけどな

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

一つだけアドバイスしとくけど、ジェームス・ボンドが日本人だったら、大木・凡人だからね。

**デフォルトの名無しさん** · 2021/12/18(土) 08:35:30.45

>>74
Rustを使ってればカッコイイという錯覚で、何も分かってないのに汚物のようなコードと意味不明な長文をまき散らす…
あんなに単純な初期のJavaやC#でさえスパゲッティコードだらけなのに、日本語の説明さえも気持ち悪い

**デフォルトの名無しさん** · 2021/12/18(土) 10:28:10.29

>>91
こじらせてんな
ゲロコード君とは違う方向性だが

**デフォルトの名無しさん** · 2021/12/18(土) 11:41:10.36

長文二人は属性が似過ぎだろ
こんなのが二人もいればRustスレが気持ち悪くなるわな

**デフォルトの名無しさん** · 2021/12/18(土) 16:44:21.13

顔真っ赤で根拠も反論もない「こじらせてんな」マンが永遠と長文や短文を書き、本Rustすれに代わりキチガイを集めるスレ

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

延々とな
ガイジそう

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

元々rustスレの隔離スレなんだから大成功でしょ

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

>>91
>あんなに単純な初期のJavaやC#でさえスパゲッティコードだらけなのに、日本語の説明さえも気持ち悪い

文の前半と後半のつながりが全くわからないので解説頼む

**デフォルトの名無しさん** · 2021/12/18(土) 21:02:25.05

> この難しさを取り除くために、Rustは、C/C++の落とし穴を排除し、その過程で使いやすく役に立つ
> 洗練された一連のツールを提供します。低レベルな制御に「下がる」必要があるプログラマは、
> C/C++のクラッシュやセキュリティホールのリスクを負わず、気まぐれなツールチェーンのデリケートな
> 部分を学ぶ必要なくRustで同じことができます。さらにいいことに、 Rustは、スピードとメモリ使用の観点で
> 効率的な信頼性の高いコードへと自然に導くよう設計されています。

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

顔真っ赤Rustオジサンの「＞」、やっぱ同一人物だったかｗ

**デフォルトの名無しさん** · 2021/12/18(土) 21:56:16.22

>>84
その、新しいオブジェクトを生成しまくってるんじゃないか、の意味が曖昧なので
自動的にヒープ領域から動的に新たなメモリ確保をすると解釈すると、それはないです
Rustでもプログラムで明示的に指定しない限り勝手にそういうことが起きることはありません

もちろん例えばVec型(伸長可能な配列)やString型(伸長可能な文字列)を新たに返す関数を使えば
それはプログラムで明示的に指定したことになり、当然ヒープ領域が使われます

一般的にイテレータの長い連鎖があっても各イテレータが返す(＝用いる)構造体は各1つで
それらはコンパイル時に静的に確定してスタック上にローカル変数と同様に領域が確保されます
したがってイテレータ連鎖で動的にヒープが使われうるのは例えば
(1) イテレータがクロージャを引数として取る場合にそのクロージャのコードがヒープを使うものである場合
(2) sorted()のように前イテレータから全要素を一旦受け取る必要がある途中のイテレータが一時格納場所としてヒープを用いる場合
(3) collect()のようにイテレータ連鎖の最後に全要素を収集してVecやStringなどを新たに生成する場合
いずれもそれらの関数やクロージャをプログラムで使用した時のみ、動的にヒープが使われます

**デフォルトの名無しさん** · 2021/12/18(土) 22:26:29.42

何が気持ち悪いかというと
自分も知らなかったことを調べてきてさも知ってたかのように上から目線でレスする精神
気持ち悪い

そしてその内容がいつも間違えてるからゲロ吐く気分になる

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

多少の間違いがあっても要点をおさえて質問に正面から答えてるんならまだいいんだけどねー
困ったもんだ

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

間違いがあれば俺が指摘修整してやるから安心しろ
おまえら雑魚はそれでいい

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

おまえは間違ってるって主張だけだと数学100点の人と同じだぞ
せっかくだからどこが間違ってるか指摘してあげなよ

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

そいつらは前スレからそんな感じだから放置されてる
ガイジとかゲロとか汚などの言葉を好む
具体的なコードや具体的な指摘は出来ないダメな連中

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

プログラム勉強しはじめたんだけど、CとかC++よりもRUSTのほうがかっこよさげだからRUSTやってる

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

意識他界系かよ

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

CやLispからはじめるのが意識高い系
Rustからはじめるのはカッコつけたいだけの単なる無知

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

C++から始めるのは何系？

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

CがあるのにC++から始めるひとはガイジ系

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

10年早い系

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

ウッホウッホホ、マウンテンゴリラです。得意なのはドラミングで毎日ドコドコやってます

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

>>108
なんでrustからだとあかんの？

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

マルチパラダイムだからでは。

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

>>114
よく知りもせんなら黙ってろや

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

最近c++勉強始めたんだが、cとかmapも使えないじゃん
どうしてんの？

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

mapを作るための言語がCだから。

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

RustはコンパイラもライブラリもRustで書かれているね

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

>>116
昔はアルゴリズムの教本を参考にして全部1からつくってた

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

今も必要があれば車輪の再発明をする能力を持つ人と持たない人にプログラマーは二分される
前者は新たな枠組みを作ることも可能な生産者
後者は既存の枠組みを使うだけの消費者

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

俺には検討もつかんわ
所詮俺は消費者か…

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

見当

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

コンシューマーって言えばカッコよくなるよ。

**デフォルトの名無しさん** · 2021/12/21(火) 02:18:43.99

プロデューサーとコンシューマーと呼ぶと両方存在して初めて意味を持ちそうな感じがするな

**デフォルトの名無しさん** · 2021/12/21(火) 02:38:28.55

この場合の生産者は、制作者(プロデューサー)ではなくて創造者(クリエイター)の方が近い

**デフォルトの名無しさん** · 2021/12/21(火) 08:29:08.29

もっともらしく言ってるけど
新たな枠組みを作ることができるかどうかに
車輪の再発明をする能力は関係ないよ

**デフォルトの名無しさん** · 2021/12/21(火) 08:37:17.38

プログラミングにおいて車輪の再発明すら出来ない人が
プログラミングにおいて新たな枠組みを作るのは無理

**デフォルトの名無しさん** · 2021/12/21(火) 08:59:49.41

ザッカーバーグとかツールレベルでいえばあるもの使ってただけだがな。

**デフォルトの名無しさん** · 2021/12/21(火) 09:42:52.55

クイックソートくらいは自作してみたほうがいい
最初混乱するだろうけど、ああなるほど！となった時に必ず経験値に加算される筈だ

**デフォルトの名無しさん** · 2021/12/21(火) 10:37:29.68

>>128
そりゃ彼はプログラミングにおいて新たな枠組みを作ったわけではないからな

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

新たな枠組みって例えば何？
フレームワークのことではなさそうだけど

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

例えば画像データの取り扱いでbitmapをそのまま処理していたような時代にpngやjpgなどのアルゴリズムをはじめて考え出して
実装したようなプログラマが新たな枠組みを作ることが出来る人
既存のライブラリ使って画像処理や表示のアプリを実装しているようなプログラマが枠組みを使うだけの人

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

もちろん例としてプログラミングのフレームワークでもいいんじゃね？
例えばそのザッカーバーグの例ならば
Facebook社はプログラミングにおいて新たな枠組みとして世間にも広まるほどのReactを作った
一方でザッカーバーグ自体はReactを今から車輪の再発明すらできないしプログラミングにおいて新たな枠組みを作れないだろう

**デフォルトの名無しさん** · 2021/12/21(火) 14:51:21.09

枠組みに限らず何か新しいもの自力で作るには
その対象レイヤーのものを作れる能力は必要
それは当たり前

ザッカーバーグだって掲示板システムを実装する能力があったからFacebookを作れたわけだが
それを「車輪の再発明する能力」と呼ぶのかどうか

「新しい枠組み」と「車輪の再発明をする能力」の定義が曖昧すぎて中身がない

**デフォルトの名無しさん** · 2021/12/21(火) 14:53:33.71

結局のところ
「低レイヤーの開発をするには低レイヤーの実装能力が必要」という主張でしかない

**デフォルトの名無しさん** · 2021/12/21(火) 15:02:25.60

そこは定義でもめるから深入りしない
例えば例に挙げたReactは自分の観点からは低レイヤーではなく高レイヤー
結局これでいいかね？

各分野のプログラミングにおいて車輪の再発明すら出来ない人が
その分野のプログラミングにおいて新たな枠組みを作るのは無理

**デフォルトの名無しさん** · 2021/12/21(火) 16:17:27.88

車輪の再発明って何
自身で模倣できる程度には理解しているということ？

**デフォルトの名無しさん** · 2021/12/21(火) 17:55:52.77

レイヤーは相対的なものだよ
低レイヤーで通じないなら下位レイヤーとでも言おうか

Reactのユーザーから見ればReactそのものの開発は下位レイヤー
Reactを作るために下位レイヤーのJavaScriptエンジンやレンダリングエンジンを再発明できる能力が必要か？

**デフォルトの名無しさん** · 2021/12/21(火) 19:16:57.14

話はシンプル
それぞれの分野で見ればよい

Reactの分野だったら
『自分でウェブフロントフレームワークを簡易なものでよいから作ったことあるか？あるいは作れるか？』
これだけの話

つまりReactの開発者たちと同じような立ち位置に立てるプログラマーなのか、
それともReactの消費者としてユーザーの立場のプログラマーなのか、の違い

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

まとめると
「新しいウェブフロントフレームワークを作るには
ウェブフロントフレームワークを作る能力が必要」

そりゃそうだ
話はシンプルシンプル

**デフォルトの名無しさん** · 2021/12/21(火) 22:16:57.85

なんだよこれ遅っせーなー
意味分かんねーんだよこの挙動
俺のほうがもっとうまく作れる

**デフォルトの名無しさん** · 2021/12/21(火) 23:02:50.37

消費者プログラマーは色んな仕組みをわかっていなかったり理解できなかったりする人が多いね
そうなると車輪の再発明すらできないし車輪の改良もできない
もちろん車輪に代わる新たな仕組みを作り出すこともできない

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

>>138
これ本気で言ってるのか

**デフォルトの名無しさん** · 2021/12/21(火) 23:37:27.40

元の話はmapの実装方法がわからない、だから、もっと深刻な状況なのか
プログラミングする上での基本的なことは
車輪の再発明であろうと自分でやってみて体験していくべき

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

習熟のために必ずしも車輪の再発明が必要であるわけではないでしょ

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

発明する必要はないけど何もないところから自分の力だけで車輪を組み立てられるようにはなっておいた方が良い

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

Cをやるとそういう力が身に付く

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

「フロントフレームワーク」なんて言い方するのかとググったら、まぁまぁ居たわ

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

IPアドレスの正規表現を再発明してるやつがいたけど
ああいうのが"新しい枠組みを作ることも可能な生産者"だったのかw

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

IPアドレスの仕組みも正規表現も別に目新しいものではないのでは？
何か特別な表現手法とかを導入する余地って残されていたか？

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

正規表現とか言ってもただの文字列だからな
数式やアルゴリズムに落とし込めないもので再発明も何も手の出しようがないだろ

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

使ってる言葉を自分なりに定義できないやつは普段物事を深く考えてない
知性の程度を簡単に測れる物差し

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

つまり…？

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

>>151
えっ？
正規表現⊆アルゴリズム
じゃない？

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

正規表現は文字列の集合を表すだけですよ。

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

ある正規言語に対応する文字列やろ

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

ただの検索や置換のためだけのメタ言語だよ
問題記述能力はない

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

問題記述能力？

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

>IPアドレスの正規表現を再発明してるやつがいたけど

再発明って具体的にどういうことやってたことを言っているんだろ

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

そのケースはアルゴリズムではないな
一般的に自分で一から作れる人はその時々に応じて最適なアルゴリズムを見つけ出すだろう

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

何がアルゴリズムで何がアルゴリズムでないか
ちゃんと境界値テストできてる？

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

数式はアルゴリズムなのか？

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

俺がすごいと思ったらすごいというのをいかに客観的評価のように見せるか議論しているようにしか見えない

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

>>163
その通り
ついでに「俺すごい」アピールをしてる

まあ議論には全くなってないがな

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

>>161
一般的には(決定性)チューリング機械で可能な処理のことだけどな。

なので一部の数式(無限大集合とか)は範囲外。

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

無限大を数値計算で扱うために優秀なソフトエンジニア達の手によって、例えば離散フーリエ変換や離散ウェーブレット変換などのアルゴリズムが工夫され考え出された
これが新しい枠組みを作り出すということ

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

無限大の連続量を有限の数値で扱う
フーリエ変換
https://ja.wikipedia.org/wiki/%E3%83%95%E3%83%BC%E3%83%AA%E3%82%A8%E5%A4%89%E6%8F%9B
https://ja.wikipedia.org/wiki/%E9%9B%A2%E6%95%A3%E3%83%95%E3%83%BC%E3%83%AA%E3%82%A8%E5%A4%89%E6%8F%9B

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

>>167
FTは無限大集合を扱っている訳では無いだろ。実数とか扱えないし。

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

周期信号のフーリエ級数展開なら有限だけど連続信号を扱うなら無限積分の計算が必要
FTは無限積分を数値計算するため分割統治のバタフライ演算に落とし込んで更に演算量を抑えるため各種のアルゴリズムが考案されてる

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

で、新しい枠組みを作り出すことが C vs C++ vs Rust にどう関わってくるの

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

枠組みを作ることは凡人には無理
殆どは枠組みを使う人
ただ枠組みの仕組みを知らないと使うことも出来ない

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

最早スレチの話題に突っ込んで悪いけど、無限積分を回避できている気になっているのは気のせいであって、バタフライ演算とか関係ないからね(笑)

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

以前に皆さま方からアドバイスをいただいて
『足し算のみで素数列を生成するジェネリックなイテレータの実装』
を当時O(N^3)という酷さでしたが、このたびほぼ O(N) の新たなアルゴリズムと実装が出来ましたのでご報告します

足し算の総回数を O(N log log N) すなわちほぼ O(N) 近くにすることに成功しました
具体的には 1億(＝10^8) までの素数生成に必要とする足し算の総回数が 2.5億回とリニアになりました
前回と異なりメモ化をしていますがこちらも工夫により配列の長さを O(√N / log N) に抑えることに成功しました
具体的には 1億(＝10^8) までの素数生成に必要とする配列の長さが 1231 と非常に小さな領域のみで実現できました

10^kまでの素数を順に生成時の足し算の総回数 O(N log log N)
10^1　4.70×10^1＝47
10^2　2.03×10^2＝203
10^3　1.90×10^3＝1903
10^4　1.95×10^4＝19508
10^5　2.12×10^5＝212715
10^6　2.27×10^6＝2278220
10^7　2.41×10^7＝24148110
10^8　2.54×10^8＝254082528

10^kまでの素数を順に生成時の配列の長さ O(√N / log N)
10^1　4
10^2　6
10^3　13
10^4　27
10^5　67
10^6　170
10^7　448
10^8　1231

メモリ使用もこの程度の少なさで
足し算を2.5億回とその比較だけで1億までの全ての素数を順に出力できるようになりました
このスレは数学が得意な方々が多いようなのでご検証よろしくお願いします

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

今回は読みやすいようにループで記述しました
impl<T> Iterator for 素数生成Iterator<T>
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　type Item = T;
　fn next(&mut self) -> Option<T> {
　　'次候補: loop {
　　　self.新素数 = self.新素数.checked_add(&T::one())?;
　　　if self.新素数 == self.倍数[self.上限] {
　　　　self.上限 += 1;
　　　　if self.子.is_some() {
　　　　　self.素数.push(self.子.as_mut()?.next()?);
　　　　}
　　　　self.倍数.push(二乗(self.素数[self.上限]));
　　　}
　　　for index in 1..self.上限 {
　　　　while self.倍数[index] != T::zero() && self.倍数[index] < self.新素数 {
　　　　　self.倍数[index] = self.倍数[index].checked_add(&self.素数[index]).unwrap_or(T::zero());
　　　　}
　　　　if self.倍数[index] == self.新素数 {
　　　　　continue '次候補;
　　　　}
　　　}
　　　break;
　　}
　　if self.子.is_none() {
　　　self.素数.push(self.新素数);
　　}
　　Some(self.新素数)
　}
}

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

上述に「子」とあるのはメモリ節約のためのテクニックで
「子」と「孫」を再帰的に利用しているためです
「自分」だけで必要なメモリをNとすると
「子」を利用することでメモリが√Nで済むように設計しました

また、 self.上限が配列の長さで
self.新素数が1億(=10^8)まで進んだ時点で self.上限が 1231 です
self.上限が更新された時のみ、つまり1億までで1231回だけ
コードにあるように以下の二乗する関数が呼ばれます

fn 二乗<T>(n: T) -> T
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　let mut count = T::one();
　let mut result = n;
　while result != T::zero() && count < n {
　　count = count.checked_add(&T::one()).unwrap();
　　result = result.checked_add(&n).unwrap_or(T::zero());
　}
　result
}

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

fn main() {
　assert_eq!(vec![2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79,83,89,97,101,103,107,109,113,127], 素数生成::<i8>().collect::<Vec<_>>());
　assert_eq!(65521, 素数生成::<u16>().last().unwrap());
　assert_eq!(78498, 素数生成::<u32>().take_while(|&p| p < 1000000).count());
}

fn 素数生成<T>() -> 素数生成Iterator<T> where T: Copy + num::One + num::CheckedAdd {
　let 孫 = 素数生成Iterator::<T>::new(None);
　let 子 = 素数生成Iterator::<T>::new(Some(孫));
　素数生成Iterator::<T>::new(Some(子))
}

struct 素数生成Iterator<T> {
　素数: Vec<T>,
　倍数: Vec<T>,
　新素数: T,
　上限: usize,
　子: Option<Box<Self>>,
}

impl<T> 素数生成Iterator<T> where T: Copy + num::One + num::CheckedAdd {
　fn new(子指定: Option<Self>) -> Self {
　　let three = T::one().checked_add(&T::one()).unwrap().checked_add(&T::one()).unwrap();
　　Self {
　　　素数: vec![T::one()],
　　　倍数: vec![three],
　　　新素数: T::one(),
　　　上限: 0,
　　　子: 子指定.map(|子| Box::new(子)),
　　}
　}
}

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

コードは以上です

今回はitertools::unfold()を用いなかったため、それにより省略できていた、
「イテレータ用構造体の宣言」「その初期化」「そのIteratorトレイト実装宣言」
などが今回は必要となりコードがその分だけ長くなっていますが
イテレータの実装本体部分は>>174のみです

足し算の総回数が O(N log log N)　例: 素数を1億までで2.5億回
メモリは配列の長さが O(√N / log N)　例: 素数を1億までで長さ1231使用
これらを足し算のみで実現できています
どうぞご検証よろしくお願いします

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

嫌われ者Rusterのウザウザ全文貼り付け、見るのも嫌になる自己満足オナニー

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

なんかやたら足し算のみで、って強調してるけど、
アルゴリズムはエラトステネスの篩だよね？
そう言ってくれたほうが理解しやすいよ

Rustはまだあんま良くわかってないのでコードは参考になるかも
でもテストケースに127が入ってるのはおかしくない？

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

あ、おかしくなかった
すまん

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

アルゴリズムに興味がある場合はCが読みやすいということがよくわかった

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

1億までの素数を全て求めるのが2.5億回の足し算だけで出来るものなのか？？
メモリもエラトステネスだと1億必要だよな？

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

一億たって100メガにすぎませんからね。

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

>>182
1億回の素数判定を個別に考えると平均2.5回の足し算となりもちろん無理です
そこで過去の判定時で用いた足し算の結果を後の判定時に用いる方法で
結果的に平均2.5回の足し算で済ませています

また、単純にエラトステネスのふるいでは1億の長さの配列が必要となりますが
まず時間と空間を逆転させることで必要となる配列の長さを減らしています
さらに再帰的に子と孫のイテレータを活用することで
>>173の表のように1億(=10^8)まで判定時で配列の長さ1231に抑えています
その時点で子と孫では配列の長さ27となっています

>>183
そんなO(N)のペースでメモリを使用していくのはいずれ限界もありますし
メモリキャッシュヒットの観点からも望ましくないと思います

さらに今回は小さい方から順に素数を返すイテレータです
イテレータ利用者は1億を超えて素数を利用するかもしれませんし
逆にもっと少ない小さい数のみ利用するかもしれません
最初に上限が1億など決まって開始する古典的エラトステネスのふるいでは上手くいかないのです

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

キャッシュヒット率の話するならベンチマークとってくれ

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

わざわざ決まってる数列を順番に出力するイテレータ書くのにそんな記述が必要になるのか
ちょっと普通のループでいいからC言語で書いてみてよ

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

>>185
ベンチマークをとる前に実装が必要だな
その前に新たなアルゴリズムも必要か
エラトステネスの篩は「指定された整数以下の素数を求めるアルゴリズム」だからイテレーターとは相性が悪そうだ

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

イテレータにすると、プログラミングの方向が変わるんですよ。
詳細を未来に先送りできるんです。
伝統ある手続き型の手法では、システムやライブラリを書く人が詳細を実装し、使う人は大まかな指示を出しましたよね。
イテレータ手法は、未来に詳細を決定する。
つまり使う人が細かいことを決める事になるんです。
そこらへんの詳しい話は、書籍クリーンアーキテクチャに載ってます。
この本に書かれてることがすべて正しいとは言いませんが、正しいことにしろ間違ってることにしろ、読んでおいて損はないです。

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

イテレータ特有の話と言うより遅延評価全般の話に読めるが

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

イテレータ万能説を唱えて長文するガチキチおじさんｗｗｗ
yieldはgeneratorをレイトバインド
for(range)はiteratorをレイトバインド
async/awaitはfutrueをレイトバインド
詳細を未来に先送り！キリッｗ

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

>>190
さあご一緒に、キリツ！

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

レイト「バインド」？

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

クリーンアーキテクチャを出してるから遅延評価のことじゃなく
IoCの一例としての高階関数のことを言いたいんじゃないかな？

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

昔は局所化して先送りにできることは素晴らしいことだと思ってた
でも最近そんなのは些末な事で、無能な働き者が気にすることだったなと考えを改めた
木を見て森を見ずと言うべきか

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

>>188
ある意味その考え方も正しいかもしれませんが
イテレータは例えば大ざっぱに分けても5種類はあるので
自分が作る部分がどの部分かによってその立場も変わると思います
(1) 発信イテレータ … >>174で示しました素数生成、レンジ(0..n)、配列やVecに対するiter()などチェーンでは先頭に来るもの
(2) 仲介イテレータ … map()、filter()、enumerate()などチェーンでは中間に来るもの
(3) 受信イテレータ … find()、fold()、collect()などチェーンでは最後に来るもの
(4) 合成イテレータ … chain()、zip()、merge()など複数のイテレータを入力とするもの
(5) 創造イテレータ … unfold()などイテレータを生み出す汎用イテレータ
とりあえず(4)(5)は置いとくにしても自分が作る部分は用途によって(1)か(2)か(3)と変わるため大きく立場も異なります

>>189
一般的に遅延評価による先送りといえば主役はクロージャですね
上述したイテレータを作り出すunfold()もクロージャを渡すことで成立しています

>>190
futureは「未来に先送り」ではなく「未来を先取り」と捉えたほうがよくないでしょうか
そして遅延評価というよりも並行並列評価する形になりますね
したがって今回の話には適さないかなと思います

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

>>186
> わざわざ決まってる数列を順番に出力するイテレータ書くのにそんな記述が必要になるのか

決まってる数列ではなく毎回算出するんですよ
記述については各々のイテレータはそれぞれ何らかの構造体にすぎないので >>176に示しましたように
「(a) イテレータとなる構造体の型宣言」「(b) その構造体の初期値定義 new()」「(c) 今回は自分と子と孫がいるためその関係記述」
があってようやく、>174に示しました「(d) イテレータ自体の毎回の算出コード」がそこに加わります
一般的にも今回の特殊な用途(c)を除いた3つ(a)(b)(d)は必要です
さらに>>195でいうところの仲介型イテレータはそれらの記述に加えて
「(e) 他のイテレータのメソッドとなりチェーンできるようにするための宣言」がさらに必要となります

上述(a)(b)(d)の部分の記述だけならば
お手軽にイテレータを生成できる itertools::unfold() を使えるケースだと
例えばフィボナッチ数列を返すジェネリックなイテレータは
以下のように初期値と処理クロージャを1つunfold()に与えてやればイテレータを作れます

fn fibonacci<T>() -> impl Iterator<Item=T>
　where T: Clone + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialEq,
{
　itertools::unfold((T::one(), T::one()), |(m, n)| {
　　if *m == T::zero() {
　　　// overflow
　　　return None;
　　}
　　// shift: ret <- m <- n <- next
　　let next = m.checked_add(&*n).unwrap_or(T::zero());
　　let ret = m.clone();
　　*m = n.clone();
　　*n = next;
Some(ret)
})
}

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

>>185
そのためにもぜひ異なるアルゴリズムの実装を作ってくださるとベンチ比較できますね
いまのところ足し算で素数生成するイテレータの実装は以前に作った明らかに非常に遅い>>62と
今回作った動作O(N log log N)でメモリ使用量O(√N / log N)となる>>174の2つしかないのです

>>187
そうなんですよ
エラトステネスのふるいは最初に上限数を指定するためそのままではイテレータと相性がよくないです
またメモリ使用量も大きくなってしまいます
そのため試行錯誤のうえ新たなアルゴリズムが生まれたのが今回の実装です
もっと良い方法を考えついた方は教えていただけるとうれしいです

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

より良い方法に興味があるんなら、普通に既存実装を研究してみたらいいんじゃない？
例えばRubyの標準添付ライブラリにも Prime.each があるよ
ソースはここ https://github.com/ruby/prime

おれはそこまで素数のアルゴリズム自体には興味ないから考えないけど

**デフォルトの名無しさん** · 2021/12/25(土) 01:08:34.65

>>197
CかC++で書いて

**デフォルトの名無しさん** · 2021/12/25(土) 04:20:39.50

C/C++/Rustならどの言語も理解できないほどの特異な書き方や奇妙な省略もなくどれも似たようなもんだ
どれか一つで書かれていれば普通のプログラマーなら読めるだろう
それでもわからない部分があれば質問したら皆が教えてくれるぞ