C++ vs Rust

**デフォルトの名無しさん** · 2021/04/24(土) 08:04:49.48

競え

**デフォルトの名無しさん** · 2021/12/02(木) 21:38:58.00

c10kはリソース問題だからブラウザサイドでも同じだよな
5chのページとか見ると多数の広告やら何やら大量にコネクション貼りに行くけど非同期で並行にシングルスレッドでも余裕で可能
これが同期プログラミングしかできない人が作ると数十のコネクションに数十のスレッドを無駄に使うか
もしくはシングルスレッドで1つずつ順に時間をかけるかのどちらかとなる

**デフォルトの名無しさん** · 2021/12/02(木) 21:47:37.10

広告アクセスに時間がかかるなんてのはc10kと全然関係ないだろう

**デフォルトの名無しさん** · 2021/12/02(木) 22:21:10.00

コネクション多数確立するという意味では同じだがC10Kと比較するのはおおげさすぎる
今時のブラウザは非同期処理の塊だろうからもっと良い例あるのでは

**デフォルトの名無しさん** · 2021/12/02(木) 22:30:51.78

ブラウザではそもそもHTML5の登場までマルチスレッド自体使えなかったし
そんな中でもAjaxでイベントによる非同期処理は要求されたし

ブラウザjsに関して言えばマルチスレッドのオーバーヘッドに耐えられず必要に駆られてっていう理由ではなく
従来のイベント非同期をPromiseで簡便に書けて、async/awaitでもっと簡便に書けて喜ばれた、というのが正しい理由でしょうね

**デフォルトの名無しさん** · 2021/12/02(木) 22:41:56.03

>>724
それブラウザがマルチプロセス・マルチスレッドで仕事をこなしてるからGUIアプリとして使いものになるんだぞ

まさかJavaScriptだけで実現できてると思ってたのか？

**デフォルトの名無しさん** · 2021/12/02(木) 22:45:23.47

どこかのスレで見たグリーンスレッド知らないおじさん？

**722** · 2021/12/03(金) 00:10:46.04

>>722
https://ideone.com/IY3aFj
・イテレータを提供
・impl Debug for LinkedListも若干スッキリ

**デフォルトの名無しさん** · 2021/12/03(金) 00:22:36.68

>>722
リスト構造ってほとんど使わんなぁ。　C++だとインスタンスの配列じゃなくて、
インスタンスへのポインタ配列を使えば、配列サイズの拡張に伴う領域確保とコピー
が行われるのは、配列要素であるポインタだけなので、要素数が増えようが、複雑な
オブジェクトだろうが、処理時間は最小限で済む。

リスト構造の欠点はソートに弱いこと。　オブジェクトインスタンスへのポインタ配列
ならソートの場合でも、ソート対象はポインタの並び替えだけで、ポインタが指す
オブジェクトのインスタンスには一切触らない(コピーや再配置は行わない)で済む。

「100日後に退職する47歳」に出てくる「クイックソートの計算量」なんて質問をする
面接官は、記憶力が全ての学力試験が産んだ馬鹿でしかない。　現実問題としては、
ソートする必要がある時はソートしなければならない。　聞くべきは『効率的にソート
するには、どんなデータ構造を採用すべきか』である。

**デフォルトの名無しさん** · 2021/12/03(金) 00:34:51.88

リスト構造も結局のところポインタやん

**デフォルトの名無しさん** · 2021/12/03(金) 00:38:41.22

>>697
GUIスレッドの裏で動く、通信専用のワーカスレッドを1つ作成して、順番に1000個
のサーバヘアクセスに行くのが簡単かつ現実的じゃないかな。

むろんコア数を調べてワーカスレッド数の上限を可変にしてもいいが、アクセス先
リストの消し込みやエラー処理とか自動リトライとか面倒になるし、そこらを頑張っ
たところで、実際のところほとんどの場合は回線速度で頭打ちになる。

それと、たとえスレッドが1000個作れても、実際の環境では、経由するルータや
相手サーバ側の制限などで、同じIPアドレスから、同時に1000個の通信セッション
が張れないことの方が多い。

**デフォルトの名無しさん** · 2021/12/03(金) 00:40:38.11

n番目の要素とm番目の要素を入れ替えるのに
配列だとポインタの読み込み2回、書き換え2回で済むのに対し
単方向リンクリストだと読み込みmax(n, m)+4回、書き換え4回必要になるからこれだけでかなりの差が生じる

**デフォルトの名無しさん** · 2021/12/03(金) 00:44:57.19

>>732
配列と違って、リスト構造を構成する各要素は、メモリ空間上に隣接して配置されて
いないのでqsort()ではソートできない。　あと、リスト内に循環参照がないとしても、
リストをバラす際にコストが掛かる。

