Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

**デフォルトの名無しさん** · 2024/05/30(木) 12:33:13.48

Rustと外側との境界はunsafeにせざるを得ないのは当たり前なのに肝心なところはunsafeと言われてもなぁ。
レビューすべき箇所が局所化されるだけでも十分なメリットだろ。

**デフォルトの名無しさん** · 2024/05/30(木) 14:46:49.26

>>20
>>21
どちらも正しい
Rustとその外側の境界部分で必ずunsafeが生じるからそこを問題にすることはない
ただしその部分は安全なインタフェースを提供するモジュールかできればクレートとして分離するのが好ましい

**デフォルトの名無しさん** ころころ · 2024/05/30(木) 16:38:16.78

Rust製Webサーバーで一番使われてるフレームワークって何だろ
MySQLと親和性高いなら使ってみたい

**デフォルトの名無しさん** · 2024/05/30(木) 18:56:43.74

>>23
axumとsqlx

**デフォルトの名無しさん** · 2024/05/30(木) 21:16:17.01

>>24
ありがと、試してみよう

**デフォルトの名無しさん** · 2024/05/31(金) 21:36:08.12

コンパイル前にcargo sqlx prepareでDBサーバからデータの型を得ておくことで静的型チェックできる仕組みなんだね

**デフォルトの名無しさん** · 2024/06/01(土) 10:39:11.44

へー、便利そう。
だけどこういう仕組みってカラム追加時のDBのマイグレーション辺りが入ってくるととたんに難しくなるんだよなぁ。

**デフォルトの名無しさん** · 2024/06/01(土) 22:15:15.67

>>27
そういうDBテーブル構成変更するとどんなプログラミング言語でも何らかの対応が必要となるよ
Rustでsqlx利用ならばDB構成変更した時にcargo sqlx prepareで型をDBから入手し直せばコンパイル時に静的に型チェックされるから楽で安全だね

**デフォルトの名無しさん** · 2024/06/01(土) 22:32:36.24

DBの構成管理をどこで行うかという話
その辺の道具類は他言語に比べてRustはまだまだなので
DB側のツールで管理しておくという昔ながらのやり方が現状のベスト

**デフォルトの名無しさん** · 2024/06/01(土) 22:35:04.27

スクラッチのPHPみたいにSQL直書きからのexecuteはナシ？

**デフォルトの名無しさん** · 2024/06/01(土) 22:44:45.41

>>30
Rustのコード内にSQL直書き文字列を書ける
その上でデータベースとの静的な型チェックもされるのがsqlxのメリット

警備員[Lv.6][新芽] · 2024/06/01(土) 22:51:53.44

それで実行計画も取れるの？

**デフォルトの名無しさん** · 2024/06/01(土) 23:58:30.16

実行計画はDBのデータではないから型チェックは意味ないような

**デフォルトの名無しさん** · 2024/06/02(日) 09:14:40.51

>>21
機械語に近い部分がunsafeなのは当たり前だけど
それを手書きしていることを納得させるのが難しいんだろう
一番自動化されてるフレームワークを使ってみたいんだろ

**デフォルトの名無しさん** · 2024/06/02(日) 12:55:11.71

接続相手の仕様が形式化されたデータとして存在すれば
Rust 上の関数との対応付けを自動化できることもあると思うけど
形式化されたデータは誰かが準備しないといけないことには変わりないからなぁ。

Windows では API の仕様記述を WinMD と呼ばれる形で標準化してるけど
それだって WinRT (ちょっと高級な API) が前提になっているのでそんなに万能ではない。

あらゆる仕様を記述できるほど自由度 (複雑さ) のあるフォーマットにしたら結局は
プログラムを書くのとそんなに変わらんようになるので自動化できる部分は自動化して
ややこしい場合は手書きするという割り切りしないと仕方ない。

**デフォルトの名無しさん** · 2024/06/02(日) 23:32:50.95

Unix系システムコールとの共通部分は
ファイルシステムなど標準ライブラリとして安全なインターフェイスを提供できてるね
Windows特有部分も同じようにMicrosoftがsafeなライブラリを公式に用意することが望ましいのかな

**デフォルトの名無しさん** · 2024/06/03(月) 08:58:28.03

>>35,36
なるほど。結構時間経ったと思うが厳しい。

Microsoftがsafeなライブラリを公式に用意するまで、
プロダクションでのRust採用は様子見するのが良さそうだ。

