Rust part18

**デフォルトの名無しさん** · 2022/12/10(土) 18:17:02.61

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

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 part17
https://mevius.5ch.net/test/read.cgi/tech/1665063793/

**デフォルトの名無しさん** · 2022/12/12(月) 02:09:06.83

冗談きついな、別室で頑張ってね

**デフォルトの名無しさん** · 2022/12/12(月) 02:11:40.12

それおちょくってるのか、そういう組織があるとマジで思ってるのか、どつち？

**デフォルトの名無しさん** · 2022/12/12(月) 02:14:41.40

>それおちょくってるのか、そういう組織
リスクの話をしている。おちょくりでもマジでもない

**デフォルトの名無しさん** · 2022/12/12(月) 02:15:18.25

レピュテーションリスク

**デフォルトの名無しさん** · 2022/12/12(月) 02:16:26.89

実態通りのレピュテーションが重要

**デフォルトの名無しさん** · 2022/12/12(月) 02:17:58.12

スレのみなさま、ごめんなさい
>>33は正しい
おやすみなさい

**デフォルトの名無しさん** · 2022/12/12(月) 02:20:53.27

そうか、スレ立て人だったか。バイバイ、面白かったよ、別室で頑張ってね

**デフォルトの名無しさん** · 2022/12/12(月) 02:26:04.34

成果を数値化した側は誤解を招き、リスクを数値化しようともしない側が数学的に優位なのはまあ分かる
3.14よりもπの方が誤解がないのと同じ

**デフォルトの名無しさん** · 2022/12/12(月) 02:28:14.68

あらら、キャラ召喚してるじゃんw

**デフォルトの名無しさん** · 2022/12/12(月) 02:58:18.77

>>33
今回に関しては全く必要なかった
2つNGにしたら33の次は85にw
複オジじゃないからNGしやすくて助かる

**デフォルトの名無しさん** · 2022/12/12(月) 03:05:27.82

そりゃどうも

**デフォルトの名無しさん** · 2022/12/12(月) 03:07:58.75

85もキャラ変しただけだからNGしときな。

**デフォルトの名無しさん** · 2022/12/12(月) 06:07:39.15

>>85
15倍の誤差だからπ=47.12って言う大暴投だからな

**デフォルトの名無しさん** · 2022/12/12(月) 06:51:30.97

深夜のレスバトルが興味深くなる見方、そして消えぬ複オジ軍団説

普段はまともぶってる放り投げキャラ？>>26がつつかれたら、速攻で複オジが出て来た
とにかく複オジは文書(翻訳)と仕様マウントが大事

放り投げキャラは次世代スレのwasmリソースコストおじ→複数人説

>>77が自演の決定的ボロなのか、あるいは監視引き継ぎミスなのか
引き継ぎミスなら→複数人説

しかも>>85がポエオジという可能性→複数人説
更にレスバトルが複オジじゃないと収拾したい>>87の登場

そういう目で見たらそう見える

**デフォルトの名無しさん** · 2022/12/12(月) 07:35:06.40

>>91
いまいち

ミスではなく>>76が引き継ぎの瞬間で
同一人物を装うために>>77を入れてる
という見立ての方が断然面白いでしょ

**デフォルトの名無しさん** · 2022/12/12(月) 07:35:25.61

自称集団ストーカー被害者の供述と同じ

**デフォルトの名無しさん** · 2022/12/12(月) 07:49:30.92

引き継いだら即幕引き、その理由は？
>>79-80
でバトルの必要が無いと判断出来た
という見立てのが面白い

**デフォルトの名無しさん** · 2022/12/12(月) 16:49:32.11

Fedora37のLinux KernelがVer.6.0になってたから新機能なんだろってググったら6.1から遂にRustサポートされるんだね

**デフォルトの名無しさん** · 2022/12/12(月) 23:25:53.54

このスレ捨て捨てよ

**デフォルトの名無しさん** · 2022/12/13(火) 22:51:58.96