**デフォルトの名無しさん** · 2021/12/03(金) 02:01:34.62

>>731
まあメモリが安く大容量になりましたからね…

**デフォルトの名無しさん** · 2021/12/03(金) 02:06:12.08

>>736
QZちーす

**デフォルトの名無しさん** · 2021/12/03(金) 02:08:33.95

>>735
リストのソートにはコムソートが容易に適用できたと記憶しています、ほぼO(NlogN)
https://mevius.5ch.net/test/read.cgi/tech/1434079972/107

**デフォルトの名無しさん** · 2021/12/03(金) 05:25:43.24

>>728
前者はその通り
後者は違ってJavaScriptだけでもGUIアプリは普通に作れる
例えばNode.jsでQtベースの物は軽くて便利

**デフォルトの名無しさん** · 2021/12/03(金) 05:44:07.66

>>733
> 通信専用のワーカスレッドを1つ作成して、
> 順番に1000個のサーバヘアクセスに行くのが簡単かつ現実的じゃないかな。

それは昔の同期プログラミングのマズいやり方でとてつもなく遅くなってしまう

> 経由するルータや相手サーバ側の制限などで、
> 同じIPアドレスから、同時に1000個の通信セッションが張れないことの方が多い。

経由する普通のルータにそんな制限はないです
1000ヶ所へ取りに行くという話だから相手サーバー側には各々1つのコネクションしか貼られないため
通信セッションが張れないということもありません

> そこらを頑張ったところで、実際のところほとんどの場合は回線速度で頭打ちになる。

たった1000個でそんなことは起きません
数KBの1000倍は数MBですから

**デフォルトの名無しさん** · 2021/12/03(金) 08:06:35.94

>>739
それって、Qtライブラリ(JavaScriptではなく、CやC++で書かれている)が、マルチ
スレッド機能を持ってるだけでは？

**デフォルトの名無しさん** · 2021/12/03(金) 08:48:42.45

>>739
そりゃC++だから軽いわな
でもってシングルスレッドかマルチスレッドかの話には基本的に関係ないわな

JSのシングルスレット非同期モデルで対応できるのは
I/O待ち等でCPUがidleになる場合か
ホスト環境が提供する別のプロセスやスレッドに処理をオフローディングできる場合だけ

デスクトップアプリでそこそこ重いSQLiteへの読み書きなんかをJS実行スレッドでやれば非同期だろうがGUIに顕著な影響がでる
だからJS使ってても当然マルチスレッド化する

**デフォルトの名無しさん** · 2021/12/03(金) 09:01:39.32

>>740
> それは昔の同期プログラミングのマズいやり方でとてつもなく遅くなってしまう

実際、書いたことある？　Webサイトの複数ページを移動しながらスクレイピング
して、ダウンロードファイルのURLを取得し、HTTPまたはHTTPSでファイルを順次
自動ダウンロードする自分専用ソフトを書いて使ってるけど、ダウンロード中に
GUIのプログレスバーや転送量/速度などの更新や、キャンセルボタン等の関係から、
GUIスレッドと通信スレッドに分けてるけど、速度はほぼ回線速度と相手サーバーの
応答に依存だよ。

> 経由する普通のルータにそんな制限はないです
> 1000ヶ所へ取りに行くという話だから相手サーバー側には各々1つのコネクション
> しか貼られないため通信セッションが張れないということもありません

確かに1000個のファイル取得先が別々なら、相手サーバーのコネクションは1つだけ
でセッション数も制限を受けないけど、2000を超えると安物や古いルーターだとNAT
テーブルの制限に引っ掛かる気がする。

> たった1000個でそんなことは起きません
> 数KBの1000倍は数MBですから

そんな制約あったっけ？

ちなみに自分が書いたアプリでダウンロードしているファイルは、小さいもので数百KB
大きいと＋数MBくらいで、1000個(総容量約3.5～3.7GB)ダウンロードすると2時間～
3時間くらいかな。

回線はSoftbank Air(非5G)で、今の時間帯だとGoogleのSpeedtestで、ダウンロードが
20Mbpsくらい。

**デフォルトの名無しさん** · 2021/12/03(金) 09:06:26.24

ちなみに、HTTP/HTTPSで速度を上げるには、市販ダウンローダーが実装している、
分割パート毎にマルチセッションで同時ダウンロードして連結する方法もあるが、
ダウンロード先が同じサーバーで、アクセス遮断されないようにというのもあって
1セッションでのダウンロードにしてる。

本当はロボットであることを覚られないよう、ファイル単位のダウンロード完了後に
ランダムな秒数の待ち時間をいれるべきだろうが、今のところやってない。

**デフォルトの名無しさん** · 2021/12/03(金) 14:35:28.91

