Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

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

公式ドキュメント
https://www.rust-lang.org/learn

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

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

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

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

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

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

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/10/20(日) 18:20:10.46

>>406
もともとの話が>338（1,2,が同じことを言っているのか別のことを言っているのか）の話なんだから，その文脈での"関数"だよ．

> 「型無の関数型(言語)」の意味が通じてなさそうだからわざわざ言い直してるんじゃない？
「意味が通じてなさそう」とか言われても，「型無の関数型」自体が>387初出だから．>372に対してではなく自分に対して言い直しているのかしらん？

>407
できるのね．ありがとう．
そろそろ苦情が出てるしレスやめるわ．

**デフォルトの名無しさん** · 2024/10/20(日) 18:26:43.67

カリー化してxsを見た目上消すのは関数を返すとみなせる。

f mf f = mf f

**デフォルトの名無しさん** · 2024/10/20(日) 18:27:17.94

あいよ

**デフォルトの名無しさん** · 2024/10/20(日) 18:37:12.50

実現方法はキャプチャしたクロージャとかでもいいんだろ
他にも構造体とそれ用のメソッドを用意する形でも実現できる
関数という名に囚われて関数自体を返さなければいけないわけではない

**デフォルトの名無しさん** · 2024/10/20(日) 23:14:31.47

>>406
そりゃねえ、関数型言語の定義の議論をしているところにいきなり「型無の関数型(言語)がありえる」なんてのを
根拠に持ち出したら意味が通じないわ。

**デフォルトの名無しさん** · 2024/10/21(月) 09:54:32.14

もう病気の類なんじゃないのかなこの人は
アスペを認めるとザワザワして発狂してしまうの？

**デフォルトの名無しさん** · 2024/10/21(月) 14:02:30.37

>>392
話の流れは追ってないけど、東大文系学科中退のホリエモン、
(もともと所属学科が存在しない)ハーバード大で法律と数学
の単位を取って中退したビルゲイツと、Fラン大学でcs学科
専攻した人を比較するのはおかしいと思うな。

**デフォルトの名無しさん** · 2024/10/21(月) 22:09:07.40

>>378
パターンマッチ有り無しとか些末すぎる
lispマクロがなぜ強力なのかを理論的に説明できないやつは関数型言語が何かを理解できてない

**デフォルトの名無しさん** · 2024/10/21(月) 22:49:21.88

>>415
Lispのマクロは健全なマクロ(hygienic macro)ではない

**デフォルトの名無しさん** · 2024/10/21(月) 23:05:26.66

>>415
Lispではコードもデータも全部同じS式なので
S式で書かれたコード片をそのままデータとして扱えるから
というのがLispのマクロが強力な最大の理由

でもこれは関数型の話とはあまり関係と思う

**デフォルトの名無しさん** · 2024/10/22(火) 00:53:30.71

>>415
lispマクロと関数型言語は関係なくね？

**デフォルトの名無しさん** · 2024/10/22(火) 02:07:57.31

>>417
それがあのシンプルな言語仕様で実現できるのはラムダ計算を計算モデルに持つから
それが関数型言語のパワーを端的に表している

**デフォルトの名無しさん** · 2024/10/22(火) 06:02:08.36

>>415
lispマクロってCommon-Lispのマクロだよね？
SchemeやarcなどLisp系にも色々あるのに、Common-LispがいかにもLisp全体であるかのように言わないでいただきたい。

**デフォルトの名無しさん** · 2024/10/22(火) 21:51:40.07

ここはLispスレ？

**デフォルトの名無しさん** · 2024/10/22(火) 21:54:55.10

はい、そうです

**デフォルトの名無しさん** · 2024/10/22(火) 21:59:52.45

>>416
その点Rustは健全なマクロ(衛生的なマクロ)だから優れてるな

**デフォルトの名無しさん** · 2024/10/22(火) 22:50:58.38

>>419
ラムダ計算をベースとしてるのはLispに限った話じゃないので
Lispのマクロが他に比べて強力な理由にはならないよね？

**デフォルトの名無しさん** · 2024/10/22(火) 23:33:18.43