Linux特有の機能が必要な場合も同様に様子見するのが良さそうだ。

**デフォルトの名無しさん** · 2024/06/03(月) 09:53:26.77

>>37
Windows クレートはもうかなり充実してるよ。
メタデータからの自動生成なので網羅的だし、 safe でいけるメソッドは safe になってる。
unsafe なのは本質的に unsafe なのでどうしようもないし。

Readme に書いてある例が古い Win32 API を使うスタイルの書き方だから印象が悪いのかなぁ……。

**デフォルトの名無しさん** · 2024/06/03(月) 12:15:09.36

>>37
LinuxでRustで困ってることないよ
様子見しなきゃいけないことがあるのならば具体的に挙げてみたら？

**デフォルトの名無しさん** · 2024/06/03(月) 15:47:20.28

>>38
>本質的に unsafe
良いキーワード出た、深掘りしてくれ

これとか
github.com/tokio-rs/io-uring

io_uringが本質的にunsafeだとでも思ってるのかな？

**デフォルトの名無しさん** · 2024/06/03(月) 16:27:42.41

本質的にC++な機能といえば多重継承
多重継承は他の言語に移植できない
万一できたとしたらそれは自動生成ではなく手作業で工夫されたコードだろうね

**デフォルトの名無しさん** · 2024/06/03(月) 17:17:59.54

Win32APIを素で提供しようと思ったらunsafeなのは仕方ないので、もう一枚ハイレベルなラッパーかませてsafeにしてほしいところではある。

**デフォルトの名無しさん** · 2024/06/03(月) 19:27:13.29

だからモダンな WinRT に移行しようね！

**デフォルトの名無しさん** · 2024/06/03(月) 20:11:34.31

WinRTってWin32のAPI網羅できてるの？
モダンなAPIが古いのを機能的に網羅できてないから仕方なく使ってる気持ちなんだけど。

**デフォルトの名無しさん** · 2024/06/03(月) 20:49:12.70

WinRT は「おおよそ」には Win32 API の機能を網羅しているが
根本的なパラダイムが違っていて単純には置き換えられない場合はある。
最初から WinRT を前提として作っていれば Win32 API 抜きで行けることは多いよ。
ゼロではないところがイライラするかもしれんけど。

**デフォルトの名無しさん** · 2024/06/03(月) 21:57:04.03

>>41
クラス多重継承は問題多すぎなダメな機能なので多くの言語で禁止している
クラス継承そのものが問題を多く抱えているため各機能のインターフェースなどを実装するのが望ましい
Rustならば複数のトレイト境界を指定することでそれら複数のトレイト機能を実装した任意の型を対象に抽象的なプログラミングができる

**デフォルトの名無しさん** · 2024/06/04(火) 07:49:08.27

かきを最新AIに重箱の隅をつつく用意尋ねましょう
全ての電磁波は強い低周波も高周波も被爆する?
電磁かいが強い場所は20Hzと55Hzは磁気閃光これも被爆している.?
音波も強い場合は被爆する?
※自然界の化学科学の観測結果論文と人間の人工物で可能な化学と科学論文を読み込ませておく
是者と校舎を別々で回答する用意する
さらに制度を挙げるなら
グレーゾーンの論文をできるともいえるしできないともいえる用意認識させる

現在の科学が正しいのならなら電磁波攻撃はこのグレーゾーンの論文を使用しているので逃亡できている?

統合失調症電磁は音波なら周囲の者被爆している!?
寿命が短いのと免疫力低下起きて当然

**デフォルトの名無しさん** · 2024/06/04(火) 20:02:17.33

GPT4-Vの100分の1のサイズで同等の性能を誇るマルチモーダルモデル「Llama 3-V」が登場、トレーニング費用はたった8万円
2024年05月29日 14時00分
OpenAIがサム・アルトマンCEOを含む「安全・セキュリティ委員会」を設置、さらにGPT-4後継モデルのトレーニングを開始
2024年05月29日
「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
※対象者【被害者】そっくりの返答が可能
たった数秒の音声データから音声合成が可能な「VoiceCraft」
2024年04月16日 07時00分
OpenAIがわずか15秒の音声からクローン音声を生成できるAIモデル「Voice Engine」をリリース
2024年04月01日
会話相手を数秒見つめて声を登録するだけでその人の声だけを聞くことができるAIヘッドホンシステムが開発される
2024年05月30日
※対象者の声を個別に録音