>>743
> 20Mbpsくらい。
ということは、毎秒2MBくらいのダウンロード能力があり、1分あたりでは120MB、1時間あたり7GBくらいはダウンロードできるということになる

> 1000個(総容量約3.5～3.7GB)ダウンロードすると2時間～
> 3時間くらいかな。
めちゃくちゃ遅くね？

**デフォルトの名無しさん** · 2021/12/03(金) 14:55:37.25

そもそもlibevとかlibeventとかはCで書かれたライブラリでC++用のリンクヘッダもあるけどNodeやRustの
専売特許じゃない、むしろ後発でC10k、promise、async/awaitだとかいってるアホは市んでほしい…
C/C++では現状コールバック関数でしかない。もちろんC++22とか出てきてないものは除く

**デフォルトの名無しさん** · 2021/12/03(金) 15:13:11.54

非同期プログラミングの先達という意味ではそうだけど
callback hell をなんとかするために生まれてきた promise や async/await にはそれはそれで価値を認めるべき

**デフォルトの名無しさん** · 2021/12/03(金) 15:17:25.21

>>745
時間帯によって速度は変わる。　MicrosoftからWindows 10のISOファイルを1つ
(ほぼ容量同じ)をWebブラウザで落としても、30分強で終わるどころか、ほぼ同じ
くらい掛かる。

**デフォルトの名無しさん** · 2021/12/03(金) 15:25:42.29

>>748
いや、それってMSのサーバ能力で律速されてるってことでしょ

そもそも
>> 通信専用のワーカスレッドを1つ作成して、
>> 順番に1000個のサーバヘアクセスに行くのが簡単かつ現実的じゃないかな。
>
> それは昔の同期プログラミングのマズいやり方でとてつもなく遅くなってしまう

に対する反論を試みようとしてるんだから、相手側の能力で律速するのなら「じゃやっぱマズいやり方だよね」ってことになるだろ

**デフォルトの名無しさん** · 2021/12/03(金) 15:35:13.37

まぁ、Softbank Airなんて回線で、数GBもダウンロードすなってのもあるがw

**デフォルトの名無しさん** · 2021/12/03(金) 15:52:47.63

別にasyncはコールバック関数を何とかするために生まれた訳じゃない、勘違い甚だしいｗ

同期関数という普通の関数と、見た目上は同様に見えるように考えられただけで価値なんてほんの少ししかない。
むしろこのキーワードの導入によりコードの汚染が酷く、さらに言うならI/Oバウンドや*nix割り込みベースや
そしてCPUバウンドな非同期（≒スレッド）と統一的に扱えないために複雑なフレームワークを導入する羽目になる。

一般的には、I/Oバウンドなブロック単位のI/O読み書き待ちでコールバックされることだけを主眼に置いて設計されて
しまったがために多くの言語で採用されているが、スレッドや軽量ルーチェンとは互換性ない場合が多い。

ただ副次的にコールバック関数のネストが解決されているように見えるだけに過ぎない。

**デフォルトの名無しさん** · 2021/12/03(金) 19:35:25.25

C10Kというけど、いま使ってるパソコンだってスレッドが数千あるのに、クライアントが1万程度でいまどき問題ある？

**デフォルトの名無しさん** · 2021/12/03(金) 20:15:24.75

有線LAN なら、200Mbps ぐらい出る。
無線にすると、10～20

無線スポットから離れると、1まで落ちる

**デフォルトの名無しさん** · 2021/12/03(金) 20:20:25.08

Elixir では、10万のプロセスを起動できる

これは、OS のプロセス・スレッドじゃないから。
Erlang 内の小プロセスだから出来る

**デフォルトの名無しさん** · 2021/12/03(金) 20:32:10.63

そんなに起動して何に使うの？

**デフォルトの名無しさん** · 2021/12/03(金) 20:45:06.44

ルーチェン

**デフォルトの名無しさん** · 2021/12/03(金) 22:07:37.69

>>751
非同期プログラミングの話をしているだけなのにそんなasync/awaitに限定するのがおかしいのではないかね
さらにいえばasync/awaitの話とpromise/futureの話を同類に捉えているからちゃんと理解していないのでは？
非同期関数をなにか特殊なもののように捉えているのも怪しい

非同期ブログラミングとは同期ブロッキングI/Oによる非効率で無駄な方法を排除するプログラミングであって
昔も今も中心部分にselectやepoll等のシステムコールを核とするループすなわち高度化した時のスケジューラーで成り立っている
そして読み書き可能になったら読み書きをするという極めて自然なプログラミング
もちろんこのスケジューラー部分で割り込みやタイマー含めて共通管理できるため「相性が悪く複雑になる」というのも間違いだ

