Rust part28

**デフォルトの名無しさん** · 2025/03/24(月) 17:37:00.15

公式
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 part27
https://mevius.5ch.net/test/read.cgi/tech/1733146370/

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

**デフォルトの名無しさん** · 2025/04/09(水) 23:36:43.93

領域展開

**デフォルトの名無しさん** · 2025/04/10(木) 01:14:23.84

>>398
>境界は「自分の認識の及ぶ対象・範囲」が原義で
>更に「自分の能力の及ぶ範囲」という意味が加わってくる
それは仏教用語でキョウガイと読む
現代日本語の境界(キョウカイ)にはそのような意味はない
境界(キョウカイ)の原義でもなく違う言葉

仏語を当ててトレイトキョウガイと読ませたかったのか？

**デフォルトの名無しさん** · 2025/04/10(木) 01:18:20.37

boundsも古典英語なら現代日本語の境界(キョウカイ)の意味もあるが
現代英語には境界(キョウカイ)の意味は基本的にはない
日本語の境界はboundary

現代英語でboundsを境界と意訳してもいいのは
out of boundsやwithin boundsなど
前置詞を伴って範囲の内か外だけに焦点があたっている状況のみ

**デフォルトの名無しさん** · 2025/04/10(木) 01:24:45.88

飽きたからXで訳者に凸してきなよ

**デフォルトの名無しさん** · 2025/04/10(木) 01:29:38.95

>>401
これもなんとも無理やりだなぁ

現代日本語における境界は境・境目・境界線のことで基本的に「線」の概念
境界という線により区切られた結果としてその内側の範囲や領域ができるが
境界という言葉が区切られた結果としてできる内側の範囲や領域を示すわけではない

境界(キョウカイ)という概念は境界を通して接している二つのものがなければ成り立たない

**デフォルトの名無しさん** · 2025/04/10(木) 09:28:59.90

>>381
そんなことしたらゴミが増えるだけ

**デフォルトの名無しさん** · 2025/04/10(木) 09:34:45.39

>>398
水平線地平線がしっくりくる

**デフォルトの名無しさん** · 2025/04/10(木) 09:37:18.05

で、結局Windowsアプリ用としてのGUIフレームワークはどれがおすすめなん？

**デフォルトの名無しさん** · 2025/04/10(木) 10:02:20.15

新参発見したわ
https://aquasoftware.net/blog/?p=2223

**デフォルトの名無しさん** · 2025/04/10(木) 11:31:17.20

>>324
>Rust での解説はこれから市民権を得ていくでしょうか。もしそうなるとすると、自分が一番馴染みがある言語で学べることになりとてもワクワクします。

今後こんな糞スペックのが増えてくるんだろうな

**デフォルトの名無しさん** · 2025/04/10(木) 11:43:14.72

>>410
Tauri以外にあるの?

**デフォルトの名無しさん** · 2025/04/10(木) 11:46:18.80

>>410
いつの間にか、eguiで日本語インライン入力できるようになっている

**デフォルトの名無しさん** · 2025/04/10(木) 12:11:08.05

>>410
個人的には slint が使いやすいとは思ってるが、 Windows の知識が充分にあるという前提なら windows-rs 経由で API を直接に呼ぶのが楽という人もいると思う。

**デフォルトの名無しさん** · 2025/04/10(木) 16:33:28.17

>>369
その通り
ちなみにRustには4つの関数があり
{fn}　キャプチャのない関数　
Fn - {fn}　キャプチャ時の値を参照してしまう関数
FnMut - Fn　キャプチャ時の値を書き換えてしまう関数
FnOnce - FnMut　キャプチャ時の値を消費してしまい1度しか呼べない関数

**デフォルトの名無しさん** · 2025/04/10(木) 18:07:01.46

自分と会話し始めちゃったよw
それも全く意味がない会話を

**デフォルトの名無しさん** · 2025/04/10(木) 18:27:16.96

foo.bar()はfooを移動したのか参照したのか見た目で区別できない
移動かと思ったらじつはCopyだったりするし
foo()も同じ

**デフォルトの名無しさん** · 2025/04/10(木) 19:11:04.12

>>418
CopyされうるならCopyトレイト実装型なのでムーブされることはない
ムーブされたらその後に使われていないため誤読することもない

**デフォルトの名無しさん** · 2025/04/10(木) 22:19:50.16

>>418
そういうのはIDEがやる仕事でしょ