ラムダ計算が計算モデルに持つとは、例えば自然数やcons cellなどの値がすべてチャーチエンコーディング等の手法を利用してラムダ項による表現を持つという意味でしょうか
不可能ではないかもしれませんが、esolang以外ではあまり聞きませんな

**デフォルトの名無しさん** · 2024/10/23(水) 00:17:49.94

型無しのラムダ計算だと
|f| f(f)
で自分に自分を渡すみたいな気持ち悪い事ができるけど
一般的な関数型言語の型付きラムダ計算だと無理なんだよね

macro_rules! combinator { ($f:expr) => { ($f)($f) }; }
とかしてもコンパイルできるcombinator!(f)が存在しないはず
何か裏技あるかもしれないけど

**デフォルトの名無しさん** · 2024/10/23(水) 00:50:41.84

>>426
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4e875602eb434b87811e7f8043069df1

別に裏技っぽいことは何もいらないが……

**デフォルトの名無しさん** · 2024/10/23(水) 00:54:14.76

>>423
健全なマクロは健全にしか出来ないんだよ。
意図的に衝突させるという自由は奪われる。
普通にしてたら健全なマクロになりつつ必要なときにはそうじゃない選択もあって欲しい。
健全なマクロが優れているということはない。
状況による。

**デフォルトの名無しさん** · 2024/10/23(水) 01:19:20.88

>>428
常に健全なマクロが優秀
https://ja.wikipedia.org/wiki/%E5%81%A5%E5%85%A8%E3%81%AA%E3%83%9E%E3%82%AF%E3%83%AD

**デフォルトの名無しさん** · 2024/10/23(水) 08:51:56.69

>>429
そういうなら根拠を提示しなよ

**デフォルトの名無しさん** · 2024/10/23(水) 09:46:54.15

まあ「コーダーのミスを許さない」というRustのコンセプト的には、余計な束縛をしない健全マクロのほうがビックリネタ減るわな。

**デフォルトの名無しさん** · 2024/10/23(水) 12:28:40.45

>>430
健全なマクロが優秀である根拠は>>429で示した

**デフォルトの名無しさん** · 2024/10/23(水) 12:55:59.93

>>427
macro_rules! combinator { ($f:expr) => { ($f)($f) }; }
↓
macro_rules! combinator { ($f:expr) => { (($f)($f)) }; }
にしないと抜け道があるなｗ
これだからマクロは苦手

**デフォルトの名無しさん** · 2024/10/23(水) 13:44:18.19

>>433
変えても何も変わらないし、関係ない
マクロで定義してるこのcombinatorを関数にして型を付けようとすると、Haskellで言うRank2Types拡張相当のリッチな型が必要で、それは必ずしも「一般的な関数型言語の型」ではないという話なら分かる

**デフォルトの名無しさん** · 2024/10/23(水) 14:16:45.58

>>423
proc_macro2 は

**デフォルトの名無しさん** · 2024/10/23(水) 15:08:29.40

>>432
書かれてないぞ。
どの部分のことを言ってる？

**デフォルトの名無しさん** · 2024/10/23(水) 15:49:07.30

お前らなんか作ってんの？

**デフォルトの名無しさん** · 2024/10/23(水) 18:08:14.82

身バレするから詳しいことは言えないんだ。
匿名前提のコミュニティの制約だからしょうがない

**デフォルトの名無しさん** · 2024/10/23(水) 20:22:42.34

>>428
Rustのmacro_rulesで宣言されるマクロは健全なマクロだけど
敢えてローカルスコープでマクロ宣言すれば不健全にローカル変数をそのまま使えるため両対応しているよ

>>435
手続きマクロは解析木を入力に自在だね

**デフォルトの名無しさん** · 2024/10/23(水) 22:12:20.50

>>426
untypedのラムダ計算をベースにしてる言語は
Lispだけでも関数型の言語だけでもないよね

>>415で言ってたLispのマクロが強力さっていうのは
Lisp特有の話じゃなかったってことでいいのかな？
だとしたら俺の考える強力さとは違ってた

**デフォルトの名無しさん** · 2024/10/24(木) 07:52:11.99

>>440
ASTを生成するコードを作れるのは大抵強力だろ。
全然別のアプローチとしてFORTHのIMMEDIATE POSTPONEみたいなのもあるけど。

**デフォルトの名無しさん** · 2024/10/24(木) 10:38:00.79