もちろん読み書き可能になったら教えて！と最初に登録するところから始まるわけだから
読み書き可能になったぜ！と教えてもらう部分がコールバックとなるのは当然の話
だからそれをまとめて包んだ非同期関数は当然コールバックとなりI/O待ちブロックされる同期関数より極めて効率が良い

promise/futureはこの部分のインターフェース部分だけを抽象化しただけに過ぎず
この中身は単なる状態管理だから具体的なI/Oやタイマー等と関係なく共通して使える点もプログラミングの利便性を向上させている
そしてこれ自体はコールバックを無くしているわけではなく例えばクロージャを渡すメソッドなどを用意することでコードの見た目を改善している
これで非同期関数のインタフェースとして(直接)コールバック系と(間接に行う)promise/future系((およびその両対応))に分かれた

以上ここまでの話は生のC言語でも普通にプログラミング可能な話である (メソッド呼び出しを除く)
もちろんスレッドなんか存在しない環境でもシングルスレッドにて並行に動作するの非同期プログラミング
当然ながらマルチスレッドでも同じように動作させられる

**デフォルトの名無しさん** · 2021/12/03(金) 22:08:57.91

>>757の続き

一方でasync/awaitは全く別の話
これだけはプログラミング言語による支援がないと実現できない
そしてこの導入目的は同期プログラミングしか出来ない人たち向けも含めて楽に非同期プログラミングするためであり
asyncと宣言した関数などの中ではawaitを付ければ見かけ上は同期プログラミングと同じ記述ができる！という改革
これによりようやく真にコールバックが利用側からは消えたので「コールバックを無くすため」というのも間違ってはいない

ではasync/await導入で非同期関数側はどう変わったか？
実は全く変わっていない、が正解
そのままpromise/futureを返す非同期関数と全く同じそのままである
つまりasync/awaitは非同期関数を利用する側だけの話という点が重要

以上で>>751氏も非同期プログラミングを正しく理解できるであろうか？

**デフォルトの名無しさん** · 2021/12/03(金) 22:13:40.85

もはやC++もRustも関係無いマウント合戦になってら

**デフォルトの名無しさん** · 2021/12/03(金) 23:22:05.85

もしかしてずーっと同じ人が暴れてんですか？

**デフォルトの名無しさん** · 2021/12/03(金) 23:31:58.32

どうしようもない二人が残っちゃったね
掃き溜め

**デフォルトの名無しさん** · 2021/12/03(金) 23:40:57.15

Goスレでも同じC#おじさんがRust/Goを学びかけて暴れてたから同じやつ
「真にコールバックが利用側からは消えた」なんてコールバック関数が消えたことはない。お前はHello worldでも
書いて満足してろｗawaitの話とpromiseを同列に語ってんのもお前、「インターフェース部分だけを抽象化」なんて
RustにもC++にも無いしC#おじさん臭さが露骨に出てる

**デフォルトの名無しさん** · 2021/12/03(金) 23:59:21.97

＞当然ながらマルチスレッドでも同じように動作させられる
そんなのはC#のような一部であり、多くのasyncを有する言語ではスレッド境界は越えられないのでそれぞれの
スレッドがイベントループとイベントキューを有する。これはAスレッドで起こったイベントはBスレッドには
伝わらず”同じように動作させられる”なんてことは無い、実行の順序制御も当然バラバラ
C++20でもコルーチェンたるco_return, co_await, co_yieldがあるのに、鬼の首を取ったようにRustなどの
触りだけ触れていて優位性を語ってるアホはまじ市んでほしい

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

最近は、一度もWindowsプログラミングしたこと無い人が増えてるからな。
Windowsは伝統的に非同期をほとんど使わないことを知らない人が多いらしい。

**デフォルトの名無しさん** · 2021/12/04(土) 01:54:42.66

>>761
もともとrustスレで暴れてた人を隔離するために立てられたスレだから最初から掃きだめ

**デフォルトの名無しさん** · 2021/12/04(土) 03:17:48.45

>>763
＞＞当然ながらマルチスレッドでも同じように動作させられる
＞そんなのはC#のような一部であり、
＞多くのasyncを有する言語ではスレッド境界は越えられない

え？？
Rustでは当然出来ますけど

＞スレッド境界は越えられないので
＞それぞれのスレッドがイベントループとイベントキューを有する。

え？？
Rustではスレッド境界を超えつつ、それぞれのスレッドがイベントループとイベントキューを有することも出来ますけど

＞これはAスレッドで起こったイベントはBスレッドには伝わらず

そこだけは正しいですｗ
しかし暇になったスレッドがいわゆるワークスティーリングすなわち他スレッドからタスクを奪ってからイベント登録しますから、

＞”同じように動作させられる”なんてことは無い

同じように別スレッドで動作を継続できます

＞実行の順序制御も当然バラバラ