**デフォルトの名無しさん** · 2024/06/04(火) 21:25:19.75

std::ptr::addr_eqでdyn同士やdynと通常参照を比較してもいいんだよね

**デフォルトの名無しさん** · 2024/06/05(水) 02:32:30.56

比較の方法が複数あるとして
最も優秀な方法に依存するのではなく抽象に依存するのが定石だよな

**デフォルトの名無しさん** · 2024/06/05(水) 13:57:39.45

>>17
>肝心なところのほとんどがunsafe

当たり前やん
そもそも観なかったことにするための機能なんだし

**デフォルトの名無しさん** · 2024/06/05(水) 14:16:34.14

言語のパラダイムでどれだけ頑張っても言語の外はその規則に従ってくれないよ。
そこらへんの境界線でおおよそどこでも信頼できるインターフェイスは ABI だけ。
根本の部分が C の影響下にある状況のほうは変えようがない。

一応 unsafe rust という選択肢が登場した分だけだいぶんマシになってんだよ。

**デフォルトの名無しさん** · 2024/06/05(水) 14:19:53.54

>>38,52
>本質的に unsafe

本質的にunsafeの定義、早う

**デフォルトの名無しさん** · 2024/06/05(水) 14:28:05.14

C/C++のコード全体が常にunsafeすなわち自動的な安全保障なしなのに対して
Rustはsafe部分のコードが自動的に安全保障されるという明確な違いがある

**デフォルトの名無しさん** · 2024/06/05(水) 14:33:58.97

>>38,54

定義するとは何かすら知らないレベルでRustやってるのかよw

**デフォルトの名無しさん** · 2024/06/05(水) 15:41:52.55

定義するとは何かも知らなくても書けるのがRustの良いところ

**デフォルトの名無しさん** · 2024/06/05(水) 18:13:30.31

なぜ定義なんだ
喩え話では駄目な理由を考えるとすぐ思いつくのは、喩え話は非○○的だから駄目なんだよね

**デフォルトの名無しさん** · 2024/06/05(水) 19:11:15.28

>>49
dynはアドレスとvtableの対なので使える

use std::fmt::Display;
let i = 12345;
let r = &i;
let d: &dyn Display = &i;
// assert!(eq(r, d)); // 型が不一致でコンパイルエラー
assert!(addr_eq(r, d)); // アドレスが一致

文字列strはアドレスと長さの対なのでこのように比較できる

use std::ptr::{addr_eq, eq};
let s1 = "abcdef";
let s2 = &s1[..3];
let s3 = &s1[3..];
assert!(!eq(s1, s2)); // 長さが異なるので不一致
assert!(addr_eq(s1, s2)); // アドレスが一致
assert!(!addr_eq(s1, s3)); // アドレスが不一致

文字列をバイト列に読み替えたときにも使える

let b1 = s1.as_bytes();
// assert!(eq(s1, b1)); // 型が不一致でコンパイルエラー
assert!(addr_eq(s1, b1)); // アドレスが一致

**デフォルトの名無しさん** · 2024/06/05(水) 19:38:28.12

>>53
safe にするのが不可能(少なくともそれ単体は)というシンプルな意味で使ってるつもりだが

**デフォルトの名無しさん** · 2024/06/06(木) 22:14:32.57

fn 単純にこの比較も<T>(slice: &[T], index: usize) {
　let p = &slice[index];
　let q = &slice[index..];
　// assert!(eq(p, q)); // 型不一致
　assert!(addr_eq(p, q));
}

**デフォルトの名無しさん** · 2024/06/07(金) 12:52:26.48

グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
https://ascii.jp/elem/000/004/202/4202481/

**デフォルトの名無しさん** · 2024/06/07(金) 23:50:20.38

as *const ()でupcastして比較しているだけなのか

**デフォルトの名無しさん** · 2024/06/08(土) 04:40:43.01

Option<String>型のxがある時に
x.as_ref()とするとOption<&String>が得られ
x.as_deref()とするとOption<&str>が得られることがわかりました

Option<&String>型のyがある時に
y.as_deref()としてもOption<&String>のままになりました
yからOption<&str>を得るにはどうすればいいのでしょうか？

**デフォルトの名無しさん** · 2024/06/08(土) 09:07:24.88

let tmp = Some(y.unwrap().clone());
let hoge = tmp.as_deref();