Android12のtokeiしたぞ計算は自分でやれ
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
Assembly 10 1835489 1776138 61 59290
GNU Style Assembly 511 698434 666001 20331 12102
C 2269 858479 652278 119729 86472
C Header 20347 4528431 3057716 1023059 447656
C++ 17900 9289538 7491429 858792 939317
C++ Header 305 157423 120050 11387 25986
Go 805 271377 201441 35705 34231
Java 57305 14796003 9709131 3245016 1841856
JavaScript 91 25468 20400 2951 2117
Kotlin 1833 319017 225519 58641 34857
Python 3721 933286 747682 79727 105877
TypeScript 231 680201 536363 142914 924
-------------------------------------------------------------------------------
Rust 203 47094 38569 3786 4739
|- Markdown 148 4044 13 3696 335
(Total) 51138 38582 7482 5074
===============================================================================
Total 105531 34440240 25242717 5602099 3595424
===============================================================================
externalの名前が実態に同意だしそもそもexternal内はダブルカウントが多発している

**デフォルトの名無しさん** · 2022/12/13(火) 23:23:57.37

もっとGoがフィーチャーされてもいい

Rust 0.27%(Android13)
Rust 2.19%(rust増減/全体増減)
Rust 6.25%(rust増減/native増減)

Go 0.94%(Android13)
Go 3.14%(go増減/全体増減)
Go 8.97%(go増減/native増減)

native(C/C++,go,rust,asm)

**デフォルトの名無しさん** · 2022/12/13(火) 23:30:32.49

相関で言うと、致命的バグが減ったのはGoが増えたおかげ

**デフォルトの名無しさん** · 2022/12/13(火) 23:37:00.82

GoはNSA公認の安全志向言語だからね

**デフォルトの名無しさん** · 2022/12/14(水) 01:02:52.63

我が軍のリターンと我が軍のリスクを比較するべきで
味方のリターンと競争相手のリターンの差をカイゼンさせようとするのは合理的ではないと思う

**デフォルトの名無しさん** · 2022/12/14(水) 01:14:31.36

最初から違和感があると思っていたが
元記事ではGoが何故か除外されてる

ストーリー構成に不都合だったのか
相関だと何とでも言えるんだね

**デフォルトの名無しさん** · 2022/12/14(水) 01:27:29.73

>>101
良くないね、堂々と数字のカラクリを肯定するとは

**デフォルトの名無しさん** · 2022/12/14(水) 01:56:11.07

>>101 我が軍
こいつ遂に開き直って複おじ複数人疑惑を隠さなくなった
引き継ぎは2時？

裏舞台でこそこそしてろよ、表舞台に出て来るんじゃないぞ

**デフォルトの名無しさん** · 2022/12/14(水) 06:45:32.23

>>102
元々C/C++のメモリー障害の話なので低レイヤーで使えないGoを対象外にするのは当たり前だと思うぞ
>>98 の native(C/C++,go,rust,asm) もどう言う根拠でGo入れてるのかよくわからん、Go入れるならJavaが入らない理由を示してほしい

**デフォルトの名無しさん** · 2022/12/14(水) 07:01:51.79

ストーリーの無い生データを見た実際のところ、バグデータのある期間(~android12)でのRustは高々0.13%しか無い
C++の検証ツール類の活用だったりGo活用だったりの方が圧倒的に貢献していると考えるのが普通
他言語の成果を横取りしてる印象を持ったし、データを見たマの反発を買うのも当然

**デフォルトの名無しさん** · 2022/12/14(水) 07:15:30.66

>>105 ...の話なので...
>>105 = 放り投げ常習犯のRustカラクリストーリー君

**デフォルトの名無しさん** · 2022/12/14(水) 07:40:22.86

>>106
ほんとこの通りだわ
今回みたいに1.5Mの疑義が出て数字を掘られなければ、メモリバグ削減はRustの成果だと信じ込まされた訳だし、恐ろしいわ

**デフォルトの名無しさん** · 2022/12/14(水) 08:29:54.62

>>107
カラクリだと言うならせめて
> >>98 の native(C/C++,go,rust,asm) もどう言う根拠でGo入れてるのかよくわからん、Go入れるならJavaが入らない理由を示してほしい
ぐらいには回答しなよ

**デフォルトの名無しさん** · 2022/12/14(水) 08:46:08.12

あのね、さすがにもう、原文の脚色を軸にした議論に価値は無い
>>109
Goを蹴落としたいだけの言いがかりになるからやめたほうがいい