え？？
非同期だからバラしたタスク間の実行順序は例えば通信相手次第で変わりますけど
それは単純なワンタスク同期なマルチスレッドの時も同じです
実行の順序制御が必要な部分のみ制御の意味での同期を行うのも同じです
例えば10個のタスクで並行して10ヵ所からデータを取得してその平均を出すならば平均を出す直前で10個全てのタスクの完了を待つだけです

非同期プログラミングしたことがない人は間違った思い込み妄想だらけで大変

**デフォルトの名無しさん** · 2021/12/04(土) 03:24:28.87

Rust使ったこと無いけど健全なマクロはいいなぁと思う。

**デフォルトの名無しさん** · 2021/12/04(土) 03:28:16.65

今言われているasync, awaitの「非同期」ってちょっと違うけど、意味的には擬似スレッドみたいな感じだな。
I/O全般というより、XHRやfetchやsocketのように遅いネットワーク通信を複数同時に待つ時に使う
時に便利な気がする。
nativeのファイルI/Oの場合、処理が完了するまで待つ方が便利だし、余計なことを考えなくて済むので
バグが少なくできるから、伝統的に同期方式を使うことが基本。

**デフォルトの名無しさん** · 2021/12/04(土) 03:36:51.75

print "hello\n";
と書いた場合に、print文は端末(terminal)などの別プロセスでの処理が
完了するまで待つことが多く、実行完了するには時間が掛かるが、
これを一々非同期にして、print 文が完了するまでに別の処理をする、
というようなことはすべきじゃない。
一番いいのは、print 文が完了するまではそこで待機して、ちゃんと
それが完了してから次の文を実行すること。
つまり、同期的処理。

**デフォルトの名無しさん** · 2021/12/04(土) 03:52:52.03

>>769
え？？
awaitはその待機という同期的処理をするためにあります
したがって非同期のprint関数を呼んでも問題は起きずにその書かれてる通りになります

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

>>770
でもそのコード部分では見て無い場所で、イベントループに戻ってしまって、
別のイベントハンドラが起動してしまう可能性が生まれ、
せっかく通常のシングルスレッドプログラミングでは起きない良い特徴が失われる。
そのため、シングルスレッドなのに排他処理が必要となってしまう。
排他処理は間違うととても危険であって、プログラミングのかなり上級者でも
気を使う必要がある。

**デフォルトの名無しさん** · 2021/12/04(土) 04:28:23.02

見かけ上はどちらも関数処理完了まで待機する形で同じですが

「同期の関数を呼んだ場合」
　　→関数から戻って来るまでそのスレッドはブロックされる

「非同期の関数を呼んでawaitする場合」
　　→そのスレッドがブロックされることはなく他にタスクがあれば並行して実行される

>>771
いいえ
その場合はそのタイミングで並行して実行されたら困るタスクを持たなければいいだけです

○ その時は他に並行して実行されるタスクを持たない
○ 並行して実行されてもよいタスクだけを他に持つ
○ 並行して実行されるタスクの動作に制限がかかるようにロック等を持つ
✕ 並行して実行されたら困るタスクを対策なしに他に持つ

選択肢はたくさんあります
これがプログラミングです

**デフォルトの名無しさん** · 2021/12/04(土) 04:34:52.83

>>772
Win32/MFC/WinForms/JavaのSwing/Android/ブラウザのJSで
プログラミングしたこと有る？
イベントループやイベントって自分で定義するものでは無いから
「タスクを持たないようにする」
っていうのは現実には不可能だぞ。

**デフォルトの名無しさん** · 2021/12/04(土) 05:07:10.24

>>773
もちろんRustでも自分でスケジューラを自作することは滅多になく
selectやpollなど使用のイベントループを自分で書くことはありません
それからここでのイベントとは当然selectやpollなどのイベントですから具体的にはファイルディスクリプタの読み書きOK等がイベントとなります
もちろんこの処理はスケジューラが担当するので自分で書かなくてもいいです
しかし新たなタスクを起こすかどうかはスレッドの時と同様にプログラマーの自由であり必要なら明示的に行います

JavaScriptの場合もイベントループを管轄するスケジューラはブラウザでもNode.jsでもシステムとして持っているため関知しなくてもよいです
ただしJavaScriptでは非同期関数を呼ぶこと自体が自動的にここでいう新たなタスクを起こすことになります
あとは例えばブラウザ自体が暗黙的に動作しているタスクとしてみなすことも出来てそのタスクから新たなタスクを発火することもあります
リスナー登録するタイプの利用時もそのパターンです

**デフォルトの名無しさん** · 2021/12/04(土) 05:13:43.45