>>441
>ASTを生成するコードを作れる
若干意味が曖昧だけどASTをいじれれば強力ということなら
それはLispに限らないし関数型言語にも限らないので
関数型言語や関数型の定義との関連は薄い

**デフォルトの名無しさん** · 2024/10/24(木) 10:45:57.96

Rustは、ASTを使ったマクロが書けるということみたいですが、
それについて詳しい書籍は有りませんか？

**デフォルトの名無しさん** · 2024/10/24(木) 11:20:06.71

AST操作ができるという意味では、Lispマクロと同等の能力を持つマクロを持つ言語は他にもあれど
AST自体がS式で非常に簡潔だからマクロを書くために追加で学習する事項はほとんどないし、言語実装側もかんたん、というのがLispマクロの特色と言えるかもね

**デフォルトの名無しさん** · 2024/10/24(木) 11:46:01.90

>>443
本は知らんけどネットの情報だけで充分に学習出来た(経験談)

**デフォルトの名無しさん** · 2024/10/24(木) 12:02:07.13

>>443
本じゃないけどdtolnayのprocedural macros workshop
本ならManningのマクロ本

**デフォルトの名無しさん** · 2024/10/24(木) 14:32:18.09

>>442
だからそういうことでしょ。

マクロは関数型言語・関数型プログラミングと直接関係無いし、Lispマクロが強力なのはASTを直接操作するメタプログラミングだからであって関数～～と直接関係無い。

**デフォルトの名無しさん** · 2024/10/24(木) 16:46:48.00

昔CommonLispでゲームサーバーとか作ってたけどね。マクロ書くのが楽なのは良かったね。
どちらかというと稼働中なサーバー止めずに関数単位でビルドできるとか型を指定して最適化しやすいってのがいい所だったけど真っ当なlispはAllegro　Commom Lisp ぐらいしかないし、高くて勧められない。
今はもうrustの方が圧倒的に便利だし、マクロも必要十分と思ってる。s式だけに拘る理由はないよ。

**デフォルトの名無しさん** · 2024/10/24(木) 17:02:46.99

マクロで抽象度高めるのはいいけど、やりすぎると自分以外に分からないDSLになる。程々でいいのよ。
Rustは頑張ればなんでも書けるマクロがあるけど、クレート分けたりちょっと面倒なんで程々で収まる。素人が手を出さない。ライブラリ作るような人だけ頑張ればいいの。

**デフォルトの名無しさん** · 2024/10/24(木) 17:49:54.17

乱数が標準ライブラリーで使えないなんて言語ある？

**デフォルトの名無しさん** · 2024/10/24(木) 18:03:21.93

>>450
RandomStateが標準ライブラリにある
用途が極少数ならそのまま使ってもよい
用途が多数なら枯渇するためシードとして用いる
シードからの生成アルゴリズムはその性質に応じて無数にあるため標準ライブラリの対象外

**デフォルトの名無しさん** · 2024/10/24(木) 19:26:04.63

>>451
RandomStateで乱数生成やったことないんだけど具体的にどうやるの？

**デフォルトの名無しさん** · 2024/10/24(木) 19:51:11.78

use std::hash::{BuildHasher, RandomState};
let random_seed: u64 = RandomState::new().hash_one(0_u64);
あとはこのシードからお好みのアルゴリズムで生成

**デフォルトの名無しさん** · 2024/10/24(木) 20:30:14.64

>>453
結局標準ライブラリでは乱数生成できないってことね、OK

**デフォルトの名無しさん** · 2024/10/24(木) 20:46:28.29

>>454
乱数値を得られていることを理解できない？
シードは乱数値
別のものだと思った？

**デフォルトの名無しさん** · 2024/10/24(木) 21:26:15.04

いやシードと乱数は違うでしょ
「テスト用の適当な数値が欲しい」くらいの用途には使えないこともないけど

**デフォルトの名無しさん** · 2024/10/24(木) 21:35:49.51

理解できない人向けにどうぞ
use std::hash::{BuildHasher, RandomState};
let random_value: u64 = RandomState::new().hash_one(0_u64);
ここで得られる値は乱数値

(シード値としても使えることを書いただけで混乱して理解できなくなる人がいるとは想定できずにごめんね)