**デフォルトの名無しさん** · 2025/04/10(木) 22:42:29.86

オープンソースの翻訳にいちゃもん付ける活動してるのは技術評論社だっけ？
本買え本って言ってたよな

**デフォルトの名無しさん** · 2025/04/11(金) 11:22:05.80

>>397
型の世界において、
ここまて型の抽象性を広げて戻り値として返す。
少なくともここまで狭めた具体的な型を引数として要求する。
その境。

**デフォルトの名無しさん** · 2025/04/11(金) 11:46:40.40

共感できることに共感するのは有能だがどんな妄想にも共感するやつは無能だ

**デフォルトの名無しさん** · 2025/04/11(金) 12:20:13.15

いいかげん中身のない主張やめて、とっととthe rust book 最新版を翻訳して用語を統一しろ。

the rust book 翻訳を古いまま放置して、偉そうに翻訳を語るなよ。

**デフォルトの名無しさん** · 2025/04/11(金) 12:57:51.71

Rust bookみたいな聖書があるのに聖書の翻訳が気に入らないからと文句つける奴は頭おかしいわ
トレイト境界でもういいだろ。聖書にそう書いてあんだよ

**デフォルトの名無しさん** · 2025/04/11(金) 13:02:09.03

今の時間crates.ioメンテでもしてんのか？
反応クッソ遅いんだが

**デフォルトの名無しさん** · 2025/04/11(金) 16:09:31.37

日本語の本読んでる時点でダメだ。原書の話題だけ頼む

**デフォルトの名無しさん** · 2025/04/11(金) 16:29:00.90

>>427
原著が日本語ならこんな翻訳の問題起きなかったって言いたそうだけど違うぞ
どの言語だろうと聖書に書かれた内容に食ってかかる反体制派とか左翼っぽいのが生まれる社会土壌の問題だ

英語が母国語でもこういうタイプの輩は、boundsという用語を使ったことに対して反抗してconstraintsで統一しろとか騒ぐ
言語の問題なんかじゃ無い。心の問題であり態度の問題だ

**デフォルトの名無しさん** · 2025/04/11(金) 16:32:35.54

いや、面倒だからフィルタになるでしょ
って程度だよ
このスレ自体を英語だけにしてもいいぞ

**デフォルトの名無しさん** · 2025/04/11(金) 16:50:22.75

>>422
>その境。
その境って何の境？
その説明じゃ全然分かんない

**デフォルトの名無しさん** · 2025/04/11(金) 18:38:06.51

境界信者はやっぱり宗教詳しいんだね
学会や壺も他宗教について詳しいもんね

**デフォルトの名無しさん** · 2025/04/11(金) 18:43:51.54

rustの仕様見たけど肝心なlifetimeの情報が網羅されてなくて本当にこれが仕様として働くのか疑問に思った

**デフォルトの名無しさん** · 2025/04/11(金) 19:27:00.96

なんでも動的にチェックする簡易な実装を考えたほうがわかりやすい

**デフォルトの名無しさん** · 2025/04/11(金) 21:09:53.34

>>432
こないだ寄贈されたやつ？
叩き台にする程度でしょ。
まだ決定版というわけではない。

**デフォルトの名無しさん** · 2025/04/11(金) 22:11:47.10

>>434
とはいえあれでISO 26262とかの認定は通ってるんだよね
ああいう審査って何を見られてるんだろ

**デフォルトの名無しさん** · 2025/04/12(土) 06:43:32.65

USO-800

**デフォルトの名無しさん** · 2025/04/12(土) 11:10:12.54

Rust境界例

**デフォルトの名無しさん** · 2025/04/12(土) 12:46:42.80

>>430
トレイト境界はあらゆる観点で間違った訳語なのでまともな回答を期待しても無駄だよ

難しい概念ではないのに「境界」を使った途端に簡潔な説明ができなくなるんだから訳語としての用を成してない

**デフォルトの名無しさん** · 2025/04/12(土) 13:53:53.64

このスレの結論
trait boundの翻訳の議論を除けばRustには欠点がないと思っていいかな？

**デフォルトの名無しさん** · 2025/04/12(土) 13:55:52.66

GC言語経験者には、難しいというのは欠点かも

**デフォルトの名無しさん** · 2025/04/12(土) 14:14:59.77

文字列処理の経験者は案外GCを使わない経験をしているはず
だが文字列指向を捨てるよう訓練された人が一番苦労する

**デフォルトの名無しさん** · 2025/04/12(土) 14:32:57.78