>>774
MFC/WinForms/JavaのSwing/Androidなどでは、マウスイベントやキーボードイベント、
メニューイベントは基本的に常時イネーブル状態になったままにして使うので、await
してしまうと、それぞれのハンドラに普通に入ってしまう。
そうなるとロジックが破綻するので排他処理するか、awaitする直前に、
一々ハンドラを disable にして、awaitの次の行に来た時に enableにする
必要がある。そんなメンドクサイことすべきじゃ無いし、そもそもdisable
にするなら、非同期のメリットも無い。
そもそもGUIスレッドは、イベントハンドラの二重起動は禁止すべきとされている。

**デフォルトの名無しさん** · 2021/12/04(土) 06:02:11.33

>>775
プログラミング分野は無数にある中で
なぜそんな特殊な環境だけを唐突に持ち出すのかも含めて分かりません
先ずは適用可能な分野から始めて経験と知識を積んで的確に判断できるようになってから結論づければよいかと

**デフォルトの名無しさん** · 2021/12/04(土) 10:01:49.43

数学の天才と言い切った手前、後に引けなくなってきたか
自分の触ったことのある範囲でいいから弁解しなくちゃ
もうリンクトリストなんてどうでもいい、無知の印象を払拭するのが第一

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

天才と言いつつテスト100点としか言えてない時点で程度は知れて馬鹿にされてるんだから今更取り繕わなくて良いのに

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

リンクリストの話はまだまだお聞きしたいと思っていますのに…
>>738 のリストのソートのご感想とか

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

>>778
数学や物理のテストは、B4 の白紙一枚をわたされて、これに回答とか証明を書け、みたいな感じですが、そんなテストで一度でも 100 点をとれるのなら、それはそれですごいとは思いますよ

**デフォルトの名無しさん** · 2021/12/04(土) 17:09:21.39

>>780
引き合いに出してたのがセンター試験だったり東大入試だったりで大学入試の成績を誇るしかない人なんだなって思っていました

**デフォルトの名無しさん** · 2021/12/04(土) 17:19:28.99

RustのLinked Listは遅いからRustはクソ言語

という論理は成立しましたか？

**デフォルトの名無しさん** · 2021/12/04(土) 17:28:22.69

>>781
回答用紙の返却のない試験の結果がどうしてわかるのか疑問ですよね

**デフォルトの名無しさん** · 2021/12/04(土) 17:40:33.98

どっちも中途半端な知識しかないのに他人の指摘は聞かないから救いようがない

隔離スレ立てたやつグッジョブ！

**デフォルトの名無しさん** · 2021/12/04(土) 18:40:15.11

>>773
あわしろ氏が言ってたけど、Win32ではメッセージループを自分で作るらしいですよ。
まあ、配送はDispatchMessage()でやってもらうんですが。

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

>>783
マジレスすると
点数はわかる

**デフォルトの名無しさん** · 2021/12/04(土) 18:49:24.09

>>785
Java の awt では、どこにメッセージループが隠れているのか、あわしろ氏に訊いていただけませんか？

**デフォルトの名無しさん** · 2021/12/04(土) 18:51:13.15

>>786
私の時代には、そういうのは転部転科でもしようとしない限りわからなかったかと、今は変わったんですね…

**デフォルトの名無しさん** · 2021/12/04(土) 18:51:48.09

>>787
了解です。
来週、職場で会うと思うので、聞いておきます。

**デフォルトの名無しさん** · 2021/12/04(土) 18:53:03.93

>>788
そう

**デフォルトの名無しさん** · 2021/12/04(土) 18:54:08.07

センター試験や東大入試は数学の天才を黙らせようとした人らが基準を示すため言い出したのであって
当の数学の天才は一度も何の試験かにすら言及していない
高校の定期試験ということもあり得る

**デフォルトの名無しさん** · 2021/12/04(土) 18:58:45.03

>>789
師が職場におられるとはうらやましいですね

**デフォルトの名無しさん** · 2021/12/04(土) 19:00:26.50

>>791
私はしませんが、仮に「自分は数学の天才である」と名乗りたいときに、どういう風に自分の天才性を形容するべきか、はいい演習課題になりますね
あまりマニアックなことをいってもスルーされるだけですし

**デフォルトの名無しさん** · 2021/12/04(土) 19:21:42.11

私は分かりやすく>>621
他には
東大後期模試300点
数学偏差値90
東大数学科卒
など

普通は
論文数/論文引用数/肩書き(教授など)/受賞歴/特許出願数
などが実績ですが
私はその辺の実績はありません

**デフォルトの名無しさん** · 2021/12/04(土) 19:24:17.53

残念ながら自称数学の天才には効かなかったようです

**デフォルトの名無しさん** · 2021/12/04(土) 19:27:28.34

アカデミー賞受賞最新作はどうでしょうか？
アカデミックな感じで。

