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/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は無限積分を数値計算するため分割統治のバタフライ演算に落とし込んで更に演算量を抑えるため各種のアルゴリズムが考案されてる