1.5Mの数字もちだして来たのどうせ>>105,109なんだろうし、この際言っておくけど、

迷惑でしかない

**デフォルトの名無しさん** · 2022/12/14(水) 12:43:46.50

>>110
はい、逃げた～
そもそもここRustスレだから迷惑なのはお前な

**デフォルトの名無しさん** · 2022/12/15(木) 18:34:29.90

Rust自体は好きで趣味で使ってるんだけど、最近の猫も杓子もRustっていう一部の風潮には、在りし日のC++やJavaが持て囃されていた時代を思い出してしまう時がある

**デフォルトの名無しさん** · 2022/12/15(木) 18:53:18.12

奴隷言語ってことなのかもな

**デフォルトの名無しさん** · 2022/12/15(木) 19:32:12.34

同意。
趣味では楽しく使ってるけど仕事では使いたくないわ。

不具合とか新規要件とか起因で所有権周り軒並みいじる必要が出てきたりしたら泣いちゃう。

**デフォルトの名無しさん** · 2022/12/15(木) 20:01:15.60

>>112
> 最近の猫も杓子もRustっていう一部の風潮
そんな風潮ホントにあるの？
C/C++の置き換えがメインだから分野はかなり限られそうだが

**デフォルトの名無しさん** · 2022/12/15(木) 21:34:29.95

正解は一つだけのようなことは昔Pythonが標榜していたけど
違反や無視しても棒で殴られたりしなかったので普通に普及した

**はちみつ餃子** ◆8X2XSCHEME · 2022/12/15(木) 21:48:07.72

C や C++ が駄目な部分を改定でどうにかしようとしてもツギハギだらけでますますグダグダになるばかり。
C や C++ みたい (いわゆるシステム記述言語) なことを安全にやれるように更地から設計しなおそうという試みの中では Rust は比較的よいと思うよ。

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

>>117
キミは仕事でRust使ってんの？
使ってなさそうな感じを受けたけど

**デフォルトの名無しさん** · 2022/12/15(木) 23:37:14.28

LinkedListってなんで使われないんですか？
VecDequeのほうが性能いいの？

**デフォルトの名無しさん** · 2022/12/16(金) 01:36:50.79

>>119 性能いいことが多いからじゃないかな。
https://www.stroustrup.com/Software-for-infrastructure.pdf
> ... Consider a simple example: generate N random integers and insert
> them into a sequence so that ...
> Now, for which N is it better to use a linked list than a
> vector (or an array) to represent the sequence? ...
> ... When I ran the experiment on my 8-Gbyte laptop, I found N to be much
> larger than 500,000. ...

**デフォルトの名無しさん** · 2022/12/16(金) 01:45:46.48

言語仕様はまあいんだろうけどライブラリがうんこっこ

**デフォルトの名無しさん** · 2022/12/16(金) 02:56:52.27

自演か軍団かどうでも良いが纏めるぞ

>>112
息を吐く様に嘘を混ぜるのはよせ
猫も杓子も...←ウソシンプルに分かりやすいウソ
在りし日の...←ウソ今も昔もJava/C++の時代 + JS/Python/C#
https://i.imgur.com/xwnzvYQ.png

>>117
大人しくしてれば良いものを、そのキャラまたどぶに捨てるのか
もう終わりだよ、そのコテハン

>>117,119-121
話題のすり替え方が雑になってワンパターン

**デフォルトの名無しさん** · 2022/12/16(金) 06:42:28.75

>>85=>>112
よく見たら嘘の混ぜ方が完全一致

**デフォルトの名無しさん** · 2022/12/16(金) 07:28:20.01

>>122のデータ面白い
例えば、0.4%以下集団の慎ましさがまるで違う

Swift/Kotlin/Dart→分野に特化して第一候補、安泰
(モバイルアプリ開発は全体の中では小さいパイだけど)

Rust→システムの低レイヤー分野に特化すれば良いのに、
各方面のスキマ案件や非典型案件で、置き換え風潮だとか
吹聴するから、そこのメインストリームから反感買う
焦り過ぎ

**デフォルトの名無しさん** · 2022/12/16(金) 07:48:14.80

得意分野、スキマ案件や非典型案件、全部集めて0.30%
Rust全然キテないじゃん