**デフォルトの名無しさん** · 2021/12/04(土) 19:28:53.97

>>794
なんか生々しいんじゃないですか？もっとサラっとした感じでお願いします…

**デフォルトの名無しさん** · 2021/12/04(土) 19:43:56.41

数学の天才っていうとラマヌジャンとかそういう人？

**デフォルトの名無しさん** · 2021/12/04(土) 19:49:29.22

>>798
円の体積・表面積を算出したアルキメデスでしょう、ニュートンライプニッツの2000年ほど前の人

**デフォルトの名無しさん** · 2021/12/04(土) 21:07:23.15

CSの天才じゃなくて数学の天才名乗るのはなんでなんだろうな

**デフォルトの名無しさん** · 2021/12/04(土) 22:13:27.18

自信が無いんだよ

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

コンビニエンスストアの天才。

**デフォルトの名無しさん** · 2021/12/04(土) 22:29:30.68

>>800
鋭い視点ですね
オーダーの話と実時間の話をシレっと往ったり還ったりするところなんかは、私には変だと思いましたね、アルゴリズムの評価はオーダーで行うのが普通で他はほとんどみない…

>>799
×　円
○　球

**デフォルトの名無しさん** · 2021/12/04(土) 22:41:59.72

天才の心は、自分が天才になった時、初めて理解できるのではないでしょうか。

**デフォルトの名無しさん** · 2021/12/04(土) 23:15:15.65

見上げてErlang夜の星を

**デフォルトの名無しさん** · 2021/12/04(土) 23:41:44.19

美少女の国に行きたいが、美少女じゃないので入れない。

**デフォルトの名無しさん** · 2021/12/05(日) 10:16:06.18

>>804
>>799 の人は1000年以上も登場する時代を間違えた人だから、その孤独感たるや想像を絶するでしょうね…

**デフォルトの名無しさん** · 2021/12/05(日) 10:27:47.16

数学100点が自慢の自称天才と
歴史的に有名な超天才を比べる変なスレ

板的にはチューリングが出てこないのは変

**デフォルトの名無しさん** · 2021/12/05(日) 11:52:13.76

チューリングの話題はLGBT板で。

**デフォルトの名無しさん** · 2021/12/05(日) 12:45:24.80

じゃあ、モンティホール問題に納得できない人は、手を上げて。

**デフォルトの名無しさん** · 2021/12/05(日) 12:47:11.55

板違い

**デフォルトの名無しさん** · 2021/12/05(日) 13:23:53.66

良スレ。
アゲ。

**デフォルトの名無しさん** · 2021/12/05(日) 15:04:30.36

>>803
>オーダーの話と実時間の話をシレっと往ったり還ったりするところなんかは、私には変だと思いましたね、
>アルゴリズムの評価はオーダーで行うのが普通で他はほとんどみない…
書くのが長くなるからオーダーで書いているだけで、オーダーだけでは正しい特徴を捉えられない
場合がある。
例えば、同じオーダーでも乗算や条件分岐の両方が使われているアルゴリズムとマシン語の
1クロックの命令1個にコンパイルされるものでは全然違う。
また、N個のデータを持っているハッシュ構造は、1回の検索は、数学的に厳密にはO(N)
だが、実験的(実際的)にはO(1)のように振舞うと言われており、厳密に扱うには、
オーダーの記号だけでは表現しきれない。
もし、オーダーだけで評価すればいいのなら、チューリング完全なあらゆる言語は、
同じアルゴリズムを使うことは可能で、同じオーダーの時間で計算できてしまうから、
速度比較には役立たない。

**デフォルトの名無しさん** · 2021/12/05(日) 15:19:38.16

>>813
＞1回の検索は、数学的に厳密にはO(N)だが、実験的(実際的)にはO(1)のように振舞う
ハッシュテーブルの構築は O(N) ですが、既存のデータをハッシュで引く割合が多ければ多いほど O(1) に近くなるでしょう
ハッシュテーブルには衝突がつき物ですが、そういうところも厳密に評価するのは難しいかもしれませんね

ただし、

＞同じオーダーでも乗算や条件分岐の両方が使われているアルゴリズムとマシン語の
＞1クロックの命令1個にコンパイルされるものでは全然違う。

そのとおりですが、それは所詮 O(f) の f の係数が違うだけでしょう、というか、そういうものはケースバイケースで一般論には載せ難いかと
そもそもあなたは、Σクロック（命令種）、で近似的に評価しようとしてますが、その姿勢は評価しますが、CPU 内の RISC 変換と並列実行、投機実行等までは及んでおらず、ある意味これも粗粗の近似だと思います
CPU 種類やメモリ構成などによって大きく変わるのですから、オーダーでの評価にとどめておくのが妥当なのでは？