**デフォルトの名無しさん** · 2024/10/24(木) 22:02:47.28

さすが複オジクオリティw

>>454
素直にrand使ってね

**デフォルトの名無しさん** · 2024/10/24(木) 22:11:35.63

そんなんでごまかせるわけないだろｗ
ワロタ

**デフォルトの名無しさん** · 2024/10/24(木) 22:18:39.07

>>457で得られる値はgetrandomシステムコールや/dev/urandomから得ているので正真正銘の乱数値

**デフォルトの名無しさん** · 2024/10/24(木) 22:40:22.29

なんでこの程度の内容で議論が発生して第三者の解説が必要になるんだよ

**デフォルトの名無しさん** · 2024/10/24(木) 22:41:20.63

なんかnightlyにあったわ、つい最近のやつじゃん
そのゴミ生成器片付けとけよ

https://doc.rust-lang.org/nightly/std/random/index.html
https://github.com/rust-lang/rust/issues/130703

**デフォルトの名無しさん** · 2024/10/24(木) 22:52:15.99

Rustの標準ライブラリはHashMapなどで使われる安全なハッシュをサポートするために各OS環境から正真正銘の乱数を得ていてそれが>>457

**デフォルトの名無しさん** · 2024/10/25(金) 01:03:47.43

>>462
これまで、標準ライブラリで乱数をサポートしないのがRustらしさだと擁護してきた信者の気持ちを踏みにじるような機能追加だな

**デフォルトの名無しさん** · 2024/10/25(金) 01:53:32.00

>>464
あれはただの現状追認主義者だから、今日以降同じことを聞かれたら何食わぬ顔でstd::randomがnightlyにあるぞと言い始めるんだろう
まったくくだらない手合いだ

**デフォルトの名無しさん** · 2024/10/25(金) 02:10:41.48

それが複オジクオリティw

**デフォルトの名無しさん** · 2024/10/25(金) 11:31:42.20

Rust信者はRustが素晴らしいという前提から出発しているから、どんな現状でも追認するしかないんだよね

**デフォルトの名無しさん** · 2024/10/25(金) 11:40:01.29

信者てここには一人しかおらんやん
乱数とハッシュ値の違いも分からん信者wだけど

**デフォルトの名無しさん** · 2024/10/25(金) 20:43:07.49

iOS/Androidに対応した「Tauri 2.0」が公開～「Rust」が使えるアプリフレームワーク
https://forest.watch.impress.co.jp/docs/news/1628498.html

**デフォルトの名無しさん** · 2024/10/25(金) 21:10:43.49

くやしいのうｗくやしいのうｗ

**デフォルトの名無しさん** · 2024/10/25(金) 22:12:28.52

話題を変えて無かったことにして欲しいらしいw
追い裏金の話を闇バイト強盗の話で誤魔化そうとしてもダメだろ～

**デフォルトの名無しさん** · 2024/10/25(金) 22:52:21.52

>>454
できる
デフォルトハッシャーでも使っている

**デフォルトの名無しさん** · 2024/10/25(金) 23:39:25.27

乱数は用途によって必要な性質が違うのであまり標準に入れて欲しくないが
インターフェイスは標準で決めて欲しいとは思う。

**デフォルトの名無しさん** · 2024/10/25(金) 23:45:41.75

乱数を標準ライブラリに入れてない頭おかしい言語って他にもあるの？

**デフォルトの名無しさん** · 2024/10/26(土) 00:10:22.27

あっても使い物にならないのとかあるしなぁ。
ECMAScript (JavaScript) とか C とかの乱数は使いものにならないから実質的に無いのと同じだし、意味のないものを入れるくらいなら入れないほうがマシ。

**デフォルトの名無しさん** · 2024/10/26(土) 00:22:27.42

>>474
言語仕様に書かれていないという意味では、メジャーな言語で言えば Haksell とか Scheme とか。
「標準ライブラリ」というのがどこまでの範囲を指すかにもよるので微妙な話だが。

警備員[Lv.4][新芽] · 2024/10/26(土) 00:32:15.24

本当に頭のいい人たちが検証を重ねて世に送り出したモノが使い物にならないとはどういうところを言うのですか?