**デフォルトの名無しさん** · 2022/12/16(金) 08:03:19.06

無名の謎言語よりも強いぞ

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

Rustもすぐに一巡して新規消滅まっしぐら
無名の謎言語と競うことに

どうしてこうなった？ry

**デフォルトの名無しさん** · 2022/12/16(金) 11:56:22.77

>>119
LinkedListがフィットするユースケースが少ないから

LRUキャッシュをHashMap+LinkedListで実装する時みたいにランダムインサート/デリートがメインでリストを高速に走査する必要がない場合に使われる

**デフォルトの名無しさん** · 2022/12/16(金) 14:41:11.47

TypeScriptでお馴染みのPrismaってRustでも使えるんか

**デフォルトの名無しさん** · 2022/12/16(金) 15:24:01.50

>>129
元々Rustで作ったバイナリをJSでラップしただけのライブラリだった

**デフォルトの名無しさん** · 2022/12/16(金) 17:29:26.91

>>120
LinkedListよりvectorの方が「ほとんどの場合速いからvectorを使うべき」
と言っているのは、Stroustrup氏だけ。

**デフォルトの名無しさん** · 2022/12/16(金) 18:47:30.36

>>131 嘘つくのやめてもらっていいですか。
https://www.google.com/search?q=vector+list で
いま２位に出たこれ↓見ても引用と併せて「ほとんどvector」って言ってる人が少なくとも二人いる。
https://ja.stackoverflow.com/a/6008
> 大抵のケースでは vector<T> 利用で十分かと思います。（Tは要素の型）
> Scott Meyers, "Effective STL" でも、Item 1で次の言及があります
>> vector is the type of sequence that should be used by default.

俺も言うし>>128も言ってそう。

**デフォルトの名無しさん** · 2022/12/16(金) 19:52:47.31

LinkedListがいいとかVectorがいいとかじゃなく適材適所やろ

**はちみつ餃子** ◆8X2XSCHEME · 2022/12/16(金) 20:14:33.69

>>133
適材適所なのは前提として承知の上で「vector が適材である場所が多い」という話だろ。

**デフォルトの名無しさん** · 2022/12/16(金) 21:44:58.60

vectorはメモリが並んでるからキャッシュヒット率が高くて速いって教わった
C++だと裏で追加したときにreallocされて参照が切れるリスクがあるけど
Rustだと一応安全だし

**デフォルトの名無しさん** · 2022/12/16(金) 21:55:52.92

>>122
まず長文を嫌って端折ったのが悪かった、ごめん
Java/C++の在りし日ってのは、特にJavaなんだけど、JavaでGUIデスクトップアプリ作ったりアプレットでフロントをやってた時代の雰囲気と、Rustでwasmフロントやってたり、tauriがイケてる！GUIの決定版！みたいに言ってる奴が似てるなって思ったのよ
WEB全盛の昨今これらは趣味レベルでしかないので数字には出ないし、当然Rustコミュニティやプロダクト全般の事について言ったわけじゃないので"一部"と書いたんだけど、Rustaceanの一部ではなくプログラマコミュニティないし業界の一部とも読めてしまうね
これもごめんなさい

**デフォルトの名無しさん** · 2022/12/16(金) 23:54:59.70

>>132
ここにいるやつらは　データ構造とアルゴリズム　からやり直したほうがいいんじゃないか？

何を持って早い？っていってるんだ？

queueを実装するのにvector使うやつは愚か者だし
ソートするデータにlinked list使うやつも変なやつ

たいていVectorでOKとかいうのは脳みそ停止してる。ちゃんと考えるべき。

linked listは中間にデータをいれるとか、要素を取り除くのが得意なだけ。
普通に適材適所だろ？

**デフォルトの名無しさん** · 2022/12/17(土) 00:08:08.60

まずお前はアルゴリズムうんぬんの前に日本語からやり直せ
はちみつの割にはまともなこと言ってる

> 適材適所なのは前提として承知の上で「vector が適材である場所が多い」という話だろ。

あとqueueの実装にvector使うのは別に変じゃない、リングバッファも知らんのか？

**デフォルトの名無しさん** · 2022/12/17(土) 00:12:22.66