＞もし、オーダーだけで評価すればいいのなら、チューリング完全なあらゆる言語は、
＞同じアルゴリズムを使うことは可能で、同じオーダーの時間で計算できてしまうから、
＞速度比較には役立たない。

そりゃそうです、言語間の速度比較にオーダーを使う方が間違っています
総じて評価センスの問題かと

**デフォルトの名無しさん** · 2021/12/05(日) 15:34:15.66

>>810
高卒の私は、いくら考えても意味がわかりませんでした…

**デフォルトの名無しさん** · 2021/12/05(日) 16:04:00.19

>>814
>＞1回の検索は、数学的に厳密にはO(N)だが、実験的(実際的)にはO(1)のように振舞う
>ハッシュテーブルの構築は O(N) ですが、既存のデータをハッシュで引く割合が多ければ多いほど O(1) に近くなるでしょう

あなたは、>>813で
「また、N個のデータを持っているハッシュ構造は、1回の検索は、数学的に厳密にはO(N)
　だが、実験的(実際的)にはO(1)のように振舞うと言われており、厳密に扱うには、
　オーダーの記号だけでは表現しきれない。」
と書いてあることの意味が全く分かって無い。

秀才以上で無いと発言禁止だ。

**デフォルトの名無しさん** · 2021/12/05(日) 16:12:34.15

>>816
ハッシュ構造は、「一回の検索」でも、数学的には、O(N)の時間が掛かる。
ハッシュ構造へのデータの書き込みとは全く関係無い。
検索自体が、数学的にはO(N)なのだ。
しかし、実際問題は、Nが常識の範囲内の大きさではO(1)のように振舞うことが
分かっているので、とても高速。

数学的には、O(f(N))とは、Nを無限に大きくしても、処理時間をf(N)で割るとある
上限値未満であるという意味。ハッシュテーブルの検索は、Nを無限に大きくすると、
定数的ではないので、O(1)ではない。

なお、g(N)=O(f(N))のように書いた時の意味で定義されているが、左辺は関数で、
右辺は集合のようなもので、両辺が等しいという意味ではない。なので、記法として
O(1)=O(N)であるが、O(N)=O(1)ではない。

不定積分の等号も集合論的な意味であって、等しいという意味ではないと聞いたことが
あると思うが、それと同じような定義。

**デフォルトの名無しさん** · 2021/12/05(日) 16:15:03.84

>>817
[さらに補足]
なお、そもそも、等号 = の左辺に O(xxx)の記号は書くべきではないという説もある。

**デフォルトの名無しさん** · 2021/12/05(日) 16:36:22.78

実時間が重要なら黙ってベンチ出せや

**デフォルトの名無しさん** · 2021/12/05(日) 16:50:30.44

>>817
＞しかし、実際問題は、Nが常識の範囲内の大きさではO(1)のように振舞うことが分かっているので

それには理由があるのでしょう？その理由はなんですか？「振舞うことがわかっている」という観測事実のみが根拠とは到底考えられませんね
>>814 が間違っているのであれば、あなたの解釈はなんですか？

＞数学的には、O(f(N))とは、Nを無限に大きくしても、処理時間をf(N)で割るとある
＞上限値未満であるという意味。ハッシュテーブルの検索は、Nを無限に大きくすると、
＞定数的ではないので、O(1)ではない。

そりゃ、衝突が頻繁に発生するようになると、それを連鎖法で処理するか、あるいはオープンハッシュ法＆セカンドハッシュ関数で処理するか、
いずれにしても N がハッシュテーブルサイズに比して大きくなりすぎるとO(1)から程遠くなるでしょう
しかし、今はハッシュテーブルサイズが N に比してそんなに大きくないことが前提だと思っていましたが、そういうハッシュテーブルの重要な性質を無視して N→∞にいきなり振るとか、やはり実装経験が不足しているとしか考えられません

あなたには、オープンハッシュ法でも連鎖法でもいいから、一度実装してみることをお勧めします、そうすれば、そんな無茶な話をふったり出来ないはずです

**デフォルトの名無しさん** · 2021/12/05(日) 16:51:42.71

>>820
×今はハッシュテーブルサイズが N に比してそんなに大きくないことが前提だ
○今は N がハッシュテーブルサイズに比してそんなに大きくないことが前提だ

**デフォルトの名無しさん** · 2021/12/05(日) 18:19:46.95

INTEL Core N4200。

**デフォルトの名無しさん** · 2021/12/05(日) 19:15:19.02

この数学100点の人はプログラミングできないんだから、ベンチ出せは禁句だよ

**デフォルトの名無しさん** · 2021/12/05(日) 19:16:59.90

>>820
あなたは馬鹿すぎて議論が成立しない。
勉強しろ、とも言えない。
なぜなら、勉強しても無駄だと思うから。