**デフォルトの名無しさん** · 2024/10/26(土) 00:44:55.37

本当に頭のいい人たちが検証を重ねて世に送り出したモノではないというところですね……

警備員[Lv.4][新芽] · 2024/10/26(土) 01:00:53.03

そう言う自分も、無批判には使わずに一様性を検定するなどしてから使うけど、信頼してないからではなく

**デフォルトの名無しさん** · 2024/10/26(土) 02:13:26.68

>>473
同意

**デフォルトの名無しさん** · 2024/10/26(土) 08:44:00.93

>>476
言語仕様と標準ライブラリの区別もつかんのかーいw

言語仕様に乱数生成ライブラリの定義がある方がむしろ珍しいだろ

**デフォルトの名無しさん** · 2024/10/26(土) 10:04:40.94

>>481
標準ライブラリは言語仕様と不可分だ。
規格に書いてあるか、公式に standard library という用語で呼んでいるのが標準ライブラリだと考えている。

ただ、変な経緯を持つものや事実上の標準のように扱われるものはあるから……。
C++ では STL (Standard Template Library) は言語仕様に取り入れられる前から STL と名乗ってた。

Haskell や Ruby のように特定の処理系が一強の場合は規格を論じるのがあまり意味ない場合もあるし。

**デフォルトの名無しさん** · 2024/10/26(土) 10:53:28.94

>>469
Tauriはゴミ

**デフォルトの名無しさん** · 2024/10/26(土) 11:44:59.52

Rustはライブラリをあまり取り込まない方針じゃなかったっけ？
変わったの？

**デフォルトの名無しさん** · 2024/10/26(土) 12:24:14.18

>>482
言語仕様と標準ライブラリ仕様の区別がついてないだけでなく規格と言語仕様の区別もついてないんだな

**デフォルトの名無しさん** · 2024/10/26(土) 12:27:05.83

>>473
物凄い支離滅裂な主張に感じるのは俺だけか？

**デフォルトの名無しさん** · 2024/10/26(土) 12:34:35.45

>>484
Rust の標準ライブラの基礎理念はエコシステムの基盤として最小限かつ実践的であること。
肥大化させるのは良くないが、だからといって有用なものまで避けたりはしない。

常識的に考えて主要なデータ構造は標準ライブラリに入れるし、
ハッシュテーブルのハッシュには乱数を使う (いわゆるソルト) のでどうせならそれをユーザ向けに公開したってよかろうという感じ。
RandomState が std::hash の下にあるのはそういうこと。

ハッシュをかき乱す要素を入れないと意図的にハッシュが衝突するデータを入力する攻撃が成立する可能性があるので、
それを避けるために乱数を混ぜ込むものなんだよ。

**デフォルトの名無しさん** · 2024/10/26(土) 12:36:36.70

>>485
区別を付けてるから言葉を使い分けてる。

**デフォルトの名無しさん** · 2024/10/26(土) 12:43:45.54

>>486
Rust ならライブラリのインターフェイスはトレイトの形で決められるだろ。
トレイトを標準ライブラリとして用意して実装は外部のクレートに任せればよいという意味だが、なんか不自然なところある？
スレッド関係とかはそうなってるのもあると思うが。

**デフォルトの名無しさん** · 2024/10/26(土) 12:58:01.15

>>489
スレッド関係というのは具体的にはFutureのことか？
あれはasync/awaitのために必要だけど、今のところ乱数にはそれと同レベルの必要性はないじゃろ

**デフォルトの名無しさん** · 2024/10/26(土) 14:44:24.24

>>487
ハッシュテーブルのハッシュにソルト必要か？

**デフォルトの名無しさん** · 2024/10/26(土) 15:08:22.43

saltは乱数ではないよ

**デフォルトの名無しさん** · 2024/10/26(土) 21:33:32.55

乱数は2種類ある
1つは擬似乱数で与えられたシード(初期値)から出発して各アルゴリズムで順に生成していく
同じシードなら同じ生成列になってしまい時刻情報などをシードとして用いても推測されると生成列がバレてしまう
そこでもう1つの自然乱数をシードとして用いることで問題を解決できる
この自然乱数は計算ではなく外部のエントロピーなどから得る
これは各OS環境などでバラバラに提供されている