>>137
比較の例は>>120で挙がってるし、「普通に適材適所」を否定してる人も居ないし、
いったい何を見てレスしてるのかわからなくて怖い。

**デフォルトの名無しさん** · 2022/12/17(土) 01:03:01.35

>>120
その記事で、Stroustrup氏は、非常に特殊な例で実験しているように思える。
最初から明らかにvectorに有利、LinkedListに不利な実験。
これは最初からLinkedListに不利なことが脳内でも分かるので、
それが分からないとしたらstroustrup氏は想像力が不足している。
Stroupstrup氏本人は難しくて理由が分からない、みたいに思ってるらしい。

**デフォルトの名無しさん** · 2022/12/17(土) 01:08:13.28

>>134
Stroustrup氏はもっと極端で、LinkedListがvectorより速度面で上回る
ケースはほとんど無い、という程度の事を言っているように思う。

**デフォルトの名無しさん** · 2022/12/17(土) 01:15:11.07

>>140
[補足]
コンテナ内にN個の要素がある場合、
リンクリストは、1個の要素の追加はO(1)。しかし、全走査や探索は、O(N)。
彼の実験だと、1個追加する際に、追加する場所を探すために平均で N/2 個の
ノードを巡ることになっているから、
1要素あたりに必要な時間 = 場所を探す時間 + 追加の時間
= O(N/2) + O(1)
= O(N)
となる。一方、vector の場合、
1要素あたりに必要な時間 = 場所を探す時間 + 追加の時間
= O(N/2) + O(N/2)
= O(N)
となる。
オーダー的には、O(N)で同じだが、前者は、キャッシュミスが酷くなるので、
「係数」がとても大きくなっている。
だから、前者の方が後者よりも遅くなっていっる理由は明確。

結論は、要素を追加する際に「場所を探す」ことを行なっていて、それがLinkedList
の不得意分野だから。

**デフォルトの名無しさん** · 2022/12/17(土) 01:26:25.05

>>142
[補足2]
リンクトリストとvectorで、条件を満たす1個の要素を線形探索で探す時に
かかる時間は、共に O(N)で、オーダー的には同じ。
ところが、彼の実験の場合、(均等確率の完全に近い)乱数で要素の追加される
場所と追加される順序が強くランダムになるようにしている。
この条件だと、途中結果の集合を線形探索する時、vectorは、
要素のアドレスが連続しているのでキャッシュの先読み(prefetch)がよく聞くが、
LinkedListは、アドレスが強くランダムになるので、キャッシュの先読みが
上手く働かず、1個の要素当り、現在のCPUで、80クロックほどのレイテンシーが
発生してしまう。
つまり、この実験においては、要素追加の場所をランダムにしているせいで、
要素を巡る際に、
vectorは、メモリーリードの追加レイテンシーが0に近い。
LinkedListは、メモリーリードの追加レイテンシーが80クロック程度かかる。

**デフォルトの名無しさん** · 2022/12/17(土) 01:27:47.24

>>140-141
そういう極端な解釈や誤解を解くためと思われる FAQ が置いてある。
https://www.stroustrup.com/bs_faq.html#list
まずはこれを読んで、それでもなにか異論を唱えたいならこの中のどの部分についての異論なのか、
自身の主張がどう違うのか明らかにするように。

**デフォルトの名無しさん** · 2022/12/17(土) 01:33:08.88

>>144
俺が言いたいのは、Stroustrup氏は、数学的想像力においては、
俺より馬鹿だということだ。

**デフォルトの名無しさん** · 2022/12/17(土) 01:36:35.34

この分野は、専門家かどうかより、生まれつきの頭の良さがものを言う。
彼ははっきり行って、計算速度の見積もりにおいては才能が無い。
彼が評価されるべきは、
誰もオブジェクト指向を知らない時にSimulaのようなオブジェクト指向言語を
知っていて、それをCに応用したというだけ。
vectorやLinkedListの速度に関しては彼は間違っている。

**デフォルトの名無しさん** · 2022/12/17(土) 01:38:43.69

「測定無しで語らないで下さい」
というのも理論を軽視している学者の典型例。
日本でも物凄く多い。
自分が理論を正しく理解できて無いから、テストしないと見積もることが出来ないだけ。

**デフォルトの名無しさん** · 2022/12/17(土) 01:46:15.68