**デフォルトの名無しさん** · 2024/06/08(土) 09:09:50.82

cloneしたくなかったら
let hoge = Some(y.unwrap().as_str());

**デフォルトの名無しさん** · 2024/06/08(土) 10:33:13.95

unwrap()は基本的には使ってはいけない。

使ってもよい場合は論理的にNoneが絶対に来ないことが保証されてる場合で、
直前にNoneではないことをチェックしていて明白な場合と、
構造的にそこにNoneが来ないことをコメントで明記している場合のどちらか。

**デフォルトの名無しさん** · 2024/06/08(土) 10:34:38.61

もう一つは簡易プログラミングをする場合で、
そこにNoneが来た時に処理続行の意味がなく、
パニックという形でプログラムを終わらせても構わない場合。
これは本来はきちんとエラー処理対応するのが好ましい。

**デフォルトの名無しさん** · 2024/06/08(土) 10:39:31.95

ドキュメントのサンプルでは、
エラー処理は邪魔なので簡易的にunwrарが多用されているが、
それをそのまま用いるのがマズい理由は上述のため。

**デフォルトの名無しさん** · 2024/06/08(土) 10:45:50.57

「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
リコーと理研、技術の実用化の“兆し”を察知するアルゴリズムを開発
2024/06/05
グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
2024年06月06日

**デフォルトの名無しさん** · 2024/06/08(土) 11:07:47.98

>構造的にそこにNoneが来ないことをコメントで明記している場合

これはexpectのことを言ってるのかな？
panic!することには変わりないが

警備員[Lv.1][新芽] · 2024/06/08(土) 11:13:56.61

truckに手をだす勇者はいないのか？
https://github.com/ricosjp/truck

**デフォルトの名無しさん** · 2024/06/08(土) 11:35:42.10

>>63
y.map(|s| s.as_str())
or
y.map(String::as_str)

**デフォルトの名無しさん** · 2024/06/08(土) 11:44:51.45

>>70
単にunwrapでpanicさせるんじゃなくて
unwrap_orやunwrap_or_elseなどを使ってfallback valueを返す

>構造的にそこにNoneが来ないことをコメントで明記している場合
個人的に↑これには賛同しかねる
コードが脆弱になるから

**デフォルトの名無しさん** · 2024/06/08(土) 12:33:54.09

構造的にNoneでないことを期待しているロジックならチェックしたところでどうせリカバリできないんだし
単にパニックでいいと思うけどな

**デフォルトの名無しさん** · 2024/06/08(土) 12:53:40.15

事前条件・事後条件に反するときは panic するのが推奨されてなかったっけ？
要するにそういうことが一度でも起きたらバグが含まれているプログラムということだから修正するという前提がついてる。
あらゆるルートを想定するのも無意味だし、想定しないルートに入ったまま続けてもろくなもんじゃないので変なところがあったら止まったほうがいい。

ライブラリとして提供するなら expect にするに越したことは無いが
ただの panic でもスタックトレースは出せるし、
発見するのが自分 (またはチーム内などの身内) で修正するのも自分なら多少は雑でもよかろ。

**デフォルトの名無しさん** · 2024/06/08(土) 13:02:44.03

>>68
サンプルでrust unwrар好きだなと思っていたんだが、そんな理由で多用だったのか

**デフォルトの名無しさん** · 2024/06/08(土) 13:06:19.28

パニックさせるということはNoneかどうかをチェックしているということ
そしてパニック用のコードもそこに含まれるということ
そのため高速化がシビアなケースではunwrap_unchecked()が使われている
unsafeなので確実な監視対象となる点でむしろ好ましいケースもありうる
とはいえ特殊な場合を除き非推奨です

**デフォルトの名無しさん** · 2024/06/08(土) 14:06:17.67

ロジック的に None でありえないことをコンパイラが見抜ける状況でなら最適化で余計なチェックが消えることもあるし、分岐予測で速度的ペナルティはどうでもよくなることもある。
チェックするにしたって単発ではナノ秒単位の処理なので速度的に足を引っ張ることはまずない。
動画処理とか機械学習とかいった計算量が大きいものならチューニングが必要になることはあるかもね。

**デフォルトの名無しさん** · 2024/06/09(日) 00:14:30.88

例えばここにある`self.front.as_mut().unwrap()`や`front.next_kv().ok().unwrap()`のunwrapの使い方は妥当？
https://github.com/rust-lang/rust/blob/master/library/alloc/src/collections/btree/navigate.rs#L79-L80