toastyっていつになったら使えるようになるの？

**デフォルトの名無しさん** · 2025/04/12(土) 16:12:49.92

>>442
toastyがどこまでやるのか途上でわからんけどさ
O/Rマッパーを名乗ってるから単純なものには使えても一般的にはORMの様々な欠点を抱えるっしょ
だからORMではないSQLxが人気だけど非同期ORMの需要もあるから既にSeaORMやDiesel-asyncがある状況で
新たにtoastyをtokio直下プロジェクトで進めようとしてるのはRDBよりむしろNoSQL対策がメインと見ていいのかね

**デフォルトの名無しさん** · 2025/04/12(土) 16:14:41.99

>>435
品質管理系の規格 (ISO9001) だと「発生したトラブル (不良品) に対して対策をする手続きが存在していてその手続き通りに実施しているか」を審査されるが、対策の効果や妥当性は審査対象ではない。
実際問題として作ってる製品の性質によるから審査しようがないし。
26262 がどういう性質のものなのかググったくらいでは全然わからんが 9001 と同じようにメタな部分を審査するんじゃないかな……。
ダングリング防止の機能があることなどは審査されてもどういうメカニズムで実現されるかは審査対象外なのかもしれん。

**デフォルトの名無しさん** · 2025/04/12(土) 17:46:03.85

>>438
まともな回答じゃなくても妥当性を判断する材料にはなる

**デフォルトの名無しさん** · 2025/04/12(土) 20:51:24.81

ニューメディアには二種類ある
知りたいことだけを問い合わせるメディアと
従来は網羅できなかったことを網羅するメディア

**デフォルトの名無しさん** · 2025/04/13(日) 10:15:42.59

これよな

そう思えるのはお前も信者だからだろ

結局のところRust信者はポリコレ過ぎる
これも「政治的に」Linusにチクって解決しようとしたところ、ブチ切れられただけ
記事の話が全部本当だとして総合的に推定すると、
Rustから叩く為のラッパ的な物を用意しようとしたところ政治闘争となり、両者辞任の痛み分け、
カーネル自体のコードには今後ともRustは無し、という所ではないかと
これは「支持」ではなく「容認」だろうよ

ただまあ、何でそんな物が『カーネル側に』必要なのか技術的に疑問ではあるがな
RustからCのAPIを叩けないなんて事はあり得ないだろうし、仮にそうだとしても、API変換をRust側でやればよかっただけの話
俺はHellwigの方が正しいと思う。まあLinus案も落とし所としてはありなだろうけど
(というかLinusはこの辺が断然上手い)

Rust信者は、技術的理由ではなく、非Rust話者を排除する為にRustを使う
TypeScriptにも似たような奴はいると思うけど

**デフォルトの名無しさん** · 2025/04/13(日) 13:34:29.88

ボランティア翻訳に訳の分からんいちゃもん付けるのはたいてい技術評論社
奴らは本を売りたいだけだから無視して良いと思う

**デフォルトの名無しさん** · 2025/04/13(日) 13:40:39.46

抽象化モデルが非効率だったと何年もたってから発覚したときにはそのモデルに依存しきっていて全体の書き直ししか修正しようがないということをリーナスは書いている。
プログラムを凝らずに書けることが良いというよりは、凝ったプログラムが柔軟性がない (修正しにくい) ことを問題視してるように見える。

実行効率はやってみないとわからん場合もあるし事情が変わる場合もあるから、ある時点で設計として真っ当であってもずっとそうだとは限らんのだな。

**デフォルトの名無しさん** · 2025/04/13(日) 15:14:15.49

>>448
問題のボランティア翻訳に深く関わってる人達が書いた本を出版してるのが技術評論社だぞ
jp.mercari.com/item/m61131849914

**デフォルトの名無しさん** · 2025/04/13(日) 15:55:50.50

突然メルカリのリンクを貼られてドン引き

**デフォルトの名無しさん** · 2025/04/13(日) 16:47:42.50

会社もメルカリで売ってるのかすごいな

**デフォルトの名無しさん** · 2025/04/13(日) 17:58:50.92

SDGsの時代だからね

**デフォルトの名無しさん** · 2025/04/14(月) 14:43:52.73

ますます怪しいな

**デフォルトの名無しさん** · 2025/04/14(月) 16:15:10.37

ボランティアは文句つけられるけど
うちから出せば金が出るよってことか

**デフォルトの名無しさん** · 2025/04/14(月) 16:17:16.70