彼は理論を分かって無いことが明白。
この実験において、LinkedListがNが大きくなると有利になると思い込んでNを
大きくしていったらしい。すると、彼の予想に反してそうならなかった。
しかし、俺には理由が分かる。
むしろ、LinkedListで、Nで割った時の単位要素あたりの時間は、あるNが
ある値を超えたときから曲線の傾きが大きくなる。

(i) N < N0 : キャッシュが働く時:
f(N) = a1 * N + b
(ii) N > N0 : キャッシュが働かない時:
f(N) = a2 * N + b

DDR4-SDRAM での推定の係数 :
a1 = 0.5
a2 = 0.5 * 80

俺は、これを数秒間で導いたから、ケアレスミスが含まれるかもしれない。

**デフォルトの名無しさん** · 2022/12/17(土) 01:50:24.83

>>148
[ミス訂正]
a1 = 0.5 * L
a2 = 0.5 * (L + 80)
L = ループ一回当りのマシン語レベルでの見た目のクロック数。

0.5 を掛けているのは、1回の線形探索において、
平均移動回数が (N / 2) 回と推定されるから。

まだ、ケアレスミスがあるかもしれない。

**デフォルトの名無しさん** · 2022/12/17(土) 02:27:39.08

すごいな。０点回答じゃん。
今後のため、ぜひコテハン頼む。

**デフォルトの名無しさん** · 2022/12/17(土) 02:32:26.93

>>142
> = O(N/2) + O(1)
> = O(N)
ナニコレ？

**デフォルトの名無しさん** · 2022/12/17(土) 02:49:00.46

>>150
ID:7EPFyoxp = はちみつがはちみつ搾り取った後の残りカス

**デフォルトの名無しさん** · 2022/12/17(土) 03:25:53.37

100点おじさん頭悪いのは知ってたけどさすがにここまでとは思ってなかった
文章読解力に難があり過ぎ

**デフォルトの名無しさん** · 2022/12/17(土) 07:25:20.60

>>150,152-153
ちょっ、はちみつオジ=C++スレの天才オジなのか？
そしてすごい0点オジに、頭悪い100点オジ？
誰か複オジ軍団相関図、書いてよ！

**デフォルトの名無しさん** · 2022/12/17(土) 08:32:26.89

Stroustrupもオジ

**デフォルトの名無しさん** · 2022/12/17(土) 09:13:23.75

適材適所にオジ

**デフォルトの名無しさん** · 2022/12/17(土) 09:40:37.34

>>136
これよく見たら謝ってるようでそうでもない
当時Javaの時代の雰囲気(全体)と今のRustのイキリ勘違いヤロウ(一部)は全然レイヤーが違う

**デフォルトの名無しさん** · 2022/12/17(土) 10:03:46.47

>>122
Rustの0.30%には流石にがっかりきた

比率からして既に一巡したんだと思う
Java vs Scala(JVM, 17.5%/0.47% => 何巡もして37倍)
C/C++ vs Rust(Native, 8.24%/0.30% => 一巡目で27倍)

**デフォルトの名無しさん** · 2022/12/17(土) 10:51:59.45

OSに依存しないライブラリの行数は、Android全体の行数で割り算できない
これが割り算のカラクリか

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

フロントエンドのちゃらい流行り廃りを追いかけ続けるのに疲れて
早めにバックエンドに転向したいと目論んでいた筋にとっとは
Rustは無駄だと思い知ったことだろう

GoやっとけよGo

**デフォルトの名無しさん** · 2022/12/17(土) 12:43:51.64

しょーきょー法でGoみたいな風潮もいかがなものか

**デフォルトの名無しさん** · 2022/12/17(土) 13:48:17.15

自分はRust使うけど人にはとりあえずGoにしとけば？って言っちゃうな
VSCodeなんかと同じで無難感はある

**デフォルトの名無しさん** · 2022/12/17(土) 14:06:02.86

統一教会は日本で、ゆとりある教育を提唱しているが、韓国では全く逆のことを言ってるからな。
騙されるなよ。

**デフォルトの名無しさん** · 2022/12/17(土) 14:19:36.18

>>157
対象の集団規模やその集団のレイヤーが異なることと、各々の集団に対して類似又は共通の雰囲気・要素が存在することないし感じられることは両立しうると思わない？