**デフォルトの名無しさん** · 2024/06/09(日) 00:37:45.34

>>79
if self.is_empty() {
　None
} else {
　以降にあるから内部構造ロジックにより問題なし

**デフォルトの名無しさん** · 2024/06/09(日) 00:50:28.83

でもmatch self.front.as_mut() {
　Some(x) => で書けるならunwrap無い方がいい

**デフォルトの名無しさん** · 2024/06/09(日) 01:03:57.65

例えば>>65ならば
match y {
　Some(s) => s.as_str(),
　None => None,
}

そのNone => Noneの時はmapに簡略できる
y.map(|s| s.as_str())

それをメソッド記法でなくフルに書くと
y.map(|s| String::as_str(s))

ここで|s| f(s)はfと簡略できるためこうなる
y.map(String::as_str)

**デフォルトの名無しさん** · 2024/06/09(日) 08:02:48.25

全ての波【電磁波】で下記の症状が起きる
理由は電磁波が強いために起こるか電磁波が通過すれば磁気が生じて鉄分が振動して間接的に鼓膜などが振動する
マイクロ波聴覚効果を用いた音声伝送に関する検討
2018/03/05
https://www.bookpark.ne.jp/cm/ieej/detail/IEEJ-ZT181039-PDF/
マイクロ波聴覚効果 Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E6%B3%A2%E8%81%B4%E8%A6%9A%E5%8A%B9%E6%9E%9C
>>マイクロ波を照射された被験者は、クリック音やブザーのようなうなり音が聞こえる
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
https://news.mynavi.jp/techplus/article/20240604-2958879/
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
https://news.mynavi.jp/techplus/article/20240606-2960578/
※電磁波も振動させれると記載あり
最低でも下記ノ電磁波の威力が必要なら行っている者全員補足されている
GPSの電波は超微弱
https://gigazine.net/news/20240421-gypsum-gps-receiver/
［２２］米国特許５８６８１００号
【ＧＰＳ位置情報を使用した動物コントロール・システム】
一例ですが年々受信機の感度は向上している
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961238/
電磁波音波攻撃をされている部位ごとにホルモンや異常物質などの観測
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
https://www.asahi.com/articles/ASS652V7RS65ULBH00GM.html

**デフォルトの名無しさん** · 2024/06/09(日) 22:41:10.47

今はOptionにas_slice()があるんだな
Some(x)なら[x]でNoneなら[]のスライス
アドレスは同じで長さが1か0なのか

**デフォルトの名無しさん** · 2024/06/10(月) 07:48:45.58

AIの性能が上がれば世界情勢が見えてくる
にゅーーすで話していることもそれらしきことを話すようになる

まづボイス・トォ・スカルが存在している場合としていない場合を問う
そのあとに人間の行動をどのように行動するかを問う

交友関係全てわかる範囲で入力しておく
社会っ情勢を知るにはさらにどういった役職等も調べておく

自分が使用しているボイス・トォ・スカルを本物か偽物化も割り出せる

**デフォルトの名無しさん** · 2024/06/10(月) 12:58:47.18

>>80
本当に内部ロジック上問題がないのかを確認するために見る必要のある範囲が広すぎるのが問題

>>81
if self.is_empty()を生かしたままという意味なら
不変条件を満たしてないコードが埋もれるのが問題
if self.is_empty()を無くすという意味なら
コードで表現したい意図から乖離するのが問題

**デフォルトの名無しさん** · 2024/06/10(月) 13:47:20.88

不眠症にカップ麺やスナック菓子などの「超加工食品」が関係しているという研究結果
https://gigazine.net/news/20240610-insomnia-linked-ultra-processed-foods/

インターネットの都市伝説「The Backrooms」の起源となった画像の正体はどうやって判明したのか？
https://gigazine.net/news/20240610-origin-of-the-backrooms/

GoogleのGeminiとMicrosoftのCopilotが過去のアメリカの大統領選挙を含めた世界中の選挙の結果を正常に返していないことが判明
https://gigazine.net/news/20240610-google-microsoft-chatbots-election-questions/

**デフォルトの名無しさん** · 2024/06/10(月) 20:09:22.20

ボイス・トォ・スカル
電磁波音波攻撃が判明する
人間は電磁界を発生させている
※被害者の身体に痕跡あり
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
名市大、頭蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
分子研など、金ナノ粒子が円偏光の左右選択性を70倍に高めることを発見
2024/06/06
弾性乱流と古典的なニュートン乱流との共通点を発見――弾性乱流を記述する数学的理論の開発に寄与　OISTら
2024-5-29
京大、テラヘルツ波の照射で超伝導体の臨界電流を制御できることを実証
2024/05/28
産総研など、1000個以上の量子ビットを制御可能な超伝導回路の原理実証に成功
2024/06/05
名大など、水素原子の約1/20の超高精度で収差補正できるX線顕微鏡を開発
2024/05/09

**デフォルトの名無しさん** · 2024/06/10(月) 20:09:43.09

細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発阪大など
2024/05/07
OIST、有機電気化学トランジスタのON時に生じるタイムラグの原因を解明
2024/05/07
並行世界でタイムリープを繰り返す!?効率的な新しいシミュレーション技術
2024.05.22
東大、電子回折パターンの減少とエントロピー増加の対応を実証
2024/06/03
理研など、「スキルミオンひも」の観察とその詳細な融解過程の記録に成功
2024/05/23 19:29
東大など、金属3Dプリント中の2D画像から3D多孔質構造を予測する手法を開発
2024/06/03

**デフォルトの名無しさん** · 2024/06/10(月) 23:46:59.09

>>84
スライスだから&[x][..]だね

**デフォルトの名無しさん** · 2024/06/11(火) 05:30:39.25

男性の精子の減少、携帯電話の使用と関係か最新研究
2023/11/02
https://www.cnn.co.jp/fringe/35211064.html
放射線と被曝
https://www.kan-etsu-hp.ne.jp/wp-content/themes/kan-etsu-hp/assets/kanetsu-hospital/department/pdf/radiology/radiation.pdf
>>エネルギーが極端に大きくなると X 線やガンマ線と呼ばれる放射線の一種になります。
※電磁波音波攻撃被爆している?

MrIは強力な磁場を利用しているので被爆しない

冷凍した人間の脳組織を解凍した後も正常に機能する技術開発
2024.05.12
https://karapaia.com/archives/52331859.html

1立方ミリメートルの脳の断片をハーバード大学とGoogleの研究者がナノメートル単位で3Dマッピングすることに成功
2024年05月10日
https://gigazine.net/news/20240510-human-brain-mapped-in-spectacular-detail/
幼児期の脳活動から18歳時点でのIQを予測できるという研究結果
2023/09/09
https://gigazine.net/news/20230909-brain-activity-toddler-predict-18-iq/

パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
https://www.asahi.com/articles/ASS652V7RS65ULBH00GM.html
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961238/

**デフォルトの名無しさん** · 2024/06/11(火) 05:31:04.86

日常的な蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961214/
細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発阪大など
2024/05/07
https://news.mynavi.jp/techplus/article/20240507-2941335/

脳が鮮明に見える！世界最強の磁束密度で脳をスキャンするMRI「イズールト」
2024.04.05
https://nazology.net/archives/148090
※5分で全身スキャン完了するのかな

**デフォルトの名無しさん** · 2024/06/11(火) 06:55:26.94

電磁波兵器の特許情報/Google検索で下記が判明
電磁波過敏症低周波騒音被害の症状が出現

設立 1998年テクノロジー犯罪の撲滅
Https://media.toriaez.jp/s2972/32686.pdf
P77-身体・運動機能が遠隔から操作される P78-五感が遠隔から操作される
ギャングストーキングと電磁攻撃 - 広島修道大学学術リポジトリ
https://shudo-u.repo.nii.ac.jp/record/3395/files/SG63205.pdf

下記を頭部などで再現

人間の「第六感」磁気を感じる能力発見
2019/03/19
https://www.sankei.com/article/20190319-6UGPQVLP4BLEDJYGVSX3WW6A4A/
髪の毛ほど薄いのに音を75％カット！MIT開発の「革新的防音カーテン」
2024.05.13
https://nazology.net/archives/149896

言葉に出さずとも内なる声を解読する、脳の読み取り装置が解発される
2024.05.20
https://karapaia.com/archives/52331884.html

**デフォルトの名無しさん** · 2024/06/11(火) 22:42:05.37

>>90
配列でもベクタでも[..]を付ければスライスへ変換されるわけか

**デフォルトの名無しさん** · 2024/06/11(火) 23:50:24.15

【AI】IQ100超えを達成したAIモデルのClaude 3は「いい性格」を持つようにトレーニングされている [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1718025035/l50

**デフォルトの名無しさん** · 2024/06/12(水) 00:41:51.20

ゼロから学ぶＲｕｓｔ　システムプログラミングの基礎から線形型システムまで (ＫＳ情報科学専門書)

Kindleで本日のみ￥500

**デフォルトの名無しさん** · 2024/06/12(水) 13:31:07.00

Rustの作者と対話をしなくてもRust上級者になれるのは
作者の心を正確に読めるからではなく
あまり正確ではない当てずっぽうと試行錯誤が嫌いではないからだと思う

**デフォルトの名無しさん** · 2024/06/12(水) 17:47:51.37

はじまた
https://www.youtube.com/live/GiVA0MiHCV0

**デフォルトの名無しさん** · 2024/06/12(水) 21:31:56.44

>>94
どちらもstd::slice::SliceIndexによるものだが
その前にVecはstd::ops::Derefでsliceに変換されるのに対して
配列はstd::marker::Unsizeが実装されていて
std::ops::CoerceUnsizedでsliceに変換される点が異なる

**デフォルトの名無しさん** · 2024/06/13(木) 02:53:52.72

人間に匹敵する知能を持った汎用人工知能を開発した研究者に総額100万ドルの賞金を授与するコンテスト「ARC Prize」が開催

**デフォルトの名無しさん** · 2024/06/13(木) 08:11:01.44

zlib-rsの0.2.0きたね
ttps://github.com/memorysafety/zlib-rs

**デフォルトの名無しさん** · 2024/06/13(木) 08:58:47.14

>>99
Vecはヒープに依存し、かつスタックに移動するのが不可能
「サイズ」を定義できないデータは（スタックに）移動できない

個人の感想です
が、これが「知能」だと思うよ

**デフォルトの名無しさん** · 2024/06/13(木) 11:16:55.93

>>95
IQ=2x偏差値

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/06/13(木) 19:06:39.65

>>101
元のzlibとの速度差はどれくらい？

**デフォルトの名無しさん** · 2024/06/13(木) 19:19:21.58

>>104
ガンガンポイント増えるな

**デフォルトの名無しさん** · 2024/06/13(木) 19:53:32.56

zlib-rsはzlibと比較してまだ圧倒的に足りてないからパフォーマンス評価のしようがない
ttps://github.com/memorysafety/zlib-rs/issues/49

**デフォルトの名無しさん** · 2024/06/13(木) 21:05:44.12

>>107
先は長いね

**デフォルトの名無しさん** · 2024/06/13(木) 21:29:59.05

RustはC/C++に置き換わるのか？

警備員[Lv.5][新芽] · 2024/06/13(木) 21:36:14.88

無理無理かたつむり

**デフォルトの名無しさん** · 2024/06/13(木) 21:37:00.52

計画も陰謀もないんだよ

**デフォルトの名無しさん** · 2024/06/13(木) 21:59:02.47

>>104
めっちゃ面白そう
　

**デフォルトの名無しさん** · 2024/06/13(木) 22:16:54.37

>>109
時間さえあれば

**デフォルトの名無しさん** · 2024/06/13(木) 23:52:05.18

>>109
C/C++がRustに置き換わっていってる

**デフォルトの名無しさん** · 2024/06/14(金) 08:05:53.63

>>109
その前にSafe Rust相当のsafe c++とか出るんじゃない？
標準化できるかわからんが。

警備員[Lv.7][新芽] · 2024/06/14(金) 08:11:27.55

C++はUTF-8の扱いを何とかして欲しいね。

**デフォルトの名無しさん** · 2024/06/14(金) 08:28:16.67

>>115
C++をいくら強化してもそれは不可能だと皆がわかった
既存C++資産メンテ用限定としてはCarbonがある
それ以外は全てがRustへの移行に向かっている

**デフォルトの名無しさん** · 2024/06/14(金) 08:44:54.37

>>117
別のサブセットを作るだけだよ。
unsafe rustに対するsafe rustみたいなもの。

**デフォルトの名無しさん** · 2024/06/14(金) 08:53:45.79

>>118
それは無理だとわかったので誰も進めていない

**デフォルトの名無しさん** · 2024/06/14(金) 08:54:29.15

C++やってればそれが不可能なことくらいわかると思うんだけどな