ボランティア叩き企業なのに
指摘されて即座に擁護が湧くのが怪しいと思う

**デフォルトの名無しさん** · 2025/04/14(月) 23:45:08.90

>>447
そうではなくて、
既に進みつつある(デバイスドライバを含めた)カーネルモジュールのRust化の利便性のために、
Rust用のAPIをLinux公式としてサポートする方針でLinusもOKを出したんだよ。
カーネルのコア部分はC言語のままだけど、各カーネルモジュールは新規分からRustへ置き換わっていってる。

**デフォルトの名無しさん** · 2025/04/14(月) 23:48:27.55

マジかー
お爺ちゃん達Rustやりだすの?

**デフォルトの名無しさん** · 2025/04/15(火) 10:08:30.99

Option<Ordering> を得たいときに i64 とか i32 の integer 型の condition があるとして
let hoge =
if condition == 0 { Some(Ordering::Equal) }
else if condition < 0 { Some(Ordering::Less) }
else if condition > 0 { Some(Ordering::Greater) }
else { None }
;
で hoge に Option<Ordering> が得られるのですが
hoge を反転させた状態を hoge から直接得るにはどうすれば良いのでしょうか
上の例のコードで -condition に置き換えたときに得られる結果と同じものを
コードの重複を避けて hoge から !hoge みたいに取得したいのです

**デフォルトの名無しさん** · 2025/04/15(火) 10:42:57.35

hoge.map(Ordering::reverse)

**デフォルトの名無しさん** · 2025/04/15(火) 10:51:02.82

>>459
反転はreverseすればいいとして
普通にcondition.cmp(0)したほうがいい

事情があってOption化したいとしても
cmpできる場合とそうでない場合の2つに分岐させる

**デフォルトの名無しさん** · 2025/04/15(火) 11:01:31.96