**デフォルトの名無しさん** · 2024/10/26(土) 21:36:01.18

Rustがstd::randomで提供しようとしているのは擬似乱数ではなく自然乱数の方
もちろん自然乱数も様々なものが使える環境もあるためtrait RandomSourceを用意している
そして各環境毎に標準的に使えそうな実装をDefaultRandomSourceとして提供している

**デフォルトの名無しさん** · 2024/10/26(土) 21:40:12.79

つまり擬似乱数の各アルゴリズムを実装しているクレートなどの本体部分はこれまで通り
それらの中でシードのために利用する自然乱数の取得を各環境別に書いていた部分がstd::randomを利用できるようになる
このために自然乱数の提供を標準ライブラリに入れようとしている

**デフォルトの名無しさん** · 2024/10/26(土) 21:43:58.25

ちなみにHashDos攻撃を避けるために標準ライブラリのHashMapは以前から自然乱数を利用するコードとなっている
そのため我々は以前から>>457のコードの形で現行の標準ライブラリでも自然乱数を間接的に得ることができる
いずれstd::randomが安定化すると自然乱数を直接的に得られるようになる

**デフォルトの名無しさん** · 2024/10/26(土) 22:18:58.17

今日一日勉強した成果がこれかぁ

>>493
前半の話はPRNG(deterministic)とCSPRNG(unpredictable and non-deterministic)の違いで
PRNGのシードもほとんどのケースは自然乱数(真の乱数)ではなくCSPRNGを使った疑似乱数

>>494
std::randomが提供しようとしているのはCSPRNGだけでなくPRNGも検討されている
https://github.com/rust-lang/rust/issues/131606

つまり…
>>495の結論は間違いだらけ
がんばれ～

**デフォルトの名無しさん** · 2024/10/26(土) 22:23:14.55

長々と書いてるがやっぱりまだ「シード＝乱数値」と思っていそうな、それを再確認するためにチェリーピッキングしたフシがあるように読めるな……

>>496
https://doc.rust-lang.org/src/std/hash/random.rs.html#67
RandomState::newで「自然乱数」を読むのはTLSにあるKEYSを初期化するときただ1回きりなのだが、それは特に問題だと思っていないという認識で良いか

**デフォルトの名無しさん** · 2024/10/26(土) 22:37:43.22

>>498
自然乱数ではないのは>>497で書いた通り

HashDos対策的にはHashMap等の各インスタンスにつき1回しか読まないので十分
それに複数回読んだら同じ入力値に対してハッシュ値が変わるのでHashMapが機能しなくなる

**デフォルトの名無しさん** · 2024/10/26(土) 22:46:16.13

>>499
？？？
あんたには聞いてないし、何から何まで間違っとるよ

**デフォルトの名無しさん** · 2024/10/26(土) 22:56:45.07

>>497
その決めつけはおかしいな
自然環境ノイズに基づく自然乱数が得られる環境では自然乱数が使われているよ
例えばLinuxやMac含めてUnix系ならば/dev/randomと/dev/urandomやシステムコール化したgetrandomがあり
Rustでも用いているよ

**デフォルトの名無しさん** · 2024/10/27(日) 02:58:36.94

>>501
getrandomはハードウェアから得られた値を直接返してるんじゃなく
それらをシードにして生成した疑似乱数を返してるんだよ

**デフォルトの名無しさん** · 2024/10/27(日) 09:03:06.72

そもそも外部のエントロピーで自然乱数列を生成出来るなら
わざわざそれをシードにして別の自然乱数列を造る必要無くね？

**デフォルトの名無しさん** · 2024/10/27(日) 11:20:29.17

crates古いのしか無いと不安になるなω
sfmt 3年前
mersenne_twister (github dcrewi) 7年前
mersenne-twister (github mztikk) 1年前
rand_mt 数ヶ月

**デフォルトの名無しさん** · 2024/10/27(日) 12:31:48.22

>>503
randomあたりのman

**デフォルトの名無しさん** · 2024/10/27(日) 14:02:01.43

自然乱数はランダムになるまで時間がかかるからな
短い間に何度も乱数が欲しいような時には使えない

**デフォルトの名無しさん** · 2024/10/27(日) 16:44:26.48

酷いスレだなあ