**デフォルトの名無しさん** · 2022/12/17(土) 14:38:10.16

集団って統一教会のことか。

**デフォルトの名無しさん** · 2022/12/17(土) 14:42:50.70

統一教会と自民党は両立じゃないだろ。
日本における統一教会の実行部隊が自民党。

**デフォルトの名無しさん** · 2022/12/17(土) 15:23:19.74

なんでRustのスレで統一教会が出てくるんだ…

統一教会に限らずカルトの関心は政治権力だから判定条件はis_自民党()じゃなくis_政権与党()だろ
必ずしもすべての政党が実行部隊機能を実装してるとは限らないけど
自民党を取り換えればカルト問題が解決するみたいな発想だとデバッグに支障がでるぞ

**デフォルトの名無しさん** · 2022/12/17(土) 15:42:05.55

>>167
ナイーブな考え方だなぁ
宗教法人を解散させればカルト問題は半分解決なんだけとなぜ解散させないのか少しでも考えたことある？

**デフォルトの名無しさん** · 2022/12/17(土) 16:16:29.71

Rustが適材適所なのはゼロではないと承知の上で「Goが適材である場所が多い」という話だろ

**デフォルトの名無しさん** · 2022/12/17(土) 16:35:05.53

Rustはlinuxのドライバー作成専用言語

**デフォルトの名無しさん** · 2022/12/17(土) 16:40:34.79

Rustはしょーきょー法で>>170みたいな風潮

**デフォルトの名無しさん** · 2022/12/17(土) 17:07:17.99

>>168
よっぽどナイーブな考え方で草
中世の人かな？

**デフォルトの名無しさん** · 2022/12/17(土) 17:29:21.75

統一教会信者出てきたな

**デフォルトの名無しさん** · 2022/12/17(土) 18:34:12.05

そうかそうかww

**デフォルトの名無しさん** · 2022/12/17(土) 19:05:38.21

>>151
要素数Nの時に何らかの処理Aに掛かる時間をf(N)とするとき、
O(g(N))は、ある N0 があって、N0 より大きなどんな実数 N に対しても、
f(N) / g(N) < アルファ
が成り立つことを意味し、「押さえられる無限大」、といい、
ランダウ記号(の一種)、または、ラージO 記法という。

だから、O(N/2)=O(N)であり、O(N)+O(1)=O(N)である。

**デフォルトの名無しさん** · 2022/12/17(土) 19:13:53.37

>>175
[補足]
このことは、
f(N) = O(g(N))
とも書く。以下、厳密性はないが、理解のために書いておけば、
f(N)=O(1)とは、大まかに言って f(N) = b
f(N)=O(N)とは、大まかに言って f(N) = a・N + b
f(N)=O(N^2)とは、大まかに言って f(N) = a2・N^2 + a1・N + b
を意味する。だから、
f'(N)=O(N/2)とは、大まかに言って f'(N) = a・N/2 + b のような意味になるから、
a' = a / 2 と書いてしまえば、
f'(N) = a'・N + b となり、f'(N)=O(N)と言えることが分かる。
f''(N)=O(N)+O(1) は、大まかに言って、
f''(N)= { a・N + b1 } + b2 = a・N + (b1+b2) であるから、
f''(N)=O(N) であることがわかる。従って、

O(N/2)+O(1)=O(N)
であることが分かる。

**デフォルトの名無しさん** · 2022/12/17(土) 19:21:03.57

>>176
[補足2]
また厳密性を無視して大体で書くと、
f(N)=O(g(N))
の場合、f(N)のNに関する最大次数がg(N)と同じ、という意味。
だから、g(N)がNに関して k 次元だと、f(N)もNに関して k 次元、という
ことを概ね意味する。だから、大体、
f(N)=O(1) とは、f(N)=b を意味する。
f(N)=O(N) とは、f(N)=a * N + ・・・を意味する。
f(N)=O(N^2) とは、f(N)=a * N^2 + ・・・を意味する。
なので、f(N)=O(N/2)+O(1)だと、
f(N) = a・N/2 + b
みたいになり、これは、N に関して 1 次関数だから、Nに関する最大次数は 1。
だから、O(N)ということになる。