【脳科学】「政治行動の激しさ」に関連する脳回路の存在が研究で判明 [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1744637408/

上記のリンクをたどったリンク先の本文とコメントを読まれると・・・
余裕ありますか・・・
大々的にインターネット上にばらまかれました！

**デフォルトの名無しさん** · 2025/04/15(火) 17:11:35.23

PartialOrdを実装してるようには見えんよな

**デフォルトの名無しさん** · 2025/04/15(火) 21:09:18.10

XY問題っぽいけど本人がいいなら別にいいんじゃね

**デフォルトの名無しさん** · 2025/04/15(火) 23:20:57.63

>>459
それらi32やi64はOrd境界を満たしている
そしてOrdにはsupertrateとしてのトレイト境界PartialOrdがある
まずそのifの4分岐を使わずともx.partial_cmp(&0)でOption<Ordering>を得ることができる
ただしOrdも満たす整数型では常にSomeとなりNoneになることはない

一方でf64などの浮動小数点は!Ordなのでpartial_cmpでNoneが返りうる
自分でstruct Pair(i32, i32)を作り二つのi32のcmpが同じ時のみpartial_cmpをSomeにする型等も同様にNoneが返りうる
そのためにPartialOrdとOrd(: PartialOrd)の二段階に分かれている

今回のi32型やi64型はOrdも実装されているためNoneが返ることは絶対にない
したがって今回はx.cmp(&0)でOrderingを返すのが正しい

**デフォルトの名無しさん** · 2025/04/16(水) 00:32:42.55

>それらi32やi64はOrd境界を満たしている
トレイト制約とトレイト実装の区別ができてないやつをちょくちょく見かけるけどあれ境界本の影響だったのか

**デフォルトの名無しさん** · 2025/04/16(水) 00:40:00.05

ある型がXxx境界を満たすこと＝その型がXxxを実装していること、だから正しいよね

**デフォルトの名無しさん** · 2025/04/16(水) 09:39:47.23

境界を満たすことって表現が気持ち悪い
日本語的じゃない

区域に含まれるようでいてそういう話でもない

**デフォルトの名無しさん** · 2025/04/16(水) 10:00:02.42

>>468
英語的にも自然ではない。でも Rust 用語ではこう言うことになっている。
テクニカルタームってのはそういうもんなので自然かどうかを論じるのは無意味。

**デフォルトの名無しさん** · 2025/04/16(水) 11:16:05.15

明らかに間違った言葉を使っていても”テクニカルタームってそういうもんなので”で済ませるメンタリティの持ち主が誤訳を生み出して広めるってことだな

役に立つ誤訳ならいいけど>>465からも分かるように境界は足を引っ張る誤訳だから早く止めるに越したことはない

**デフォルトの名無しさん** · 2025/04/16(水) 11:28:23.19

traitボヨヨ～ンでいいよ。

**デフォルトの名無しさん** · 2025/04/16(水) 11:30:24.19

普通にC#/TypeScript/Kotlinあたりで採用されているconstraint: 制約でよかったと思うけどね
Rustは変な選民意識が足を引っ張っている

**デフォルトの名無しさん** · 2025/04/16(水) 11:33:26.57

Cの置き換え言語に高尚な意識は要らん

**デフォルトの名無しさん** · 2025/04/16(水) 11:34:30.78

組込みやってる人達と接点は持ったほうがいいね

**デフォルトの名無しさん** · 2025/04/16(水) 12:15:29.62

くだらない議論する労力あるならとっととthe rust book 最新版を翻訳して用語統一しろよ。

**デフォルトの名無しさん** · 2025/04/16(水) 12:22:24.48

プログラムという単語自体がもうおかしいからな
そこに目を瞑ってる時点で同じ穴の狢よ

**デフォルトの名無しさん** · 2025/04/16(水) 12:41:52.97

>>460
Option<Ordering> に .map(Ordering::reverse) ってゼロコストなんか
可読性がどうでも良いなら
>>459 でそのまま -condition した方が速いんじゃね

**デフォルトの名無しさん** · 2025/04/16(水) 12:48:16.89

>>469
>英語的にも自然ではない。
CPU boundsとか聞いたことないの？

**デフォルトの名無しさん** · 2025/04/16(水) 15:44:17.59

意識高い系プログラミング言語界隈はbindを多用しすぎていて曖昧になってしまっているのは問題
ネイティブにとってクールで知的な語感なのか知らんがどんだけ束縛プレイ好きなんだよ

**デフォルトの名無しさん** · 2025/04/16(水) 16:00:15.57

緊縛緊縛

**デフォルトの名無しさん** · 2025/04/16(水) 18:39:21.33

AとBの境界を満たすって意味がもうすでに訳が分からないので気持ち悪い

**デフォルトの名無しさん** · 2025/04/16(水) 19:25:04.78

上界下界

**デフォルトの名無しさん** · 2025/04/16(水) 19:28:02.69

AとBの条件を満たすならわかる
AとBの境界を満たすのは意味不明

Aの境界を満たすですら意味不明

**デフォルトの名無しさん** · 2025/04/16(水) 19:31:37.92

簡単な概念に難しい言葉使いすぎ。共和党党員でも理解出来るdealみたいな簡単な単語にする
computerとかラテン語っぽいのは嫌われちゃうぞ

**デフォルトの名無しさん** · 2025/04/16(水) 21:14:58.28

テクニカルタームってのは「その分野に固有の定義がある語」なので日常用語の意味で解釈されないようにしなきゃならないんだよ。
その分野を学んだことがない初心者でも自然に読めてしまうのは用語の選定が失敗した証だとも言える。
法律用語の「悪意」「ないし」あたりは日常用語とは明瞭に意味が異なるのに日常用語としても解釈できてしまうので良くない例だ。
その一方では全く由来のないデタラメに作り出した語は単純に言いにくいし覚えにくい。
境界と言うかわりにププイータとかフニャコソとか言ったって (それで統一されるなら) 辻褄は合うが、さすがにそれはあんまりというものだろう。
そういう微妙な機微を踏まえて選定するものなんだよ。

**デフォルトの名無しさん** · 2025/04/16(水) 21:17:18.07

ボヨヨ～ン一択

**デフォルトの名無しさん** · 2025/04/16(水) 21:24:19.59

>>477
それは最適化されるので大丈夫
「-condition」を使ってはいけない
これはi32::MIN時にoverflowする
したがってそのif文で書くならばGREATERとLESSを入れ替えるか
「condition > 0」と「condition < 0」を入れ替えることになる

しかしOrderingについて「if文で多分岐させる」こと自体がいけない
可読性に劣るとともにケアレスミスも起きうるだけでなく
生成コードを見ると以下の正解よりも少し長くなりえて遅くなりうることがわかる

正解はこれ
普通のまま: condition.partial_cmp(&0)
逆にする時: condition.partial_cmp(&0).map(|x| x.reverse())
逆にする時: condition.partial_cmp(&0).map(Ordering::reverse) 【上記と同じ】
いずれも生成コードがそのif文より短くなりうる
そして可読性も優れている

ただしconditionにi32やi64の整数型を使うとpartial_cmp()がNoneになることはない
Option<Ordering>を使う必要はなくcmp()でOrderingを得れば十分
真の正解はこれ
普通のまま: condition.cmp(&0)
逆にする時: condition.cmp(&0).reverse()

**デフォルトの名無しさん** · 2025/04/16(水) 22:12:59.22

てすと

**デフォルトの名無しさん** · 2025/04/16(水) 23:55:34.09

Rustでの抽象化したコードの方が可読性の良さだけでなく速いんだよな
様々な抽象化したコードの連鎖もRustでの最適化と下請けのLLVMでの最適化のおかげで速くなってる

**デフォルトの名無しさん** · 2025/04/17(木) 00:27:01.07

エイリアス解析は最適化の重要な要素だから参照関係を明瞭に追える Rust は有利。

**デフォルトの名無しさん** · 2025/04/17(木) 06:01:08.25

Rustはオワコン

**デフォルトの名無しさん** · 2025/04/17(木) 11:32:45.05

>>485
bind (bound, boundary, 等々)なんて、特に固有の定義を持たない雰囲気ワードの最たるものだろう
なんとなくオシャレだからというだけで乱用されすぎてもはや意味不明

**デフォルトの名無しさん** · 2025/04/17(木) 11:47:53.19

>>477
反転するコストがあるんだからゼロコストではない
でも反転前の値が既にある前提なら.map(Ordering::reverse)より速くするのは無理
conditionから新規に反転した値を取得したいのなら当たり前だけど.map(Ordering::reverse)を使わないほうが速い
(ただし>>459の実装ではなくstdと同じ実装を使わないと最適化の度合いで差が出る)

**デフォルトの名無しさん** · 2025/04/17(木) 12:04:31.60

これは嘘です
その場合でも.map(Ordering::reverse)が一番速いです

>>493
>>conditionから新規に反転した値を取得したいのなら当たり前だけど.map(Ordering::reverse)を使わないほうが速い

**デフォルトの名無しさん** · 2025/04/17(木) 12:20:41.10

ところがRustならゼロコストなんだなあ

**デフォルトの名無しさん** · 2025/04/17(木) 13:46:18.29

ユースケース説明してくれないのに速いとかなんとか言っても不毛だし境界の話に戻ろうぜ！

**デフォルトの名無しさん** · 2025/04/17(木) 14:21:55.09

>>487
論理的に反転したいときにreverseって一般的なのかな
negateの方がふさわしいと思うが

**デフォルトの名無しさん** · 2025/04/17(木) 15:59:50.14

【AI】OpenAIが「GPT 4.1」のAPIを公開、100万トークン対応と実用性能で飛躍的進化を遂げた次世代AIモデル [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1744724723/

上記のリンク先のコメントを読んでもまだ医者の威厳を保てるのか？

**デフォルトの名無しさん** · 2025/04/17(木) 18:53:03.37

>>459
それと全く同じ動作をする関数fはこれが速さも簡潔さもベスト

fn f(condition: i64) -> Option<Ordering> {
　condition.partial_cmp(&0)
}

Less/Greaterを反転させた関数f_revはこれが速さも簡潔さもベスト

fn f_rev(condition: i64) -> Option<Ordering> {
　0.partial_cmp(&condition)
}

アセンブリ手書きでもこれらの生成コードより速くできないことをx86-64で確認した

**デフォルトの名無しさん** · 2025/04/17(木) 19:35:44.38

>>497
Rustではサイドエフェクトが無いことを保証できるので
どちらでも同じコードに落ちます

**デフォルトの名無しさん** · 2025/04/17(木) 19:48:15.83

>>497
論理反転ではないからreverseだと思う
論理反転ならlt⇔ge　gt⇔le　eq⇔neだろうけど
Orderingはlt,eq,gtの3種
そしてOrdering::reverseはlt⇔gtだから

**デフォルトの名無しさん** · 2025/04/17(木) 22:47:28.82

結局RustではC風に書くより抽象的に書いた方が、
可読性が良いだけでなく実行速度でも有利なんだな。

**デフォルトの名無しさん** · 2025/04/17(木) 22:49:00.49

>>499
でも>>494は
condition.partial_cmp(&0).map(Ordering::reverse)のほうが
0.partial_cmp(&condition)より速いって言ってるけどどっちが本当？