Qiita 7 - キータぞ、来たぞ、キータだぞー (785ﾚｽ)
Qiita 7 - キータぞ、来たぞ、キータだぞー http://mevius.5ch.io/test/read.cgi/tech/1757733847/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
7: デフォルトの名無しさん [sage] 2025/09/14(日) 13:28:33.58 ID:ZqIkDajJ そもそもの話として、ひとつの記事の中で複数の関数が引数だとか配列の内容を書き換えるのかどうかとか仕様が合ってないから比較になってないのよね。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/7
8: デフォルトの名無しさん [] 2025/09/14(日) 13:42:25.65 ID:yOrWt/NI >>7 問題はそこだね ループでも書けるよとかの筋違いな批判は要らんて http://mevius.5ch.io/test/read.cgi/tech/1757733847/8
9: デフォルトの名無しさん [sage] 2025/09/14(日) 14:21:09.67 ID:ZqIkDajJ ・引数は配列を渡すのみ ・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない という条件にしたとして、繰り返しで書くより再帰のほうが良い書き方ができるだろうか? func ReverseArrayWithFor(arr []int) []int { n := len(arr) result := make([]int, n) for i := 0; i < n; i++ { result[i] = arr[n - i - 1] } return result } 「全ての点で再帰による表記が勝る」という人には再帰の素晴らしさをぜひ証明してほしいところだが口だけ番長だろうなあ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/9
10: デフォルトの名無しさん [sage] 2025/09/14(日) 15:20:41.57 ID:wFXoVVHv >>9 大昔からの古典すら知らない無知 LISPも知らないんだろうな http://mevius.5ch.io/test/read.cgi/tech/1757733847/10
11: デフォルトの名無しさん [sage] 2025/09/14(日) 15:24:57.73 ID:ZqIkDajJ GoとLISPの区別もつかない人とはなあｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/11
12: デフォルトの名無しさん [sage] 2025/09/14(日) 15:30:37.23 ID:ZqIkDajJ 記事のスライス操作版のコードは > // ReverseArrayWithSlice はスライス操作で配列を逆順にする（再帰） > func ReverseArrayWithSlice(arr []int) []int { > // ベースケース: 要素が1つ以下なら逆順にする必要なし > if len(arr) <= 1 { > return arr > } > > // 最初の要素を取り出し、残りを再帰的に逆順にしてから結合 > return append(ReverseArrayWithSlice(arr[1:]), arr[0]) > } 要素数1の配列を渡した場合は引数の配列をそのまま返してしまうので // ベースケース: 要素が0以下なら逆順にする必要なし if len(arr) <= 0 { とした方が良いな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/12
13: デフォルトの名無しさん [sage] 2025/09/14(日) 15:35:06.93 ID:ZqIkDajJ 試しに ・引数は配列を渡すのみ ・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない 再帰で書いてみたが func ReverseArray(arr []int) []int { n := len(arr) result := make([]int, n) copy(result, arr) var reverseArray func(int, int) reverseArray = func(start int, end int) { if start < end { result[start], result[end] = result[end], result[start] reverseArray(start + 1, end - 1) } } reverseArray(0, n - 1) return result } エレガントとは程遠いな。 ぜひLISP仕込みのエレガントな例をGoで書いて披露してほしいものだ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/13
14: デフォルトの名無しさん [sage] 2025/09/14(日) 17:50:25.98 ID:ZqIkDajJ ChatGPTに下記の質問投げたらそこそこ納得できる回答くれたわ。 「Go言語は末尾再帰はサポートされてるの?」 「末尾再帰最適化されないところでの再帰呼び出しは引数の範囲が不定だとスタックがどれくらい使われるかの予測はしづらいので要はGoでは引数の範囲が不定なところでの再帰呼び出しは使わない方が無難てことですね。」 「関数型言語で育った人とかで「再帰は繰り返し処理より常に正義」とかって人いるじゃない。ああいう人にはGoは辛いかもですね。」 「Lispにloopがサポートされても意地でも使わないとかの人いましたね。」 http://mevius.5ch.io/test/read.cgi/tech/1757733847/14
15: デフォルトの名無しさん [] 2025/09/14(日) 18:13:30.88 ID:pN1ZIB1N >>6 何言ってんの爆速ですわ http://mevius.5ch.io/test/read.cgi/tech/1757733847/15
16: デフォルトの名無しさん [sage] 2025/09/14(日) 18:45:10.81 ID:d1cvwZ2J ＞何言ってんの爆速ですわ コードと実行結果のひとつでも挙げりゃ良いのだけど、それができない人がなんか言ってる感じｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/16
17: デフォルトの名無しさん [sage] 2025/09/14(日) 19:42:15.05 ID:buQYk9+g >>13 下手すぎ 最初に丸ごとcopyする時点でプログラミングのセンスがない http://mevius.5ch.io/test/read.cgi/tech/1757733847/17
18: デフォルトの名無しさん [sage] 2025/09/14(日) 19:59:01.07 ID:d1cvwZ2J 丸ごとcopyしない>>17のセンスある実装に期待ｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/18
19: デフォルトの名無しさん [sage] 2025/09/14(日) 21:05:23.33 ID:gAWV5uS0 いつも的外れな記事批判を繰り返している連投クンは本気でわからないようだな 元データを改変せずに新たに逆順を返す再帰関数を書きたいのならば例えばこうする func ReverseArray(input []int) []int { if len(input) == 0 { return nil } else { return append(ReverseArray(input[1:]), input[0]) } } http://mevius.5ch.io/test/read.cgi/tech/1757733847/19
20: デフォルトの名無しさん [sage] 2025/09/15(月) 00:35:19.13 ID:aenReHhk >>19と他のコードでベンチマークしてみた。要素数は10から10000。 https://ideone.com/DZJosr > 10: > ReverseArray9: 0.000001 > ReverseArray13: 0.000000 > ReverseArray19: 0.000002 > 100: > ReverseArray9: 0.000000 > ReverseArray13: 0.000000 > ReverseArray19: 0.000016 > 1000: > ReverseArray9: 0.000002 > ReverseArray13: 0.000040 > ReverseArray19: 0.000104 > 10000: > ReverseArray9: 0.000011 > ReverseArray13: 0.000293 > ReverseArray19: 0.000958 http://mevius.5ch.io/test/read.cgi/tech/1757733847/20
21: デフォルトの名無しさん [sage] 2025/09/15(月) 00:39:24.47 ID:Wq0UyIVm エンジニアならベンチ結果で語るべきだよな！ http://mevius.5ch.io/test/read.cgi/tech/1757733847/21
22: デフォルトの名無しさん [sage] 2025/09/15(月) 00:41:02.81 ID:oHygyuIm 末尾再帰を自動的にループ化しないシステムもあれば appendするだけで毎回ムダに新たに別メモリを確保してしまうシステムもある Goは最悪だと実証された http://mevius.5ch.io/test/read.cgi/tech/1757733847/22
23: デフォルトの名無しさん [sage] 2025/09/15(月) 00:50:27.97 ID:cAmqpZFr このクソ仕様がGoの敗因っぽいね ＞appendは毎回新たなスライスを生成します http://mevius.5ch.io/test/read.cgi/tech/1757733847/23
24: デフォルトの名無しさん [sage] 2025/09/15(月) 08:10:37.10 ID:aenReHhk >>17が丸ごとcopyしないセンスある実装を晒してくれなかったので書いてみた。 func ReverseArray(arr []int) []int { n := len(arr) result := make([]int, n) var reverseArray func(int) reverseArray = func(i int) { if i < n { result[i] = arr[n - 1 - i] reverseArray(i + 1) } } reverseArray(0) return result } やはりセンスある感じではないな。素直に for で繰り返した方が素直な感じ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/24
25: デフォルトの名無しさん [sage] 2025/09/15(月) 08:16:11.29 ID:aenReHhk ベンチマーク結果 https://ideone.com/mBV6Jr > 10: > ReverseArray9: 0.000001 > ReverseArray13: 0.000001 > ReverseArray19: 0.000003 > ReverseArray24: 0.000000 > 100: > ReverseArray9: 0.000000 > ReverseArray13: 0.000001 > ReverseArray19: 0.000024 > ReverseArray24: 0.000001 > 1000: > ReverseArray9: 0.000003 > ReverseArray13: 0.000061 > ReverseArray19: 0.000143 > ReverseArray24: 0.000006 > 10000: > ReverseArray9: 0.000013 > ReverseArray13: 0.000446 > ReverseArray19: 0.001487 > ReverseArray24: 0.000060 ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/25
26: デフォルトの名無しさん [sage] 2025/09/15(月) 08:27:46.98 ID:aenReHhk ideone では Go のコンパイラが 1.12.1 と旧く、もっと新しい版(1.24.2)だと ReverseArray9 と ReverseArray24 の差は小さくなる模様。 https://godbolt.org/z/KW87qMWsf 出力コードも見ようとしたけどちょっと見る気起きないな。 main_ReverseArray19_pc0 の中で再帰呼び出ししてることは > CALL main.ReverseArray19(SB) 確認したが。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/26
27: デフォルトの名無しさん [sage] 2025/09/15(月) 08:41:05.40 ID:7N5dcPCF 一番シンプルにわかりやすい>>19を再帰呼び出しのままは厳しいな appendするたびに作り直すらしいGoの仕様が足を引っ張ってるのだろうか http://mevius.5ch.io/test/read.cgi/tech/1757733847/27
28: デフォルトの名無しさん [sage] 2025/09/15(月) 09:31:01.39 ID:G/lRv3X8 今のQiitaはこの程度の話すらコメ欄ではできないのがクソなんだよなあ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/28
29: デフォルトの名無しさん [sage] 2025/09/15(月) 12:47:17.00 ID:aenReHhk なんか同じパラメータでの呼び出しを2回繰り返すと ReverseArray13 と ReverseArray19 だけ 2回目の速度が向上するな? https://ideone.com/zLdldJ > 1000: > ReverseArray9: 0.000003 > ReverseArray13: 0.000089 > ReverseArray19: 0.000174 > ReverseArray24: 0.000007 > 1000: > ReverseArray9: 0.000004 > ReverseArray13: 0.000005 > ReverseArray19: 0.000016 > ReverseArray24: 0.000007 > 10000: > ReverseArray9: 0.000018 > ReverseArray13: 0.000574 > ReverseArray19: 0.001747 > ReverseArray24: 0.000059 > 10000: > ReverseArray9: 0.000024 > ReverseArray13: 0.000035 > ReverseArray19: 0.000207 > ReverseArray24: 0.000055 キャッシュの影響ではなさそうだがなんぞコレ? こういうのは楽しい。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/29
30: デフォルトの名無しさん [sage] 2025/09/15(月) 13:03:08.76 ID:aenReHhk 要素数を1000から1000刻みで増やしていくと6000でガクッとパフォーマンス落ちてるな。 https://ideone.com/2yAyfW 再帰呼び出しを深く行うことでスタックが足りなくなりスタック領域の拡張が行われそれでパフォーマンスが落ちてる気がする。 予めスタック領域が十分拡張されてれば ReverseArray13 と ReverseArray19 のパフォーマンスも 1回目から比較的マシになりそうな気がする。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/30
31: デフォルトの名無しさん [sage] 2025/09/15(月) 13:16:02.23 ID:aenReHhk 試しにmain()の先頭にスタック領域を拡張してくれそうな処理を入れてみた。 var enlarge func(int) enlarge = func(n int) { if n > 0 { enlarge(n - 1) } } enlarge(100000) 実行結果 https://ideone.com/cJl9AC > 1000: > ReverseArray9: 0.000005 > ReverseArray13: 0.000011 > ReverseArray19: 0.000028 > ReverseArray24: 0.000009 > 10000: > ReverseArray9: 0.000032 > ReverseArray13: 0.000048 > ReverseArray19: 0.000273 > ReverseArray24: 0.000110 こうかは ばつぐんだ！ http://mevius.5ch.io/test/read.cgi/tech/1757733847/31
32: デフォルトの名無しさん [sage] 2025/09/15(月) 13:23:08.72 ID:aenReHhk >>25で > ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。 というのは多分間違いで、ReverseArray24 の前に実行している ReverseArray13 や ReverseArray19 のお陰でスタック領域が予め拡張されていたため ReverseArray24 の実行でスタック領域拡張処理が発生しなかったことがパフォーマンスが案外良かったことの原因と思われる。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/32
33: デフォルトの名無しさん [sage] 2025/09/15(月) 19:24:06.27 ID:OSZOiNza IDコロコロ切り替えてる人は自分の投稿に自信がないのかな http://mevius.5ch.io/test/read.cgi/tech/1757733847/33
34: デフォルトの名無しさん [sage] 2025/09/15(月) 22:14:31.00 ID:wx2AhEF9 >>33 いや自信ないのはお前 いまはIDコロコロを言う流れでない 直前の投稿は同一IDで8件投稿してIDコロコロでない 安価なくIDコロコロと言われても何を言ってるのかわからない お前が自分の投稿に自信ないのは空気を読めず日本語が不自由だから http://mevius.5ch.io/test/read.cgi/tech/1757733847/34
35: デフォルトの名無しさん [sage] 2025/09/16(火) 01:27:30.19 ID:JSTZ1Kt/ IDコロコロに反応する人がいるのは面白いねえｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/35
36: デフォルトの名無しさん [] 2025/09/16(火) 02:12:35.47 ID:NVXmEvhV 図っ星 http://mevius.5ch.io/test/read.cgi/tech/1757733847/36
37: デフォルトの名無しさん [sage] 2025/09/16(火) 09:08:34.57 ID:zaWo9xwV Qiitaのコメ欄で有意義な議論ができない問題、バカなこと言ってる側が複垢使うとかで相手を攻撃的と通報する可能性までありそうだなｗ http://mevius.5ch.io/test/read.cgi/tech/1757733847/37
38: デフォルトの名無しさん [sage] 2025/09/16(火) 19:41:50.97 ID:Wr/gNYaO >>9や>>24のコードがダサくて>>19がシンプルなのは再帰の有無ではなくコードの抽象的な度合いが原因だと思う http://mevius.5ch.io/test/read.cgi/tech/1757733847/38
39: デフォルトの名無しさん [] 2025/09/17(水) 08:59:29.24 ID:JW/5kEOI 数学的に言うと Σ(Sigma) は 再帰の方が抽象的なんか？ ループでも等価だと思うんだが http://mevius.5ch.io/test/read.cgi/tech/1757733847/39
40: デフォルトの名無しさん [sage] 2025/09/17(水) 09:21:49.27 ID:0mQm0ojt >>38 再帰を使わないシンプルな版を書いて主張すれば良い http://mevius.5ch.io/test/read.cgi/tech/1757733847/40
41: デフォルトの名無しさん [sage] 2025/09/17(水) 09:26:43.33 ID:MzfCTW9l >>9 arr[n - i - 1]が不格好ではあるな http://mevius.5ch.io/test/read.cgi/tech/1757733847/41
42: デフォルトの名無しさん [sage] 2025/09/17(水) 10:55:53.14 ID:0mQm0ojt >>41 func ReverseArray(arr []int) []int { n := len(arr) result := make([]int, n) for i, j := 0, n - 1; i < n; i, j = i + 1, j - 1 { result[i] = arr[j] } return result } http://mevius.5ch.io/test/read.cgi/tech/1757733847/42
43: デフォルトの名無しさん [sage] 2025/09/17(水) 21:20:35.77 ID:0mQm0ojt しまったー！ ElixirChip初お目見え会今日だったじゃーん 忘れてたわー！ざーんねーん！ とか言ったりして。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/43
44: デフォルトの名無しさん [sage] 2025/09/17(水) 22:01:15.40 ID:+QFNSyi5 配列などの各要素を巡る抽象化はイテレータだよ 抽象化の役割分担がわかりやすいRustで説明すると 今回の各要素の順番を逆順にしたベクタを作る関数はこうなる fn reverse_value<T: Clone>(input: &[T]) -> Vec<T> { input .iter() // 各要素への参照を巡るイテレータ .rev() // それを逆順に巡る .cloned() // 各要素への参照から値を複製して値を得る .collect() // それらの値を今回は返り型で指定のVecへ収集 } このイテレータは各要素への参照(ポインタ)を動かしていくので 今回のように値を複製したい場合は.cloned()が必要となる それを無しにすると以下のように各要素への参照のベクタが得られる fn reverse_reference<T>(input: &[T]) -> Vec<&T> { input .iter() // 各要素への参照を巡るイテレータ .rev() // それを逆順に巡る .collect() // それらの参照を今回は返り型で指定のVecへ収集 } このように抽象化された各パーツを組み合わせることで 可読性と安全性と高速実行を両立させている http://mevius.5ch.io/test/read.cgi/tech/1757733847/44
45: デフォルトの名無しさん [sage] 2025/09/17(水) 22:14:21.95 ID:Iu+PtAN6 改行CRとLFの真実：MS-DOS・BIOS・WIN10での挙動比較 https://qiita.com/earthen94/items/9c1a1fb8e1c7a2f32432 > Windows10 > '\r'で行頭に戻ることは確認できましたが、'\n'では下の行に下がるだけでなく行頭に自動的に戻されてしまうようです。 '\n'で行頭に移動するのはC言語の仕様で「\n 改行（new line）現表示位置を次の行の最初の位置に移動する。」となってるからで、WindowsではユニバーサルCランタイム (UCRT)が標準出力をテキストモードでオープンしてるため '\n' が '\r' + '\n' に変換されるからで、さらに最近の Windows Terminal は '\n' の動作が行頭に移動するようなってるので、とか説明せんといかんのかな、メンドい。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/45
46: デフォルトの名無しさん [sage] 2025/09/17(水) 22:54:27.39 ID:Iu+PtAN6 せっかくなので>>44の関数のベンチマークをしてみた。 https://godbolt.org/z/KxYEdofWd reverse_value() のほうがちょっと速いのかな。 Rustって知らんけどblack_boxなんてあんのは面白いな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/46
47: デフォルトの名無しさん [sage] 2025/09/17(水) 23:13:57.67 ID:2et8KGNs >>46 参照型つまりアドレスたぶん64bitを収容と i32型つまり32bitを収容のサイズの異なる比較になってしまってないかね？ http://mevius.5ch.io/test/read.cgi/tech/1757733847/47
48: デフォルトの名無しさん [sage] 2025/09/18(木) 00:40:20.60 ID:sD2s9VAq for でぐるぐる回すとこんな感じかな。 fn reverse_array<T: Clone>(input: &[T]) -> Vec<T> { let mut result = Vec::with_capacity(input.len()); for i in (0..input.len()).rev() { result.push(input[i].clone()); } result } https://godbolt.org/z/5dc1KaWsd http://mevius.5ch.io/test/read.cgi/tech/1757733847/48
49: デフォルトの名無しさん [sage] 2025/09/18(木) 01:41:40.32 ID:sD2s9VAq 出力の関数名間違ってたので訂正 https://godbolt.org/z/Kb7b3hc6P http://mevius.5ch.io/test/read.cgi/tech/1757733847/49
50: デフォルトの名無しさん [sage] 2025/09/18(木) 16:56:30.82 ID:E/kzpuoF >>44 元のGoのコードがintの配列扱ってるのにジェネリック化してCloneで効率下げてるのなんで?? http://mevius.5ch.io/test/read.cgi/tech/1757733847/50
51: デフォルトの名無しさん [sage] 2025/09/18(木) 17:45:09.89 ID:530bwAJW >>50 Rustのジェネリックは効率を下げなくて従来の型指定した時と全く同じように動作することが特徴です RustのCloneとは参照先から値を複製することです 例えば32bit数値の場合ならばCPUによるメモリ/レジスタ⇔メモリ/レジスタ間のロードやセーブが複製であって必ず行われることなので効率が下がることはありません http://mevius.5ch.io/test/read.cgi/tech/1757733847/51
52: デフォルトの名無しさん [sage] 2025/09/18(木) 23:44:30.13 ID:aCgogNys Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね 安全性などはついでのオマケ http://mevius.5ch.io/test/read.cgi/tech/1757733847/52
53: デフォルトの名無しさん [sage] 2025/09/21(日) 18:14:05.85 ID:MlvLaXh2 再帰派、息してる? http://mevius.5ch.io/test/read.cgi/tech/1757733847/53
54: デフォルトの名無しさん [] 2025/09/21(日) 19:59:36.62 ID:kxRRh56H もれちんは再吃不能 http://mevius.5ch.io/test/read.cgi/tech/1757733847/54
55: デフォルトの名無しさん [sage] 2025/09/21(日) 19:59:57.80 ID:hyRHfdTv 天才すぎて再起不能 http://mevius.5ch.io/test/read.cgi/tech/1757733847/55
56: デフォルトの名無しさん [] 2025/09/21(日) 23:24:29.32 ID:wsaoMzy7 >>52 Rustは冗長なくせに変な略語や記号を多用するから可読性は低いよ。JavaとPerlの悪い所取り。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/56
57: デフォルトの名無しさん [sage] 2025/09/21(日) 23:46:21.39 ID:xj5a3FOL >>56 変な記号？ 記号は他の言語と同じ Rustはコードの抽象化に成功していて可読性も保守性も高い http://mevius.5ch.io/test/read.cgi/tech/1757733847/57
58: デフォルトの名無しさん [sage] 2025/09/22(月) 07:39:29.97 ID:2d/wDxg8 Rustの..と..=の違いはセンスないなあと思った。Rubyの..と...も同様。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/58
59: デフォルトの名無しさん [sage] 2025/09/22(月) 08:00:31.81 ID:01ZECo7h >>58 長さlenの連続体(スライス)のインデックスは0からlen-1になるのだから 0..lenが0以上len未満つまり0からlen-1を示すRustの仕様はセンスが良い これを一般的には半開区間と言い数学では[start, end)と表記しstartは含むがendは含まず利点が多い プログラミングでn個を処理するときにインデックスなどを i = 0 から i < n と書くがこれも半開区間でRustなら0..nの表記になる ごく稀にn+1個の処理をする i = 0 から i <= n を扱いたい時には対応する0..=nの表記ができる したがってRustの表記法がベストであることがよくわかる http://mevius.5ch.io/test/read.cgi/tech/1757733847/59
60: デフォルトの名無しさん [sage] 2025/09/22(月) 09:09:30.72 ID:2d/wDxg8 『Rust で書いたプログラムがなんか遅い』 Rustで..=を気軽にホイホイ使ってしまって「なんか遅い」と言ってる例。 抽象化の高い言語を使って何が起きてるか分かってないのも考えものだな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/60
61: デフォルトの名無しさん [sage] 2025/09/22(月) 09:16:25.38 ID:Ow6is+fL Rubyの .. はPascal と記法を合わせたもので、 ... は番兵を1つ外側に立たせておくくらいのイメージかな。 Rustの .. は、Pascac と記法を合わせることには拘らず、多用される番兵方式を少ない記号数で記述できる方が合理的という判断なんだろう。..= という記法のセンスの良し悪しは何とも言えないが。 どちらも内在的にはそれなりに合理的なんじゃないかな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/61
62: デフォルトの名無しさん [sage] 2025/09/22(月) 09:59:26.76 ID:ytnqyum6 Pascal方式は1発進と相性がよく1..nがn個になる Rust方式は0発進と相性がよく0..nがn個になる indexが0発進になる言語はRust方式が便利 http://mevius.5ch.io/test/read.cgi/tech/1757733847/62
63: デフォルトの名無しさん [sage] 2025/09/22(月) 10:11:48.70 ID:2d/wDxg8 Pascalは..もforも閉区間[a, b]で統一されてるし配列の添字の範囲も自由なので思想的にはシンプルだと思う。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/63
64: デフォルトの名無しさん [sage] 2025/09/22(月) 11:19:37.59 ID:XiCaSJNI 記述や可読性の差が大きい start..endの個数 【Rust】 end-start個 【Pascal】 end-start+1個 startからn個 【Rust】 start..(start+n) 【Pascal】 start..(start+n-1) このように間違えやすく見にくい+1や-1が 半開区間を採用のRustでは不要となる http://mevius.5ch.io/test/read.cgi/tech/1757733847/64
65: デフォルトの名無しさん [sage] 2025/09/22(月) 11:35:27.21 ID:0o6m1dEB Ruby の .. と ... はスッキリしているけど、老眼には辛いのよ。麻雀牌のニ萬と三萬よりさらに見分けづらいから。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/65
66: デフォルトの名無しさん [] 2025/09/22(月) 23:00:01.38 ID:AxN4Bvca >>59 ..は左右対称なので閉区間にしか見えず、それで右半開区間を表すのはバグの元となりやすい。 右半開区間は左右非対称の..<で表すのが妥当で、Swiftはそうしている。Swiftは閉区間が...で .が1個余分なのは良くないが。 閉区間を..で、右半開区間を..<で表せば、左半開区間を<..で、開区間を<..<で整合的に表せるし、 互いの見分けも容易だから合理的。もしC++が範囲演算子を導入するならこうしてもらいたい。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/66
67: デフォルトの名無しさん [sage] 2025/09/22(月) 23:50:00.52 ID:ci9fXj6N 前例に倣ったままにしとけめんどくせえ http://mevius.5ch.io/test/read.cgi/tech/1757733847/67
68: デフォルトの名無しさん [sage] 2025/09/23(火) 00:57:25.80 ID:0DVfn//v >>64 Rustの方式が優れてるね http://mevius.5ch.io/test/read.cgi/tech/1757733847/68
69: デフォルトの名無しさん [sage] 2025/09/23(火) 08:21:07.31 ID:ptEtOTO9 半開区間と閉区間の両方をサポートするならどちらも間違いようがない書き方にするべきだろう。Rustは閉区間を..=で表すなら半開区間は..<とでもすれば良かったな。 ..では「あれ? どっちだっけ?」と思ってしまう可能性がある。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/69
70: デフォルトの名無しさん [sage] 2025/09/23(火) 09:39:04.17 ID:BqTZOz5k コード内に使われる記号列として許容できるのは .. と ... までかなぁ（ただし、両方を採用すると、ぱっと見では見分けがつきにくいという問題がある）。..= とか ..< は、もちろんそれなりに合理的な考慮の上で採用されたんだろうけど、もう見た目で受け付けないわ。 Rustも基本的には .. を使えってことなんじゃない？ 一応、..= も用意してあるけど、どうしても必要なケースがあるなら使ってねくらいの位置付けに過ぎないと思う。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/70
71: デフォルトの名無しさん [sage] 2025/09/23(火) 10:03:23.14 ID:U5/crNyE 範囲を表すのは .. だけにして、含まれない端点にはマーカー文字をつけるという方法もありそうだけど、目立つ採用例がないってことはたぶん問題があるんだろうね。 1 .. 5 → 1から5まで 1 .. 5^ → 1から4まで http://mevius.5ch.io/test/read.cgi/tech/1757733847/71
72: デフォルトの名無しさん [sage] 2025/09/23(火) 15:33:33.09 ID:rmbzdEQk >>64 一見すると素人には閉区間が便利に見えてしまうけどそのような複雑化する害が多すぎるんだよな プログラミング言語としては半開区間が最適だ http://mevius.5ch.io/test/read.cgi/tech/1757733847/72
73: デフォルトの名無しさん [sage] 2025/09/23(火) 17:38:31.18 ID:ptEtOTO9 IDコロコロ君の投稿を容易に見分けられるようになってしまい残念な気持ち。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/73
74: デフォルトの名無しさん [sage] 2025/09/23(火) 19:08:43.70 ID:zU/q7UQ3 >>60 半開区間イテレータはゼロコスト抽象化が可能だけど、 閉区間イテレータはその仕様上どうしても枯渇フラグが別途必要となるため、 データサイズの増大とコード実行が遅くなってしまうからね。 閉区間イテレータは効率を求める場面ではタブーと教えるしかないよ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/74
75: デフォルトの名無しさん [sage] 2025/09/23(火) 19:13:50.59 ID:zU/q7UQ3 >>69 Rustはもともと効率のいい半開区間イテレータ「..」しかなくて、「..」以外の仕様でも半開区間が採用されているため、間違えることがないようにできているよ。 動作が遅くてもいいから欲しいとの要望により、閉区間イテレータ「..=」を後から追加したんだよ。 速度を気にする場所でこの変な記号「..=」を使うのは要注意と覚えれば大丈夫。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/75
76: デフォルトの名無しさん [sage] 2025/09/24(水) 04:44:51.44 ID:NxVT75eJ 歴史的な事情で対称性の悪い表記が存在するのって（その歴史を知らないと納得できないから）負の遺産だよね。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/76
77: デフォルトの名無しさん [] 2025/09/24(水) 09:37:45.93 ID:iLsvaA+I 古い言語は仕方ないね 新たな言語を作るならば歴史的な知見で誰もが半開区間ベースの言語仕様にするでしょう ①プログラムを書く上で便利 理由>>64 ②実行効率も良い 理由>>74 http://mevius.5ch.io/test/read.cgi/tech/1757733847/77
78: デフォルトの名無しさん [sage] 2025/09/25(木) 07:39:21.36 ID:rGEl0fht Pythonのrange(1,5)も1,2,3,4を意味する半開区間だよ http://mevius.5ch.io/test/read.cgi/tech/1757733847/78
79: デフォルトの名無しさん [sage] 2025/09/25(木) 08:04:45.13 ID:+zec6Qog 半開区間と閉区間の両方をサポートしてて紛らわしい表記になってるのが残念という話が理解できない人かな http://mevius.5ch.io/test/read.cgi/tech/1757733847/79
80: デフォルトの名無しさん [sage] 2025/09/25(木) 10:55:22.03 ID:qSe6mg1h Rustみたいに標準ライブラリ全体の仕様を半開区間で統一すれば間違えることもなく悩まずに済むのに http://mevius.5ch.io/test/read.cgi/tech/1757733847/80
81: デフォルトの名無しさん [sage] 2025/09/25(木) 11:16:52.45 ID:Wia1VUCr 要らない..=をサポートしてしまった為に糞化してしまったRust哀れ http://mevius.5ch.io/test/read.cgi/tech/1757733847/81
82: デフォルトの名無しさん [sage] 2025/09/25(木) 11:29:57.30 ID:qSe6mg1h >>81 糞化って何？ 意味がわからない http://mevius.5ch.io/test/read.cgi/tech/1757733847/82
83: デフォルトの名無しさん [] 2025/09/26(金) 10:22:57.69 ID:UkFmEBgM 確かに元から糞なものが糞化とは腹が痛い http://mevius.5ch.io/test/read.cgi/tech/1757733847/83
84: デフォルトの名無しさん [sage] 2025/09/26(金) 12:42:08.13 ID:X9xxY5lJ >>82 「糞化って何？」って何？ 意味がわからない 元から糞なものが糞になって糞化したと言っても意味が通る http://mevius.5ch.io/test/read.cgi/tech/1757733847/84
85: デフォルトの名無しさん [sage] 2025/09/26(金) 16:46:57.32 ID:IX+dZCHo >>82 ウンコになったってことだよ http://mevius.5ch.io/test/read.cgi/tech/1757733847/85
86: デフォルトの名無しさん [sage] 2025/09/26(金) 20:33:46.74 ID:/tXGYc/j >>64 それよりもっと重要なことが抜けてるぞ Pascal方式で避けられないそれら+1や-1がRust方式では不要となるだけでなく Rust方式では長さ0を特別扱いせずに自然に扱えることが最大の特徴 Rust方式は長さnがstart..(start + n)であるため 長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える Pascal方式は長さnがstart..(start + n -1)であるため 長さ0はstart..(start -1)になり左右逆転してしまう そのためこの不格好な逆転状態を長さ0とみなして扱うか 場合分けして長さ0を扱わないようにするか 場合分けして長さ0の時にnullとかnilとか空リストなど特別扱いする形になる http://mevius.5ch.io/test/read.cgi/tech/1757733847/86
87: デフォルトの名無しさん [sage] 2025/09/27(土) 00:25:32.78 ID:XX0uOJLH ＞長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える 長さ0を表現するのにstartが具体的な値持ってて自然てどういう理屈? http://mevius.5ch.io/test/read.cgi/tech/1757733847/87
88: デフォルトの名無しさん [sage] 2025/09/27(土) 00:31:44.56 ID:lQv27qFK >>87 長さ1や長さ2がstart違ってあちこちにあるように 長さ0もstart違ってあちこちに存在する http://mevius.5ch.io/test/read.cgi/tech/1757733847/88
89: デフォルトの名無しさん [sage] 2025/09/27(土) 00:43:10.07 ID:XX0uOJLH >>88 Pascalでstartの違う長さ0表して便利な例挙げてみて http://mevius.5ch.io/test/read.cgi/tech/1757733847/89
90: デフォルトの名無しさん [] 2025/09/27(土) 00:55:46.18 ID:B/IRYC2K >>87 Rustの..は性質の良い半開区間なので、 例えばstart..endを途中のmiddleの位置で分割すると、start..middleとmiddle..endの二つに綺麗に分かれる性質も持っているよ。 そしてそのmiddleの決定算出結果が処理内容や処理状況によっては、たまたまstartと一致することも出てくる。 その時、start..middleとmiddle..endの二つは、start..startとstart..endの二つに分かれて前者は長さ0になるね。 Rustでのプログラミングでも実際にこれはよく起きるよ。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/90
91: デフォルトの名無しさん [sage] 2025/09/27(土) 01:43:57.58 ID:XX0uOJLH >>90 区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/91
92: デフォルトの名無しさん [sage] 2025/09/27(土) 01:48:32.95 ID:XX0uOJLH 閉区間と半開区間のどちらにメリットがある場合もあり、Rustも閉区間をサポートしてるのに半開区間のみを持ち上げてるのは見識が狭いな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/92
93: デフォルトの名無しさん [] 2025/09/27(土) 02:17:11.42 ID:B/IRYC2K >>91 区間には必ずスタート位置を伴いますね。 そこから長さが2だったり長さが1だったり長さが0だったりするわけです。 長さ0の時だけスタート位置が無いのは不自然でしょう。 >>92 良い性質を備えていてメリットがあるのは半開区間でしょう。 Rustの標準APIは区間分割split_atなどでも半開区間を前提として処理されます。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/93
94: デフォルトの名無しさん [sage] 2025/09/27(土) 02:20:12.82 ID:u3EkYZLQ 『fast inverse square root (高速逆平方根) のようなトリックまとめ』 未定義動作コードの見本市みたいな記事。 C言語知りませんアピールか。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/94
95: デフォルトの名無しさん [sage] 2025/09/27(土) 07:25:01.25 ID:rUQ4UupW C言語なんて動きゃいいんだよ動きゃ http://mevius.5ch.io/test/read.cgi/tech/1757733847/95
96: デフォルトの名無しさん [sage] 2025/09/27(土) 08:53:18.36 ID:ItgajmGE 動きゃいいんだよ動きゃなんて言語でカーネルを作ってほしくない http://mevius.5ch.io/test/read.cgi/tech/1757733847/96
97: デフォルトの名無しさん [sage] 2025/09/27(土) 12:15:10.22 ID:HCtgOBXK 古いのから新しいのまであらゆるCPUで動きゃいいんだよ動きゃ http://mevius.5ch.io/test/read.cgi/tech/1757733847/97
98: デフォルトの名無しさん [sage] 2025/09/27(土) 13:57:37.59 ID:HvNJXk8w ＞動きゃいいんだよ動きゃ 動くかわからん未定義動作のコードにこういうこと言う奴は馬鹿 http://mevius.5ch.io/test/read.cgi/tech/1757733847/98
99: デフォルトの名無しさん [sage] 2025/09/27(土) 16:57:30.37 ID:1KNVq9e2 特定のCPU/GPU環境と断ってる C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え http://mevius.5ch.io/test/read.cgi/tech/1757733847/99
100: デフォルトの名無しさん [sage] 2025/09/27(土) 17:02:10.01 ID:mMYsldco CとC++はこの手の気持ち悪いオジサン湧くからほんと無理 http://mevius.5ch.io/test/read.cgi/tech/1757733847/100
101: デフォルトの名無しさん [sage] 2025/09/27(土) 17:19:12.43 ID:CHztWjoA >>94 その記事「特定のCPU/GPU環境」を書かないのが片手落ちやな http://mevius.5ch.io/test/read.cgi/tech/1757733847/101
102: デフォルトの名無しさん [sage] 2025/09/27(土) 20:09:28.90 ID:16nWnOPC >>100 直前に出たRustとC/C++の違いは C/C++はお前のようなバカにも理解できるように分かりやすく話してあげてることだぞ http://mevius.5ch.io/test/read.cgi/tech/1757733847/102
103: デフォルトの名無しさん [] 2025/09/27(土) 20:36:16.39 ID:jktxSQ82 >>77 半開区間で書く方が便利な場合があることを誰も否定してはいないだろう。一方、閉区間で 書く方が便利な場合もある。例えば1からnまでの自然数を表示したいときがそうだが、 半開区間しかないPythonではfor i in range(1, n + 1): print(i)なんてひねくれた書き方を 強要されるし効率も悪い（Pythonで効率を云々しても意味ないが）。だから、半開区間と 閉区間の両方の記法を提供するのが良い。 半開区間を表すのに左右対称な..を使うのは紛らわしいので不適切。Pascalなどで..で閉区間を 表す慣用が定着していたにもかかわらず、..で半開区間を表す愚行を最初にやらかしたのはDか。 その前車の轍をC#, Go, Rustが踏んでしまった。特に.NET兄弟のF#とPowerShellが..を閉区間で 既に使っていたのにC#が半開区間を表すのに..を導入してしまったのは大きな誤りだった。 Dはほぼ死語と化したから、..で半開区間を表す不適切な記法も消え去るべきだな。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/103
104: デフォルトの名無しさん [sage] 2025/09/27(土) 20:44:14.86 ID:CHztWjoA 閉区間ｲﾗﾈｴ http://mevius.5ch.io/test/read.cgi/tech/1757733847/104
105: デフォルトの名無しさん [sage] 2025/09/27(土) 21:04:56.86 ID:h+m11Qj8 閉区間を表す記号を用意すべきかどうかについてはそれぞれ考え方の違いがあるんだなと思うが、.. は左右対称だから閉区間にすべきというのは正直よく分からん理由付けだわ。Pascalだってそんな理由で .. を閉区間の記号にしたわけではないと思うが。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/105
106: デフォルトの名無しさん [] 2025/09/27(土) 21:10:34.65 ID:B/IRYC2K >>103 多くの言語が半開区間を基本として扱っている理由は、半開区間だけが優れた性質を備えていてプログラミングに適しているためだよ。 半開区間だけが、start～endは長さ start - endを示し、startから長さnはstart～(start + n)になり、長さ0をstart～startで示すことができ、start～endをstart～middleとmiddle～endの2つに分割できる。 間違えた古い言語に習うことなく、半開区間をstart:endやstart..endなど簡素に記述するそれらの言語C# Go Rust Pythonなどが正しいよ。 JavaScriptもarr.slice(start, end)は半開区間であり、半開区間を基本とする言語が多数派だね。 http://mevius.5ch.io/test/read.cgi/tech/1757733847/106
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 679 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.028s