25/09/14 01:56:40.69 CZ0V8fQ4.net
『【Go】配列を再帰的に逆順にするサンプルコードを書いてみた』
> 再帰を使うことで、ループを使わずにエレガントに実装できる。
根本的なところで誤解してる人な模様。
3:デフォルトの名無しさん
25/09/14 02:53:44.41 bGojT+ur.net
>>2
一般論として
再帰で表現した方が抽象度が高く理解しやすく定義そのまま表現できることが多い
特に末尾再帰をコンパイラがループへ変換してくれて実行効率が同等ならば全ての点で再帰による表記が勝る
4:デフォルトの名無しさん
25/09/14 12:10:16.28 RhzWmJy7.net
入力配列と出力配列渡してループで処理するわ
5:デフォルトの名無しさん
25/09/14 12:59:52.05 ZqIkDajJ.net
記事の再帰版のコードは
> func ReverseArray(arr []int, start, end int) []int {
> // ベースケース: 配列の中央に到達したら終了
> if start >= end {
> return arr
> }
>
> // 要素を交換
> arr[start], arr[end] = arr[end], arr[start]
>
> // 再帰呼び出し: 範囲を狭めて継続
> return ReverseArray(arr, start+1, end-1)
> }
引数で渡した配列の内容書き換えるんでreturn要らないんだよなあ。
再帰で書くよか繰り返しで書いた方が余程シンプルとも思う。
func ReverseArrayWithFor(arr []int, start, end int) {
for start < end {
arr[start], arr[end] = arr[end], arr[start]
start += 1
end -= 1
}
}
6:デフォルトの名無しさん
25/09/14 13:06:57.84 ZqIkDajJ.net
記事のスライス操作版のコードは
> // ReverseArrayWithSlice はスライス操作で配列を逆順にする（再帰）
> func ReverseArrayWithSlice(arr []int) []int {
> // ベースケース: 要素が1つ以下なら逆順にする必要なし
> if len(arr) <= 1 {
> return arr
> }
>
> // 最初の要素を取り出し、残りを再帰的に逆順にしてから結合
> return append(ReverseArrayWithSlice(arr[1:]), arr[0])
> }
引数の配列内容を書き換えないし再帰を説明する上では面白い例だと思うが、パフォーマンスは最低だ罠。
7:デフォルトの名無しさん
25/09/14 13:28:33.58 ZqIkDajJ.net
そもそもの話として、ひとつの記事の中で複数の関数が引数だとか配列の内容を書き換えるのかどうかとか仕様が合ってないから比較になってないのよね。
8:デフォルトの名無しさん
25/09/14 13:42:25.65 yOrWt/NI.net
>>7
問題はそこだね
ループでも書けるよとかの筋違いな批判は要らんて
9:デフォルトの名無しさん
25/09/14 14:21:09.67 ZqIkDajJ.net
・引数は配列を渡すのみ
・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない
という条件にしたとして、繰り返しで書くより再帰のほうが良い書き方ができるだろうか?
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
}
「全ての点で再帰による表記が勝る」という人には再帰の素晴らしさをぜひ証明してほしいところだが口だけ番長だろうなあ。
10:デフォルトの名無しさん
25/09/14 15:20:41.57 wFXoVVHv.net
>>9
大昔からの古典すら知らない無知
LISPも知らないんだろうな
11:デフォルトの名無しさん
25/09/14 15:24:57.73 ZqIkDajJ.net
GoとLISPの区別もつかない人とはなあｗ
12:デフォルトの名無しさん
25/09/14 15:30:37.23 ZqIkDajJ.net
記事のスライス操作版のコードは
> // 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 {
とした方が良いな。
13:デフォルトの名無しさん
25/09/14 15:35:06.93 ZqIkDajJ.net
試しに
・引数は配列を渡すのみ
・内容を逆にした配列を返し、引数で渡した配列の内容は書き換えない
再帰で書いてみたが
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で書いて披露してほしいものだ。
14:デフォルトの名無しさん
25/09/14 17:50:25.98 ZqIkDajJ.net
ChatGPTに下記の質問投げたらそこそこ納得できる回答くれたわ。
「Go言語は末尾再帰はサポートされてるの?」
「末尾再帰最適化されないところでの再帰呼び出しは引数の範囲が不定だとスタックがどれくらい使われるかの予測はしづらいので要はGoでは引数の範囲が不定なところでの再帰呼び出しは使わない方が無難てことですね。」
「関数型言語で育った人とかで「再帰は繰り返し処理より常に正義」とかって人いるじゃない。ああいう人にはGoは辛いかもですね。」
「Lispにloopがサポートされても意地でも使わないとかの人いましたね。」
15:デフォルトの名無しさん
25/09/14 18:13:30.88 pN1ZIB1N.net
>>6
何言ってんの爆速ですわ
16:デフォルトの名無しさん
25/09/14 18:45:10.81 d1cvwZ2J.net
＞何言ってんの爆速ですわ
コードと実行結果のひとつでも挙げりゃ良いのだけど、それができない人がなんか言ってる感じｗ
17:デフォルトの名無しさん
25/09/14 19:42:15.05 buQYk9+g.net
>>13
下手すぎ
最初に丸ごとcopyする時点でプログラミングのセンスがない
18:デフォルトの名無しさん
25/09/14 19:59:01.07 d1cvwZ2J.net
丸ごとcopyしない>>17のセンスある実装に期待ｗ
19:デフォルトの名無しさん
25/09/14 21:05:23.33 gAWV5uS0.net
いつも的外れな記事批判を繰り返している連投クンは本気でわからないようだな
元データを改変せずに新たに逆順を返す再帰関数を書きたいのならば例えばこうする
func ReverseArray(input []int) []int {
if len(input) == 0 {
return nil
} else {
return append(ReverseArray(input[1:]), input[0])
}
}
20:デフォルトの名無しさん
25/09/15 00:35:19.13 aenReHhk.net
>>19と他のコードでベンチマークしてみた。要素数は10から10000。
URLﾘﾝｸ(ideone.com)
> 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
21:デフォルトの名無しさん
25/09/15 00:39:24.47 Wq0UyIVm.net
エンジニアならベンチ結果で語るべきだよな！
22:デフォルトの名無しさん
25/09/15 00:41:02.81 oHygyuIm.net
末尾再帰を自動的にループ化しないシステムもあれば
appendするだけで毎回ムダに新たに別メモリを確保してしまうシステムもある
Goは最悪だと実証された
23:デフォルトの名無しさん
25/09/15 00:50:27.97 cAmqpZFr.net
このクソ仕様がGoの敗因っぽいね
＞appendは毎回新たなスライスを生成します
24:デフォルトの名無しさん
25/09/15 08:10:37.10 aenReHhk.net
>>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 で繰り返した方が素直な感じ。
25:デフォルトの名無しさん
25/09/15 08:16:11.29 aenReHhk.net
ベンチマーク結果
URLﾘﾝｸ(ideone.com)
> 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が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。
26:デフォルトの名無しさん
25/09/15 08:27:46.98 aenReHhk.net
ideone では Go のコンパイラが 1.12.1 と旧く、もっと新しい版(1.24.2)だと ReverseArray9 と ReverseArray24 の差は小さくなる模様。
URLﾘﾝｸ(godbolt.org)
出力コードも見ようとしたけどちょっと見る気起きないな。
main_ReverseArray19_pc0 の中で再帰呼び出ししてることは
> CALL main.ReverseArray19(SB)
確認したが。
27:デフォルトの名無しさん
25/09/15 08:41:05.40 7N5dcPCF.net
一番シンプルにわかりやすい>>19を再帰呼び出しのままは厳しいな
appendするたびに作り直すらしいGoの仕様が足を引っ張ってるのだろうか
28:デフォルトの名無しさん
25/09/15 09:31:01.39 G/lRv3X8.net
今のQiitaはこの程度の話すらコメ欄ではできないのがクソなんだよなあ。
29:デフォルトの名無しさん
25/09/15 12:47:17.00 aenReHhk.net
なんか同じパラメータでの呼び出しを2回繰り返すと ReverseArray13 と ReverseArray19 だけ 2回目の速度が向上するな?
URLﾘﾝｸ(ideone.com)
> 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
キャッシュの影響ではなさそうだがなんぞコレ? こういうのは楽しい。
30:デフォルトの名無しさん
25/09/15 13:03:08.76 aenReHhk.net
要素数を1000から1000刻みで増やしていくと6000でガクッとパフォーマンス落ちてるな。
URLﾘﾝｸ(ideone.com)
再帰呼び出しを深く行うことでスタックが足りなくなりスタック領域の拡張が行われそれでパフォーマンスが落ちてる気がする。
予めスタック領域が十分拡張されてれば ReverseArray13 と ReverseArray19 のパフォーマンスも 1回目から比較的マシになりそうな気がする。
31:デフォルトの名無しさん
25/09/15 13:16:02.23 aenReHhk.net
試しにmain()の先頭にスタック領域を拡張してくれそうな処理を入れてみた。
var enlarge func(int)
enlarge = func(n int) {
if n > 0 {
enlarge(n - 1)
}
}
enlarge(100000)
実行結果
URLﾘﾝｸ(ideone.com)
> 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
こうかは ばつぐんだ！
32:デフォルトの名無しさん
25/09/15 13:23:08.72 aenReHhk.net
>>25で
> ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。
というのは多分間違いで、ReverseArray24 の前に実行している ReverseArray13 や ReverseArray19 のお陰でスタック領域が予め拡張されていたため ReverseArray24 の実行でスタック領域拡張処理が発生しなかったことがパフォーマンスが案外良かったことの原因と思われる。
33:デフォルトの名無しさん
25/09/15 19:24:06.27 OSZOiNza.net
IDコロコロ切り替えてる人は自分の投稿に自信がないのかな
34:デフォルトの名無しさん
25/09/15 22:14:31.00 wx2AhEF9.net
>>33
いや自信ないのはお前
いまはIDコロコロを言う流れでない
直前の投稿は同一IDで8件投稿してIDコロコロでない
安価なくIDコロコロと言われても何を言ってるのかわからない
お前が自分の投稿に自信ないのは空気を読めず日本語が不自由だから
35:デフォルトの名無しさん
25/09/16 01:27:30.19 JSTZ1Kt/.net
IDコロコロに反応する人がいるのは面白いねえｗ
36:デフォルトの名無しさん
25/09/16 02:12:35.47 NVXmEvhV.net
図っ星
37:デフォルトの名無しさん
25/09/16 09:08:34.57 zaWo9xwV.net
Qiitaのコメ欄で有意義な議論ができない問題、バカなこと言ってる側が複垢使うとかで相手を攻撃的と通報する可能性までありそうだなｗ
38:デフォルトの名無しさん
25/09/16 19:41:50.97 Wr/gNYaO.net
>>9や>>24のコードがダサくて>>19がシンプルなのは再帰の有無ではなくコードの抽象的な度合いが原因だと思う
39:デフォルトの名無しさん
25/09/17 08:59:29.24 JW/5kEOI.net
数学的に言うと Σ(Sigma) は
再帰の方が抽象的なんか？
ループでも等価だと思うんだが
40:デフォルトの名無しさん
25/09/17 09:21:49.27 0mQm0ojt.net
>>38
再帰を使わないシンプルな版を書いて主張すれば良い
41:デフォルトの名無しさん
25/09/17 09:26:43.33 MzfCTW9l.net
>>9
arr[n - i - 1]が不格好ではあるな
42:デフォルトの名無しさん
25/09/17 10:55:53.14 0mQm0ojt.net
>>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
}
43:デフォルトの名無しさん
25/09/17 21:20:35.77 0mQm0ojt.net
しまったー！
ElixirChip初お目見え会今日だったじゃーん
忘れてたわー！ざーんねーん！
とか言ったりして。
44:デフォルトの名無しさん
25/09/17 22:01:15.40 +QFNSyi5.net
配列などの各要素を巡る抽象化はイテレータだよ
抽象化の役割分担がわかりやすい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へ収集
}
このように抽象化された各パーツを組み合わせることで
可読性と安全性と高速実行を両立させている
45:デフォルトの名無しさん
25/09/17 22:14:21.95 Iu+PtAN6.net
改行CRとLFの真実：MS-DOS・BIOS・WIN10での挙動比較
URLﾘﾝｸ(qiita.com)
> Windows10
> '\r'で行頭に戻ることは確認できましたが、'\n'では下の行に下がるだけでなく行頭に自動的に戻されてしまうようです。
'\n'で行頭に移動するのはC言語の仕様で「\n 改行（new line）現表示位置を次の行の最初の位置に移動する。」となってるからで、WindowsではユニバーサルCランタイム (UCRT)が標準出力をテキストモードでオープンしてるため '\n' が '\r' + '\n' に変換されるからで、さらに最近の Windows Terminal は '\n' の動作が行頭に移動するようなってるので、とか説明せんといかんのかな、メンドい。
46:デフォルトの名無しさん
25/09/17 22:54:27.39 Iu+PtAN6.net
せっかくなので>>44の関数のベンチマークをしてみた。
URLﾘﾝｸ(godbolt.org)
reverse_value() のほうがちょっと速いのかな。
Rustって知らんけどblack_boxなんてあんのは面白いな。
47:デフォルトの名無しさん
25/09/17 23:13:57.67 2et8KGNs.net
>>46
参照型つまりアドレスたぶん64bitを収容と
i32型つまり32bitを収容のサイズの異なる比較になってしまってないかね？
48:デフォルトの名無しさん
25/09/18 00:40:20.60 sD2s9VAq.net
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
}
URLﾘﾝｸ(godbolt.org)
49:デフォルトの名無しさん
25/09/18 01:41:40.32 sD2s9VAq.net
出力の関数名間違ってたので訂正
URLﾘﾝｸ(godbolt.org)
50:デフォルトの名無しさん
25/09/18 16:56:30.82 E/kzpuoF.net
>>44
元のGoのコードがintの配列扱ってるのにジェネリック化してCloneで効率下げてるのなんで??
51:デフォルトの名無しさん
25/09/18 17:45:09.89 530bwAJW.net
>>50
Rustのジェネリックは効率を下げなくて従来の型指定した時と全く同じように動作することが特徴です
RustのCloneとは参照先から値を複製することです
例えば32bit数値の場合ならばCPUによるメモリ/レジスタ⇔メモリ/レジスタ間のロードやセーブが複製であって必ず行われることなので効率が下がることはありません
52:デフォルトの名無しさん
25/09/18 23:44:30.13 aCgogNys.net
Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
安全性などはついでのオマケ
53:デフォルトの名無しさん
25/09/21 18:14:05.85 MlvLaXh2.net
再帰派、息してる?
54:デフォルトの名無しさん
25/09/21 19:59:36.62 kxRRh56H.net
もれちんは再吃不能
55:デフォルトの名無しさん
25/09/21 19:59:57.80 hyRHfdTv.net
天才すぎて再起不能
56:デフォルトの名無しさん
25/09/21 23:24:29.32 wsaoMzy7.net
>>52
Rustは冗長なくせに変な略語や記号を多用するから可読性は低いよ。JavaとPerlの悪い所取り。
57:デフォルトの名無しさん
25/09/21 23:46:21.39 xj5a3FOL.net
>>56
変な記号？
記号は他の言語と同じ
Rustはコードの抽象化に成功していて可読性も保守性も高い
58:デフォルトの名無しさん
25/09/22 07:39:29.97 2d/wDxg8.net
Rustの..と..=の違いはセンスないなあと思った。Rubyの..と...も同様。
59:デフォルトの名無しさん
25/09/22 08:00:31.81 01ZECo7h.net
>>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の表記法がベストであることがよくわかる
60:デフォルトの名無しさん
25/09/22 09:09:30.72 2d/wDxg8.net
『Rust で書いたプログラムがなんか遅い』
Rustで..=を気軽にホイホイ使ってしまって「なんか遅い」と言ってる例。
抽象化の高い言語を使って何が起きてるか分かってないのも考えものだな。
61:デフォルトの名無しさん
25/09/22 09:16:25.38 Ow6is+fL.net
Rubyの .. はPascal と記法を合わせたもので、 ... は番兵を1つ外側に立たせておくくらいのイメージかな。
Rustの .. は、Pascac と記法を合わせることには拘らず、多用される番兵方式を少ない記号数で記述できる方が合理的という判断なんだろう。..= という記法のセンスの良し悪しは何とも言えないが。
どちらも内在的にはそれなりに合理的なんじゃないかな。
62:デフォルトの名無しさん
25/09/22 09:59:26.76 ytnqyum6.net
Pascal方式は1発進と相性がよく1..nがn個になる
Rust方式は0発進と相性がよく0..nがn個になる
indexが0発進になる言語はRust方式が便利
63:デフォルトの名無しさん
25/09/22 10:11:48.70 2d/wDxg8.net
Pascalは..もforも閉区間[a, b]で統一されてるし配列の添字の範囲も自由なので思想的にはシンプルだと思う。
64:デフォルトの名無しさん
25/09/22 11:19:37.59 XiCaSJNI.net
記述や可読性の差が大きい
start..endの個数
【Rust】 end-start個
【Pascal】 end-start+1個
startからn個
【Rust】 start..(start+n)
【Pascal】 start..(start+n-1)
このように間違えやすく見にくい+1や-1が
半開区間を採用のRustでは不要となる
65:デフォルトの名無しさん
25/09/22 11:35:27.21 0o6m1dEB.net
Ruby の .. と ... はスッキリしているけど、老眼には辛いのよ。麻雀牌のニ萬と三萬よりさらに見分けづらいから。
66:デフォルトの名無しさん
25/09/22 23:00:01.38 AxN4Bvca.net
>>59
..は左右対称なので閉区間にしか見えず、それで右半開区間を表すのはバグの元となりやすい。
右半開区間は左右非対称の..<で表すのが妥当で、Swiftはそうしている。Swiftは閉区間が...で
.が1個余分なのは良くないが。
閉区間を..で、右半開区間を..<で表せば、左半開区間を<..で、開区間を<..<で整合的に表せるし、
互いの見分けも容易だから合理的。もしC++が範囲演算子を導入するならこうしてもらいたい。
67:デフォルトの名無しさん
25/09/22 23:50:00.52 ci9fXj6N.net
前例に倣ったままにしとけめんどくせえ
68:デフォルトの名無しさん
25/09/23 00:57:25.80 0DVfn//v.net
>>64
Rustの方式が優れてるね
69:デフォルトの名無しさん
25/09/23 08:21:07.31 ptEtOTO9.net
半開区間と閉区間の両方をサポートするならどちらも間違いようがない書き方にするべきだろう。Rustは閉区間を..=で表すなら半開区間は..<とでもすれば良かったな。
..では「あれ? どっちだっけ?」と思ってしまう可能性がある。
70:デフォルトの名無しさん
25/09/23 09:39:04.17 BqTZOz5k.net
コード内に使われる記号列として許容できるのは .. と ... までかなぁ（ただし、両方を採用すると、ぱっと見では見分けがつきにくいという問題がある）。..= とか ..< は、もちろんそれなりに合理的な考慮の上で採用されたんだろうけど、もう見た目で受け付けないわ。
Rustも基本的には .. を使えってことなんじゃない？ 一応、..= も用意してあるけど、どうしても必要なケースがあるなら使ってねくらいの位置付けに過ぎないと思う。
71:デフォルトの名無しさん
25/09/23 10:03:23.14 U5/crNyE.net
範囲を表すのは .. だけにして、含まれない端点にはマーカー文字をつけるという方法もありそうだけど、目立つ採用例がないってことはたぶん問題があるんだろうね。
1 .. 5 → 1から5まで
1 .. 5^ → 1から4まで
72:デフォルトの名無しさん
25/09/23 15:33:33.09 rmbzdEQk.net
>>64
一見すると素人には閉区間が便利に見えてしまうけどそのような複雑化する害が多すぎるんだよな
プログラミング言語としては半開区間が最適だ
73:デフォルトの名無しさん
25/09/23 17:38:31.18 ptEtOTO9.net
IDコロコロ君の投稿を容易に見分けられるようになってしまい残念な気持ち。
74:デフォルトの名無しさん
25/09/23 19:08:43.70 zU/q7UQ3.net
>>60
半開区間イテレータはゼロコスト抽象化が可能だけど、
閉区間イテレータはその仕様上どうしても枯渇フラグが別途必要となるため、
データサイズの増大とコード実行が遅くなってしまうからね。
閉区間イテレータは効率を求める場面ではタブーと教えるしかないよ。
75:デフォルトの名無しさん
25/09/23 19:13:50.59 zU/q7UQ3.net
>>69
Rustはもともと効率のいい半開区間イテレータ「..」しかなくて、「..」以外の仕様でも半開区間が採用されているため、間違えることがないようにできているよ。
動作が遅くてもいいから欲しいとの要望により、閉区間イテレータ「..=」を後から追加したんだよ。
速度を気にする場所でこの変な記号「..=」を使うのは要注意と覚えれば大丈夫。
76:デフォルトの名無しさん
25/09/24 04:44:51.44 NxVT75eJ.net
歴史的な事情で対称性の悪い表記が存在するのって（その歴史を知らないと納得できないから）負の遺産だよね。
77:デフォルトの名無しさん
25/09/24 09:37:45.93 iLsvaA+I.net
古い言語は仕方ないね
新たな言語を作るならば歴史的な知見で誰もが半開区間ベースの言語仕様にするでしょう
①プログラムを書く上で便利 理由>>64
②実行効率も良い 理由>>74
78:デフォルトの名無しさん
25/09/25 07:39:21.36 rGEl0fht.net
Pythonのrange(1,5)も1,2,3,4を意味する半開区間だよ
79:デフォルトの名無しさん
25/09/25 08:04:45.13 +zec6Qog.net
半開区間と閉区間の両方をサポートしてて紛らわしい表記になってるのが残念という話が理解できない人かな
80:デフォルトの名無しさん
25/09/25 10:55:22.03 qSe6mg1h.net
Rustみたいに標準ライブラリ全体の仕様を半開区間で統一すれば間違えることもなく悩まずに済むのに
81:デフォルトの名無しさん
25/09/25 11:16:52.45 Wia1VUCr.net
要らない..=をサポートしてしまった為に糞化してしまったRust哀れ
82:デフォルトの名無しさん
25/09/25 11:29:57.30 qSe6mg1h.net
>>81
糞化って何？
意味がわからない
83:デフォルトの名無しさん
25/09/26 10:22:57.69 UkFmEBgM.net
確かに元から糞なものが糞化とは腹が痛い
84:デフォルトの名無しさん
25/09/26 12:42:08.13 X9xxY5lJ.net
>>82
「糞化って何？」って何？
意味がわからない
元から糞なものが糞になって糞化したと言っても意味が通る
85:デフォルトの名無しさん
25/09/26 16:46:57.32 IX+dZCHo.net
>>82
ウンコになったってことだよ
86:デフォルトの名無しさん
25/09/26 20:33:46.74 /tXGYc/j.net
>>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とか空リストなど特別扱いする形になる
87:デフォルトの名無しさん
25/09/27 00:25:32.78 XX0uOJLH.net
＞長さ0はstart..startになって特別扱いすることなく自然にそのまま扱える
長さ0を表現するのにstartが具体的な値持ってて自然てどういう理屈?
88:デフォルトの名無しさん
25/09/27 00:31:44.56 lQv27qFK.net
>>87
長さ1や長さ2がstart違ってあちこちにあるように
長さ0もstart違ってあちこちに存在する
89:デフォルトの名無しさん
25/09/27 00:43:10.07 XX0uOJLH.net
>>88
Pascalでstartの違う長さ0表して便利な例挙げてみて
90:デフォルトの名無しさん
25/09/27 00:55:46.18 B/IRYC2K.net
>>87
Rustの..は性質の良い半開区間なので、
例えばstart..endを途中のmiddleの位置で分割すると、start..middleとmiddle..endの二つに綺麗に分かれる性質も持っているよ。
そしてそのmiddleの決定算出結果が処理内容や処理状況によっては、たまたまstartと一致することも出てくる。
その時、start..middleとmiddle..endの二つは、start..startとstart..endの二つに分かれて前者は長さ0になるね。
Rustでのプログラミングでも実際にこれはよく起きるよ。
91:デフォルトの名無しさん
25/09/27 01:43:57.58 XX0uOJLH.net
>>90
区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。
92:デフォルトの名無しさん
25/09/27 01:48:32.95 XX0uOJLH.net
閉区間と半開区間のどちらにメリットがある場合もあり、Rustも閉区間をサポートしてるのに半開区間のみを持ち上げてるのは見識が狭いな。
93:デフォルトの名無しさん
25/09/27 02:17:11.42 B/IRYC2K.net
>>91
区間には必ずスタート位置を伴いますね。
そこから長さが2だったり長さが1だったり長さが0だったりするわけです。
長さ0の時だけスタート位置が無いのは不自然でしょう。
>>92
良い性質を備えていてメリットがあるのは半開区間でしょう。
Rustの標準APIは区間分割split_atなどでも半開区間を前提として処理されます。
94:デフォルトの名無しさん
25/09/27 02:20:12.82 u3EkYZLQ.net
『fast inverse square root (高速逆平方根) のようなトリックまとめ』
未定義動作コードの見本市みたいな記事。
C言語知りませんアピールか。
95:デフォルトの名無しさん
25/09/27 07:25:01.25 rUQ4UupW.net
C言語なんて動きゃいいんだよ動きゃ
96:デフォルトの名無しさん
25/09/27 08:53:18.36 ItgajmGE.net
動きゃいいんだよ動きゃなんて言語でカーネルを作ってほしくない
97:デフォルトの名無しさん
25/09/27 12:15:10.22 HCtgOBXK.net
古いのから新しいのまであらゆるCPUで動きゃいいんだよ動きゃ
98:デフォルトの名無しさん
25/09/27 13:57:37.59 HvNJXk8w.net
＞動きゃいいんだよ動きゃ
動くかわからん未定義動作のコードにこういうこと言う奴は馬鹿
99:デフォルトの名無しさん
25/09/27 16:57:30.37 1KNVq9e2.net
特定のCPU/GPU環境と断ってる
C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
100:デフォルトの名無しさん
25/09/27 17:02:10.01 mMYsldco.net
CとC++はこの手の気持ち悪いオジサン湧くからほんと無理
101:デフォルトの名無しさん
25/09/27 17:19:12.43 CHztWjoA.net
>>94
その記事「特定のCPU/GPU環境」を書かないのが片手落ちやな
102:デフォルトの名無しさん
25/09/27 20:09:28.90 16nWnOPC.net
>>100
直前に出たRustとC/C++の違いは
C/C++はお前のようなバカにも理解できるように分かりやすく話してあげてることだぞ
103:デフォルトの名無しさん
25/09/27 20:36:16.39 jktxSQ82.net
>>77
半開区間で書く方が便利な場合があることを誰も否定してはいないだろう。一方、閉区間で
書く方が便利な場合もある。例えば1からnまでの自然数を表示したいときがそうだが、
半開区間しかないPythonではfor i in range(1, n + 1): print(i)なんてひねくれた書き方を
強要されるし効率も悪い（Pythonで効率を云々しても意味ないが）。だから、半開区間と
閉区間の両方の記法を提供するのが良い。
半開区間を表すのに左右対称な..を使うのは紛らわしいので不適切。Pascalなどで..で閉区間を
表す慣用が定着していたにもかかわらず、..で半開区間を表す愚行を最初にやらかしたのはDか。
その前車の轍をC#, Go, Rustが踏んでしまった。特に.NET兄弟のF#とPowerShellが..を閉区間で
既に使っていたのにC#が半開区間を表すのに..を導入してしまったのは大きな誤りだった。
Dはほぼ死語と化したから、..で半開区間を表す不適切な記法も消え去るべきだな。
104:デフォルトの名無しさん
25/09/27 20:44:14.86 CHztWjoA.net
閉区間ｲﾗﾈｴ
105:デフォルトの名無しさん
25/09/27 21:04:56.86 h+m11Qj8.net
閉区間を表す記号を用意すべきかどうかについてはそれぞれ考え方の違いがあるんだなと思うが、.. は左右対称だから閉区間にすべきというのは正直よく分からん理由付けだわ。Pascalだってそんな理由で .. を閉区間の記号にしたわけではないと思うが。
106:デフォルトの名無しさん
25/09/27 21:10:34.65 B/IRYC2K.net
>>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)は半開区間であり、半開区間を基本とする言語が多数派だね。
107:デフォルトの名無しさん
25/09/27 21:12:07.66 PCqkgGFG.net
＞特定のCPU/GPU環境と断ってる
＞C言語仕様と特定CPU仕様を履き違えて未定義動作って言いたいだけの馬鹿の一つ覚え
記事のコードがダメのはC言語の仕様として未定義動作と規定されてることをやってるからで特定CPU関係ないよ。
108:デフォルトの名無しさん
25/09/27 21:17:11.52 jktxSQ82.net
>>105
数学での表記も閉区間と開区間の記号は左右対称で、半開区間は左右非対称。
閉区間[a, b] 開区間(a, b) 左半開区間(a, b] 右半開区間[a, b)
..は閉区間にしか見えない。右半開区間は..<か..~にすべきなのにたった1文字をケチって
バグを呼び込むのは愚行としか言いようがない。
>>106
for i in range(1, n + 1): print(i)がプログラミングに適しているとでも?
109:デフォルトの名無しさん
25/09/27 21:29:49.40 B/IRYC2K.net
>>108
それら現在メジャーな各言語の、range(srart, end)もslice(start, end)もstart:endもstart..endも全て半開区間を意味しているため、間違える人はいなくて、初心者もすぐ理解して誰も困っていないよ。
0からn個がrange(0, n)
1からn個がrange(1, n + 1)
2からn個がrange(2, n + 2)
とてもわかりやすくなっているね。
110:デフォルトの名無しさん
25/09/27 21:50:13.15 jktxSQ82.net
>>109
そんなものがわかりやすいわけないだろ。2からnまでの自然数を表示したい場合にはn - 1個だから
右端はn - 1 + 2 = n + 1でrange(2, n + 1)なんていちいち計算するのかw
mからn個ならC#のEnuemerable.Rangeが分かりやすい。
0からn個がEnuemerable.Range(0, n)
1からn個がEnuemerable.Range(1, n)
2からn個がEnuemerable.Range(2, n)
理解していなくて間違えるのではなく、理解しているが左右対称の見た目につられてうっかり間違えやすい。
それなのにわずか1文字をケチるのは愚行。
111:デフォルトの名無しさん
25/09/27 21:54:38.07 h+m11Qj8.net
① 多用される半開区間を少ない記号で書けるよう .. を半開区間の記号にしました。
② Pascal以来の伝統を重視して .. を閉区間の記号にしました。
③ 閉区間の記号は数学記号に倣って左右対称であるべきなので .. を閉区間の記号にしました。
自分は、説得力を感じる度合いとしては① >= ② >>> ③ かな。③ははっきり言ってパラノイアの戯言レベルの物言いにしか思えない。
また、半開区間の記号を ..< とか ..～ のような冗長で読みにくい記号にする前提なら、それが .. を閉区間の記号にしたくない最大の理由になるかな。Pascalのように閉区間の記号しか設けていないのなら仕方ないが、開区間と閉区間の記号を両方用意するなら、開区間の記号の方をスッキリした記号にして欲しい。Rubyの .. と... で許容範囲ギリギリくらい。
112:デフォルトの名無しさん
25/09/27 22:08:37.36 jktxSQ82.net
>>111
意味がある記号を書くのを冗長とは言わない。消すのを愚行という。Pythonが意味がある{}を消したのも愚行。
そんなに文字数を減らしたいなら半開区間の記号を.~にしたらどうか。
113:デフォルトの名無しさん
25/09/27 22:45:20.51 fM3CYn91.net
> 閉区間[a, b] 開区間(a, b) 左半開区間(a, b] 右半開区間[a, b)
これでいうとrust方式は一貫性の点で詰んでないか？
閉区間[a, b] a..=b
開区間(a, b) ???
右半開区間[a, b) a..b
左半開区間(a, b] ???
pascal方式だと以下のように拡張しうる余地がある
閉区間[a, b] a..b
開区間(a, b) a<..<b
右半開区間[a, b) a..<b
左半開区間(a, b] a<..b
114:デフォルトの名無しさん
25/09/27 23:23:15.70 h+m11Qj8.net
このスレでパラノイアの妄執を開陳されてもなぁ。
..< とか <..< とかで「一貫してるぞ、わーい」って喜べるの貴方くらいだよ。
115:デフォルトの名無しさん
25/09/27 23:40:53.38 xS2lIG/M.net
Rustは非常にシンプルで
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない
116:デフォルトの名無しさん
25/09/28 00:57:38.05 aU9wcwp7.net
>>114
108と113は別人だから、少なくとも2人はいるな。左右対称の..が閉区間に見えるのが自然な感覚なのに、
それに反して半開区間を割り当てているのが正解だなんて言い張っている方がカルト教団だよ。
数学に固執する本当のパラノイアはJuliaの作者だな。文字列連結演算子には+を使うのが自然な感覚なのに、
数学では+は可換演算子だから不適切で、*は非可換演算子の場合もある（例：行列演算）から*を使うのが
適切と言い張っている。
117:デフォルトの名無しさん
25/09/28 01:05:52.83 IhNFMRKQ.net
>>115
合理的だな
118:デフォルトの名無しさん
25/09/28 01:15:35.68 aU9wcwp7.net
>>115
<は右の値を含まないことが一目瞭然だが、..はそうではなく右の値を含むようにしか見えない。
119:デフォルトの名無しさん
25/09/28 01:22:45.65 OpklV7ok.net
対称なstart:endで半開区間を示す言語も多いけどそれには文句をつけずに
なぜかstart..endだけに文句をつけているから単なるキチガイだと思う
120:デフォルトの名無しさん
25/09/28 01:28:15.16 aU9wcwp7.net
>>119
:で半開区間を表す言語なんてあったっけ?
121:デフォルトの名無しさん
25/09/28 01:34:38.77 exR0IU1B.net
マイクロソフトまでもがC#8.0でついに導入した範囲構文を
「start..end」と記述して半開区間を意味することにしちゃったからね
半開区間が多数派だよ
122:デフォルトの名無しさん
25/09/28 02:06:41.24 OkDUf4Ut.net
>>102
気持ち悪いから絡んでくんなRust信者
123:デフォルトの名無しさん
25/09/28 02:22:58.32 /6w9hfWi.net
現在メジャーに使われているプログラミング言語で調査してみた
start:endやstart..endと書いた時にどちらを意味するか？
【閉区間】Ruby
【半開区間】C# Go Python Rust
124:デフォルトの名無しさん
25/09/28 03:25:05.02 1+QqAxps.net
Rubyでも半開区間はstart...endと左右対称な形で書くよ
「半開区間を左右対称な形に記述するな！」と主張してる>>108は頭おかしい
125:デフォルトの名無しさん
25/09/28 06:17:53.02 riDxLC/x.net
彼の主張する
・閉区間はPascalと同じstart..end
・半開区間は左右非対称な記号列
を満たす言語はそもそも存在するの？
Pascal自体は半開区間が存在しないから満たさない
>>123の各言語はRubyを含めて半開区間が左右対称な記号列
126:デフォルトの名無しさん
25/09/28 06:43:10.95 .net
>>91
>>>90
>区間の長さが0だった話じゃなくて、長さ0を表現するのにstartが具体的な値持ってるのはどうなのと聞いています。
これすげえな
多重ループすら見たことないのか
127:デフォルトの名無しさん
25/09/28 08:23:09.99 0sdmbxgV.net
ここの住人もQiitaと同レベルだよな
128:デフォルトの名無しさん
25/09/28 08:34:28.79 SzcnPpn2.net
争いは同じレベルの者同士でしか発生しないからな
129:デフォルトの名無しさん
25/09/28 13:02:57.89 iPJCP/07.net
現行の言語のデザインに何も疑問を持たないのはそれだけの人
130:デフォルトの名無しさん
25/09/28 13:46:21.84 .net
>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が
131:デフォルトの名無しさん
25/09/28 13:49:09.56 .net
全てのインデックスを過不足なく処理することの需要が最も大きいんだから
その用法の記述が最もシンプルになるべき
情報圧縮なんて聞いたことすら無いから登場頻度の多いものに少ないビット数を割り当てるなんて聞いたことすらないんだろう
そこで数学ガーとか言い出すのは間違いなく数学も出来ない低学歴無職
132:デフォルトの名無しさん
25/09/28 14:09:14.21 Md4hnl4x.net
どの言語も範囲指定は半開区間が基本だから困ってる人はいないだろ
半開区間を左右非対称な記法にしなければ閉区間と誤解する人なんていない
133:デフォルトの名無しさん
25/09/28 15:14:07.50 .net
左右対称とかバカしかやらない
インデックスを過不足なく処理したいのに閉区間にされたら端の重複を除外する処理が追加で必要になる
知能が存在しないからそんな妄想ができる
間違いなく中学レベルの数学の証明すらできない脳障害の妄想
バカすぎて数学が出来なくて悔しかったので
思考力の無さを誤魔化すために「数学原理主義」に立つことで自分は数学ができるんだと言い聞かせるという低学歴しぐさ
134:デフォルトの名無しさん
25/09/28 16:40:35.56 1TqmSl7N.net
急所突かれて発狂ｗ
135:デフォルトの名無しさん
25/09/28 17:11:35.80 AfcFEDfn.net
Pythonのlist[start:end]は半開区間でstartを含んでendは含まないけど
これを「閉区間と勘違いするから左右非対称なlist[start:<end]に変更しろ」と要求してるのかよwww
136:デフォルトの名無しさん
25/09/28 17:32:21.30 1TqmSl7N.net
半開区間と閉区間の両方をサポートする言語と半開区間か閉区間のどちらかしかサポートしない言語との区別がつかない>>135は馬鹿だな
137:デフォルトの名無しさん
25/09/28 18:01:58.35 fCzTTfAf.net
なるほど
両方サポートしていれば閉区間の指定方法が別途あるから確実に両者の区別がついて混乱しないってことか
138:デフォルトの名無しさん
25/09/28 18:33:01.36 .net
そんなもん使い道が無い
139:デフォルトの名無しさん
25/09/28 18:33:42.56 .net
そもそもマシンコードに区間なんて存在しないんだから
内部的に２つの条件判断に置き換えるだけ
サポートしてるかどうかなど全く無意味
140:デフォルトの名無しさん
25/09/28 18:34:40.04 .net
しかもいまだにAIエージェントでコーディングしてない時点でヤバすぎる
やるのはエージェントだからタイピングの手間とか見やすさとかそんなものは存在しない
仕事してない無職の妄想
141:デフォルトの名無しさん
25/09/28 18:58:05.58 abSkBPDh.net
AIにとっては左右非対称であることが重要
左右対称なら閉区間だと思い込む可能性が高い
142:デフォルトの名無しさん
25/09/28 19:03:52.16 .net
>>141
無職の妄想は意味ないよ
143:デフォルトの名無しさん
25/09/28 19:04:21.97 .net
>>141
証拠出せよ
出せないなら自殺して詫びろ
144:デフォルトの名無しさん
25/09/28 19:17:29.37 HeMXelkZ.net
そもそも人間は左右対称だと閉区間と思い込むもんなの？
そこからおかしいんじゃないの？
145:デフォルトの名無しさん
25/09/28 19:19:06.15 .net
>>144
思い込まない
何の証拠もない中卒の妄想
ソースが無い
146:デフォルトの名無しさん
25/09/28 19:21:01.28 .net
話題になり得るのはAIエージェントが取り違えしてないかどうかチェックするためのテストコードをどうやってAIエージェントに漏れなく全ての箇所で書かせるかとかだろ
人間にとっての見やすさなんて無職の自白
147:デフォルトの名無しさん
25/09/28 19:28:03.90 .net
区間記号を全てgrepして該当箇所をファイルに書き出して書き込み禁止にし
その該当箇所全てでテストコードを書かことを義務付けてパスしないと認めない指示にするとかだな
記号なんて全くどうでも良い
テストするんだから
148:デフォルトの名無しさん
25/09/28 19:29:08.83 .net
区間記号の解釈とテストがどうなっているべきかも.mdに最初に書かせて
それを守ってない行動は全てリバート
149:デフォルトの名無しさん
25/09/28 19:38:57.62 NUkjyMN+.net
現在メジャーに使われているプログラミング言語で調査してみた
半開区間の指定が左右対称か左右非対称か？
【左右対称】C# Go Python Ruby Rust
【左右非対称】Swift
150:デフォルトの名無しさん
25/09/28 20:05:41.70 iPJCP/07.net
>>139
> そもそもマシンコードに区間なんて存在しないんだから
> 内部的に２つの条件判断に置き換えるだけ
URLﾘﾝｸ(godbolt.org) と URLﾘﾝｸ(godbolt.org) じゃ結構違うと思うが何言ってる?
151:デフォルトの名無しさん
25/09/28 20:16:56.42 .net
>>150
だからアセンブラで書けよ無能
どんなマシンコードにコンパイルされるかすら知らねえ猿が吠えんな
152:デフォルトの名無しさん
25/09/28 20:25:27.74 iPJCP/07.net
>>151
ちょっと何言いたいんだか分からんね。
153:デフォルトの名無しさん
25/09/28 20:27:54.00 .net
>>152
アセンブラ書けねえのか無知
154:デフォルトの名無しさん
25/09/28 20:28:29.22 .net
>>129
>現行の言語のデザインに何も疑問を持たないのはそれだけの人
>>129
違うデザインのものなんて無数にあるのに誰も支持しなかったことすら考えられないからお前は中卒無職ヒキコモリ脳障害なんだよ
自殺しとけ猿が
155:デフォルトの名無しさん
25/09/28 20:29:19.56 .net
>>152
分からんなら自殺しろ
アセンブラすら知らない猿が吠えんな
最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから
消えろ
この世から
156:デフォルトの名無しさん
25/09/28 20:33:56.40 iPJCP/07.net
> 最終的にどんなマシンコードになるか知らないバカが妄想しても意味ねーから
スマホで見て発狂してる可能性もあるかな?
157:デフォルトの名無しさん
25/09/28 20:37:44.61 .net
>>156
最適化レベルすら指定してない猿
無職か？
158:デフォルトの名無しさん
25/09/28 20:48:48.21 iPJCP/07.net
> 最適化レベルすら指定してない猿
指定してる -Copt-level=2 が最適化指示とわからん人かな?
159:デフォルトの名無しさん
25/09/28 20:59:03.90 67OEPeOQ.net
AIって想像以上にアホだぞ
160:デフォルトの名無しさん
25/09/28 21:12:11.28 aU9wcwp7.net
>>124
Rubyは閉区間と半開区間の両方を提供したことと、閉区間に左右対称な..を採用したことでは
賢明だったが、半開区間に左右対称な...を採用したのは惜しい誤りだったな。..とも判別しづらいし。
..<か..~にすべきだった。
>>125
>>66にも書いたように、Swiftでは閉区間は...で左右対称、半開区間は..<で左右非対称だよ。
閉区間はPascalの..より.が1つ多い...だが、左右対称という点では共通する。
増分も指定できるように拡張することを見越すと、半開区間には..<より..~の方が適している。
開始値..増分..<終了値だと増分が負のとき変な感じがするが、開始値..増分..~終了値ならば
問題ないから。
もっともSwiftでは増分指定では記号を使わない。stride(from: 開始値, through: 終了値, by: 増分) の
ように省略不可の名前付き引数を書かせる。そして、名前付き引数だから順不同ということもなく、
この順でしか受け付けない。このようなガチガチの書式で固めたのもバグを防ぐための用心だろう。
Fortran, Juliaでは開始値:終了値:増分だがMATALAB, Octave, Scilabでは開始値:増分:終了値で
順序が異なるため、混同による書き間違えの恐れがあるから。
161:デフォルトの名無しさん
25/09/28 21:13:50.83 aU9wcwp7.net
>>131
>>116に挙げたJuliaの作者じゃないから、数学に合わせること自体に固執しているわけではない。
左右対称な..が閉区間を表すのが自然な感覚で、それに反するのはバグの元だからやめるべきだと
いうのが根源的な理由で、数学はそれに反していない例として挙げたに過ぎない。
人間は機械ではないから見た目に惑わされやすい。機械だけが相手なら半開区間をi!jで表せば
効率が最も良いし、多くの言語では破壊的変更も文法的に不要で好都合なはずだが、人間の
感覚では!は半開区間とは容易に結びつかない（:の変形と見なせば結びつかなくもないが）し、
|とも判別しづらいから不適当。
屁理屈を捏ねて自然な感覚に反することを強制するのは、ギークの村社会のキモい悪習としか
言いようがない。プログラム言語の記法の選定はUI設計の一種なのに、不自然で間違えやすい
記号を採用するのは工学的センスが絶望的にない。UIは美的にも心地良いことに越したことはなく、
その点でも見苦しい略語を多用するRustは落第だな。そもそも名前からして汚らしい。
>>144
基本ラテン文字の大文字全体を'A'..'Z'で表すのが素直な感覚（EBCDICのような化石はこの際
無視して良い）で、'Y'までしか含まないと言い張るのは無理がある。'A'..='Z'は冗長だし、
'A'..'['では何を意図しているかすぐには分からない人が多いだろう。
162:デフォルトの名無しさん
25/09/28 21:25:20.44 YRR4qqFp.net
Rustのイテレータがとてもわかりやすい
【C】i = 0 ; i < n; i++
【Rust】0..n
と
【C】i = 0 ; i <= n; i++
【Rust】0..=n
対応している
163:デフォルトの名無しさん
25/09/28 21:32:15.76 .net
>>158
書いてないぞ
164:デフォルトの名無しさん
25/09/28 21:38:57.07 .net
>>161
そんな感覚は無いのでお前の負け
ソース無し
165:デフォルトの名無しさん
25/09/28 21:43:13.72 .net
>>161
自然なのは左右対称とかどうでもいい猿の妄想じゃなくて
最も使われるものが最もシンプルに書けるという情報理論的効率性な？
166:デフォルトの名無しさん
25/09/28 22:05:51.43 aU9wcwp7.net
>>164
正直に白状しろ。心当たりが全くなくはないはずだ。
C++ STLの.begin()と.end()の組の.end()を書くときにも、もやもやする感覚が常に伴うな。
『リーダブルコード』に、
プログラミングの命名規約では、包含／排他的範囲にbeginとendを使うことが多い。
でも、endは少しあいまいだ。例えば、「本の終盤（the end of the book）を読んでいる」の
「end」は包含的だ。残念ながら英語には「ちょうど最後の値を超えたところ」を意味する簡潔な
言葉がない。
と述べられている通り。簡潔な言葉がないなら作れば良かったと思う。例えば、endの次（next）だから
nendとか。無闇に造語すべきではないが、どうしても必要なら作れば良い。bitは成功例だろう。
とは言え、複数の本を本棚に並べ右端の横にブックエンドを置いたとき、.end()は本そのものではなく
ブックエンドだと考えれば、.end()はまあ納得できるから..ほど悪くはなく許容できる。
>>165
誤記予防という機能性を犠牲にしてたった1文字をケチる愚行。第一、閉区間より半開区間の方が頻繁に
使われるという主張も怪しい。作るプログラムによって異なるだろ。
167:デフォルトの名無しさん
25/09/28 22:07:15.34 .net
>>166
なんのソースもない中卒の妄想は意味ない
ソースを出せ
出せないなら自殺して詫びろ
168:デフォルトの名無しさん
25/09/28 22:08:16.70 .net
>>166
曖昧なことなど一つもない
定義を見れば良いだけ
定義以外の妄想してる時点で中卒無職だと確定する
169:デフォルトの名無しさん
25/09/28 22:11:06.36 5mXw367y.net
>>162
従来との対応関係のあることが最も重要なのでそれで正しい
170:デフォルトの名無しさん
25/09/28 22:13:10.39 .net
>>166
りーだぶるwwww
こーどwwwww
お前無職だろ？
そんな実績0の無能な猿が書いたゴミを流行りで買ってる時点で無職バレバレ
171:デフォルトの名無しさん
25/09/28 22:15:00.74 aU9wcwp7.net
>>167
低学歴ではないが、低学歴という煽りもここでは意味がないね。プログラム言語なんて小学生でも
分かる程度のものでしかないし、一般的感覚も自然言語と高校までの数学によって形成されるものだから。
そこから乖離した屁理屈をあれこれほざいても、ギークのキモい戯言でしかない。
172:デフォルトの名無しさん
25/09/28 22:18:09.06 .net
>>171
ソース出せない妄想と
173:デフォルトの名無しさん
25/09/28 22:18:52.64 .net
>>171
低学歴だから定義を無視して字面から妄想し
低学歴だからソースもないのに妄想を断定できてしまう
174:デフォルトの名無しさん
25/09/28 22:23:17.24 iPJCP/07.net
>>162
>【C】i = 0 ; i <= n; i++
と
>【Rust】0..=n
は同じ動作になるとは限らないので何言いたいんだかわからん。
175:デフォルトの名無しさん
25/09/28 22:26:42.41 iPJCP/07.net
いまこのスレで発狂してるやつ見てるとQiitaでアカウントBANされたコイツ思い出すんだよなあ。
URLﾘﾝｸ(web.archive.org)
> はい、私が勘違いしてました。
> 途中で、
>
> スクリーンショット 2022-12-19 184235.png
>
> みたいな突っ込みがあって、やっと問題文をちゃんと読み直して『あれ？』となったわけですが、
>
> 自分、基本的にTwitterでの間違いは死んでも認めない主義なので、そのまま押し切る事にしました。
>
> Twitterとかのネットは所詮遊び場なので「バトルしようぜ、Tweetバトル！俺が勝ったらテメェは俺以下だぁー！！」みたいなノリで強引に押し切ろうとしました。
>
> で、まぁ、惨敗したわけですけどねｗ
176:デフォルトの名無しさん
25/09/28 22:27:15.68 jJ7lr+aR.net
以下の性質の良さの違いのため
プログラミングでは半開区間が多用されている
半開区間 (性質が良い)
・start～endの長さはend-start
・startから始まる長さlenの区間はstart～(start+len)
・startから始まる長さ0の区間はstart～startと表せてそのまま自然に扱える
・途中middleでstart～middleとmiddle～endの二つに分割できる
閉区間 (性質が悪い)
・start～endの長さはend-start+1
・startから始まる長さlenの区間はstart～(start+len-1)
・startから始まる長さ0の区間はstart～(start-1)になって破綻
・途中middleでstart～middleとmiddle～endの二つに分割できない
start～middleと(middle+1)～endか
start～(middle-1)とmiddle～endになる
177:デフォルトの名無しさん
25/09/28 22:27:24.30 aU9wcwp7.net
>>173
カルト教団のむきになった反論そのものw 教祖様のお言葉がソースか?
自然言語と高校までの数学表記が一般に広く受け入れられていること、それで根拠として十分。
178:デフォルトの名無しさん
25/09/28 22:32:09.90 .net
>>177
>>171
低学歴だから定義を無視して字面から妄想し
低学歴だからソースもないのに妄想を断定できてしまう
179:デフォルトの名無しさん
25/09/28 22:38:40.96 jJ7lr+aR.net
区間指定の文法を持つ最近のメジャーなプログラミング言語では半開区間を簡単に表記できるようになっている
例えば
GoやPythonなどでは list[start:end]
C#やRustなどでは list[start..end]
いずれもendを含まない半開区間を意味している
180:デフォルトの名無しさん
25/09/28 22:46:12.82 aU9wcwp7.net
>>178
定義なんて所詮は教祖様がお作りになった教義に過ぎない。それを絶対視して変だと考えず、
変だと指摘する人にむきになって壊れたレコードのようにワンパターンな反応を繰り返す
カルト信者。
181:デフォルトの名無しさん
25/09/28 22:47:22.28 .net
>>180
定義はコンパイラの仕様
バカすぎる無職
182:デフォルトの名無しさん
25/09/28 22:47:41.83 .net
>>180
変なのはお前
だから無職なんだろ中卒
183:デフォルトの名無しさん
25/09/28 22:49:02.93 .net
>>176,179
これを入社試験の面接で説明できなきゃ不採用でいいわ
これ分からん奴はセンスが無さすぎる
184:デフォルトの名無しさん
25/09/28 23:01:12.25 aU9wcwp7.net
>>181
コンパイラは教祖様がお作りになった言語仕様に沿って作られたものだろ。
>>182
無限ループ、またの名を暴走と言うw
185:デフォルトの名無しさん
25/09/28 23:01:37.54 .net
>>184
これが無職
186:デフォルトの名無しさん
25/09/28 23:25:09.36 jJ7lr+aR.net
>>183
初心者は仕方ないとしてもプログラミング歴のある人には必須な知識だと思う
187:デフォルトの名無しさん
25/09/28 23:34:39.97 SbwCraTd.net
ここプログラム技術板で閉区間が自然だと主張して暴れてるやつはどこから来たお客さんなんだろう
188:デフォルトの名無しさん
25/09/28 23:48:23.78 aU9wcwp7.net
>>187
閉区間が自然だとは全く主張していないぞ。
・閉区間で書くのが便利な場合も半開区間で書くのが便利な場合もあるので、両方の書き方を
提供するのが良い（勿論、前者の場合には閉区間が自然ということになるが）
・閉区間には左右対称、半開区間には左右非対称の記号を割り当てるのが自然で、バグを
生みにくい
と主張しているだけ。
189:デフォルトの名無しさん
25/09/28 23:54:41.82 jJ7lr+aR.net
現実のメジャーなプログラミング言語では>>179のように半開区間を簡潔に記述できることを重視している
190:デフォルトの名無しさん
25/09/29 00:05:25.27 .net
>>188
根拠0
証拠0
ソース0
バカすぎて論外
191:デフォルトの名無しさん
25/09/29 00:05:49.17 .net
>>188
こういうバカは無職なのが自然
192:デフォルトの名無しさん
25/09/29 03:12:26.72 KaR4fBa3.net
>>188
func main(){
var a = [5]string{"a","b","c","d","e"}
fmt.Println(a[0]) // a
fmt.Println(a[1]) // b
fmt.Println(a[1:3]) // [b c]
}
Go言語は半開区間のみ
> 両方の書き方を提供するのが良い
半開区間のみを提供するのが良い
２つの書き方を提供するのはバグを生みやすい
あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
193:デフォルトの名無しさん
25/09/29 03:23:08.08 Lm5HPMDj.net
>>192
横からだけど
Goは言語機能が非常に弱くて
その半開区間の指定も部分フライス指定にしか使えない
イテレータとして機能しない
(switchやmatchなどの)パターンマッチングにも使えない
194:デフォルトの名無しさん
25/09/29 07:48:42.16 kekj+dde.net
>>192
＞あるプロジェクトでマイクロソフトが自社のC#でなくGo言語を採用したことが有名
TypeScriptコンパイラのことなら
Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
という記事にまとめられているが
＞半開区間のみを提供するのが良い
＞２つの書き方を提供するのはバグを生みやすい
なんて理由は挙げられてないね。
195:デフォルトの名無しさん
25/09/29 23:43:13.74 6lOYarrI.net
現実は>>179
理由は>>176
ということでいいのかな
196:デフォルトの名無しさん
25/09/30 00:17:04.81 jvKDz5J9.net
閉区間と半開区間のどちらが優れているということは誰も言ってないのに一人発狂してる人がいる感じ
197:デフォルトの名無しさん
25/09/30 01:59:55.11 4wPfeVv9.net
閉区間より半開区間が優れている
そのため半開区間を短い記述で指定できる文法を用意している言語が多い
短い記述の結果として半開区間が左右対称の記述になっているが誰も気にすることはない
半開区間の記述は左右非対称であるべきだとこだわっているキチガイは一人だけ
198:デフォルトの名無しさん
25/09/30 02:52:38.16 .net
無職の妄想に価値はない
199:デフォルトの名無しさん
25/09/30 08:25:04.59 EJn4wwZL.net
グレゴリオ暦のうるう年判定に延々とおかしなイチャモンつけてたashworthまんまだなｗ
200:デフォルトの名無しさん
25/09/30 10:36:18.87 hvi0j7l5.net
そもそも自転はずれるからな
201:デフォルトの名無しさん
25/09/30 11:06:24.13 EJn4wwZL.net
いまはこのルールでやりましょうというグレゴリオ暦を分かってないｗ
202:デフォルトの名無しさん
25/09/30 12:34:48.41 dVe563is.net
グレゴリオ暦のうるう年の判定ルール
・西暦年が4で割り切れる年はうるう年となる
・ただし、西暦年が100で割り切れる年はうるう年としない
・さらに、西暦年が400で割り切れる年は例外的にうるう年とする
203:デフォルトの名無しさん
25/09/30 12:39:42.96 .net
低学歴がなぜ低学歴なのかよくわかる
204:デフォルトの名無しさん
25/09/30 12:40:27.16 .net
>>201
バカすぎてルールを理解できないことを正当化するためにルールがおかしいと吠えたまま死ぬ
これが低学歴の人生
205:デフォルトの名無しさん
25/09/30 12:40:59.11 .net
そういうゴミクズを雇ったら終わりなので学歴システムがある
人間判定試験
猿を雇わないようにするための仕組み
206:デフォルトの名無しさん
25/09/30 23:54:22.10 gehVEPsn.net
>>188
閉区間ではなく半開区間をサポートするプログラミング言語が多い理由を考えてみよう
それらの言語は半開区間に左右非対称の記号ではなく簡潔な記号を割り当てている理由を考えてみよう
207:デフォルトの名無しさん
25/10/01 00:59:06.36 .net
算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は
208:デフォルトの名無しさん
25/10/01 01:38:56.41 Fskx/ZBj.net
> そもそも自転はずれるからな
地球の自転周期が変わったとして影響があるのは1日の長さなんだがｗ
209:デフォルトの名無しさん
25/10/01 02:15:45.08 VkTjow7K.net
>>207
多用する半開区間に短い記号を充てるのが正解だと思う
しかしPythonやGoの start:end はあまりにも短すぎて用いる場所によっては文法的に曖昧になる可能性があるためなのか
現状はスライスのインデックス部分 a[start:end] でしか用いることができない
例えばmatch文のcaseでは指定できないため case x if start <= x < end と書く必要がある
イテレータとしても指定できないため for i in range(start, end) と書く必要がある
これら全て同じ記法で書けると好ましい
210:デフォルトの名無しさん
25/10/01 21:52:18.72 yE7SMjvb.net
Rustは同じ扱い
buf[100..200]
for i in 100..200 { … }
match x {
100..200 => …,
…
}
211:デフォルトの名無しさん
25/10/01 23:34:49.32 a34LDfpM.net
>>206
>それらの言語は半開区間に左右非対称の記号ではなく簡潔な記号を割り当てている理由を考えてみよう
教祖様がお作りになった教義だから。教祖様の好みが強く反映されているとしか言いようがない。
>閉区間ではなく半開区間をサポートするプログラミング言語が多い
事実ではなかろう。
・閉区間しかない
Ada, bash, Delphi, Elixir, F#, Fortran, Groovy, Haskell, Julia, MATLAB, OCaml, Octave, Pascal, Perl, PowerShell, R, S, Scilab, Wolfram
（Wolfram以外は左右対称記号を使用、Wolframはほぼ左右対称の;;を使用）
・半開区間しかない
C#, D, Go, Python
（すべてが左右対称記号を使用）
・両方ある
Kotlin, Nim, Raku, Ruby, Rust, Swift, Zig
（これらのうち、
閉区間に左右対称記号を使用：Kotlin, Nim, Raku, Ruby, Swift, Zig
半開区間に左右対称記号を使用：Ruby, Rust, Zig）
※抜けている言語や記憶違いなどがあるかも知れないので、見つけたら指摘してもらいたい
以上を一覧すれば、半開区間しかない言語は少ないし、閉区間に左右対称記号を使う言語は多いし、
半開区間に左右対称記号を使う言語は少ない。要するに、一般的感覚に敢えて背く仕様の言語は
少ないことが看取される。
212:デフォルトの名無しさん
25/10/01 23:35:20.38 a34LDfpM.net
>>207
圧縮ファイルを直読みできる超人さんですか?w
短さを馬鹿の一つ覚えみたいに持ち出しているが、間違えにくさを犠牲にしてまで達成すべきものではない。
人間は機械ではないのでうっかり間違えやすい記号を宛てないのが賢明で、たった1文字をケチるのは愚行。
正確に言えば機械も生の状態では間違えるから、エラー訂正符号を付加して無謬に見せかけているだけなので、
人間にも機械にも最短ではなくそれぞれの間違え方を防ぐような追加の情報も必要だという訓戒に纏められるな。
そこを疎かにするのは欠陥設計。
213:デフォルトの名無しさん
25/10/01 23:36:14.72 .net
>>211
算術符号とかハフマン符号なんて聞いたことすらねえんだろうな低学歴は
214:デフォルトの名無しさん
25/10/01 23:37:07.68 .net
>>212
え？圧縮ファイル？
何言ってんのこの中卒無職脳障害
そんなの関係ねえよ猿が
情報理論的な効率性の話しかしてないのに中卒だからわかんねえのか自殺しとけ猿が
215:デフォルトの名無しさん
25/10/01 23:38:06.41 .net
>>212
お前が低学歴で人間じゃないだけ
お前は無職で人間の世界から排除されてるから人間の世界に口出しする権利ないよ
参加お断り
216:デフォルトの名無しさん
25/10/01 23:51:28.21 a34LDfpM.net
>>214
馬鹿には皮肉の解説が必要だったか。情報理論的な効率性を徹底的に追求したのが圧縮ファイルだろ。
それは人間には勿論読めないが、もう少し緩く追求した半開区間に..を使う表記も人間にはやっぱり
間違いやすい。お前がそんなことはないと言い張るなら、さぞかし凄い超人なんだろうねーという皮肉。
たった1文字追加するだけで効率性と間違えにくさのバランスが取れた表記になるのに、ムキになって
否定するのは愚か。
217:デフォルトの名無しさん
25/10/01 23:56:05.16 .net
>>216
圧縮ファイルなんて使ってない
人間の世界では最短符号を使って人間は読んでる
無職はそれが読めないから誰も雇わない
218:デフォルトの名無しさん
25/10/01 23:56:30.77 .net
>>216
お前が間違えてもどうでもいい
だってお前は人間じゃないし人間の社会に参加出来ないから
219:デフォルトの名無しさん
25/10/01 23:57:04.34 .net
>>216
人間は間違えない
猿は間違える
だから猿を雇わない
よってお前は無職
猿だからな
220:デフォルトの名無しさん
25/10/02 00:00:52.83 IXGrVOcw.net
>>216
C#の半開区間指定start..end読みやすくて良いと思うよ
閉区間だと間違える人はいない
221:デフォルトの名無しさん
25/10/02 00:02:09.92 .net
人間は間違えない
猿は間違える
だから猿を雇わなきゃいいだけ
222:デフォルトの名無しさん
25/10/02 00:02:41.34 .net
猿に合わせて人間のルールを変えるわけねえだろ
猿を排除するのが最善
223:デフォルトの名無しさん
25/10/02 00:44:06.46 Jz40Wv3H.net
>>211
それら閉区間しかないプログラミング言語は現代のメジャーな言語ではないな
センスが悪いとメジャーな言語になれないことがわかった
224:デフォルトの名無しさん
25/10/02 01:12:51.54 EU/7mSn/.net
>>202
『あなたは本当に「プログラミングができない、向いてない」のか？ 〜うるう年判定プログラムで考える〜』
URLﾘﾝｸ(qiita.com)
という記事のコメ欄でashworthが他のコメントに絡んでたけど(垢BAN済み)、記事のコード見ると
> year = int(input())
> if year % 400 == 0: # 400の倍数なら「うるう年です。」
> print("うるう年です。")
> elif year % 100 == 0: # 100の倍数なら「うるう年ではありません。」
> print("うるう年ではありません。")
> elif year % 4 == 0: # 4の倍数なら「うるう年です。」
> print("うるう年です。")
> else: # どれにも当てはまらなければ、「うるう年ではありません。」
> print("うるう年ではありません。")
400は100の倍数、100は4の倍数を利用したグレゴリオ暦の説明の逆順で判定するけったいなコード書いてんなあナンダコレ?
まあ記事はNucoなんでセンスなくて当たり前なんだけど、ashworthがこれに絡んでなかった辺りやっぱセンスないわなｗ
225:デフォルトの名無しさん
25/10/02 01:14:57.85 qLX1OCT3.net
まともな言語がいずれも半開区間をサポートしているのは偶然ではなくて、
配列やリストやベクタあるいは文字列などの連続領域の一部分いわゆるスライスを言語で扱おうとすると、
その区間を指定する必要がでてくる。
まともな汎用言語ならそのスライスと区間指定をサポートするのは必然で、
しかも閉区間は扱いにくいことが判明しているわけだから、
結果的に半開区間をサポートしているか否かでまともな言語か否かが判明することになっている。
226:デフォルトの名無しさん
25/10/02 04:38:08.95 oFFK8/LC.net
>>224のコードってそんなに変かな？ 自分もこんな感じに書くと思うが。
227:デフォルトの名無しさん
25/10/02 05:00:19.18 vDXY/c5t.net
>>226
動くコードは無数に考えられる。
しかし保守性を考慮すると、
元の文章に対応したコードのみが正解。
元の文章と逆順に書いた場合、
何か理由が添えてない限り失格でクビだろうね。
228:デフォルトの名無しさん
25/10/02 07:15:16.83 .net
ソース読めよ
Check out this DeepWiki page URLﾘﾝｸ(deepwiki.com)
229:デフォルトの名無しさん
25/10/02 07:34:34.02 3AP3Ig0g.net
なるほど、if文のネストみたいな感じで書くのだとしたらそれはかえって分かりにくいのではと思ったけど、and or で1行で書いちゃうならスッキリしているね。
230:デフォルトの名無しさん
25/10/02 08:18:23.33 .net
if文使った時点で不採用
print文使った時点で不採用
正解は
・数式・比較演算子と論理演算子で書く
・デバッガで各論理式の評価を確認してprint文を使わない
231:デフォルトの名無しさん
25/10/02 08:19:21.13 .net
deepwikiでソースコードに聞け
低スキルの「エンジニア」同士で低スキルを伝播しても害しかない
232:デフォルトの名無しさん
25/10/02 08:24:53.30 3AP3Ig0g.net
print関数はさすがに説明の便宜のためでしょ。
233:デフォルトの名無しさん
25/10/02 08:26:48.25 .net
知りたいgithubのアドレスを取得
URLﾘﾝｸ(github.com)
アドレスのgithubをdeepwikiに置換
URLﾘﾝｸ(deepwiki.com)
最下部のフォームに質問すればソースコードをソースにして回答する
234:デフォルトの名無しさん
25/10/02 08:29:36.47 .net
で
このdeepwikiもMCPでアクセスできるので
AIエージェントがコーディングのお作法を実装前にDeepWiki MCPで確認してソースコードをソースにして手順を確立してメモしてからそれを見ながら実装を開始するように出来る
低スキルエンジニア同士の会話など害しかない
235:デフォルトの名無しさん
25/10/02 08:45:54.05 6BvO5ATM.net
速さ優先ならこれとはまた異なってくるのだろう
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
236:デフォルトの名無しさん
25/10/02 13:03:09.54 sP1LMqCx.net
return False
237:デフォルトの名無しさん
25/10/02 13:37:06.50 dLU/Z4Pm.net
> それ、問題文の条件のまま書いちゃダメなんですよね。
> 「ただし」がある場合は前出の条件を否定してくるので、条件の順番通りに書くと破綻します。
> だから、「ただし」がある場合は条件を逆に記述していくのが鉄則です。
ashworthさん、何言ってんの?
238:デフォルトの名無しさん
25/10/02 23:03:29.56 jdy8/BVE.net
>>219
これまでの書き込みからお前はRust信者と推測されるが、「言語仕様で明確に定義されているのに数学につられて
間違えるのは低学歴・無職・猿」という煽り文句がブーメランになることに気づいていないのか?
C, C++ではif (a = b)という書き方が許されているが、数学では=が比較にも使われるため、比較するつもりで
if (a = b)とうっかり書き間違え、読み返しても間違いを見落とす恐れがあるので、C#やRustではこういう書き方を
できなくした。お前の煽り文句に従えば、代入は=、比較は==と言語仕様で明確に区別して定義されているのに
数学につられて間違えるのは低学歴・無職・猿で、C#やRustは低学歴・無職・猿向けの言語ってことになるねw
仮にお前がRustでなく他の言語の信者だとしても、似たようなブーメランを見つけることができるだろう。
Rustは他にも変数宣言でmutをいちいち書かせるなど過保護な安全性が設計思想にあるのに、半開区間..では
危うさを放置するのはチグハグだな。
あと、ここはプログラマー板じゃなくてプログラム板だから、別に職業プログラマ向けというわけではなく、
プログラムに関する見識は職を得ることに結びつかない。職業プログラマなんてIT土方とも揶揄されて
威張れるもんじゃないし、まして特定の言語と一蓮托生で必死になってるようではなー。お前の煽り文句は
明後日の方を向いているw
239:デフォルトの名無しさん
25/10/02 23:03:54.24 jdy8/BVE.net
>>223
ユーザーは区間の記法だけによってどの言語を使うか選んでいるわけではないから、一概には言えない。
Pythonはずぼらだからはびこってしまった。あんな害蛇はさっさと駆除すべきだな。その点、Rustは
繁文縟礼の塊なのであまり普及せず実害は少ない。
C#はユーザーを十分獲得した後の2019年に半開区間..を初めて導入した。.NET兄弟のF#とPowerShellが
..を閉区間に既に割り当てていたのに、そして開発責任者はPascalと縁が深いのに、何であんな変な記法を
許してしまったの解せない。
240:デフォルトの名無しさん
25/10/02 23:12:57.09 .net
>>238
いやRustなんか興味ないし知らん
どうでもいい
脳障害は日本語すら読めないだけ
人間は間違えないので猿を雇わなければ良いだけ
猿のために人間のルールを変えるわけない
241:デフォルトの名無しさん
25/10/03 00:09:20.16 Q1aE47Vx.net
半開区間に左右非対称を採用してる言語はSwiftだけじゃね？
半開区間の記法
【start:end】 Go Python
【start..end】C# Rust Zig
【start...end】Ruby
【start..<end】Swift
この現状で左右対称を採用している言語はダメだと叩いている人は偏った異端者かと
242:デフォルトの名無しさん
25/10/03 01:07:33.20 aYxPE6CF.net
1991 Python
1995 Ruby
2000 C#
2009 Go
2010 Rust
2014 Swift
2015 Zig
後発の方が先達の反省が活かされた洗練された記法を採用してる可能性は普通に考えられるかな
243:デフォルトの名無しさん
25/10/03 01:23:00.07 Q1aE47Vx.net
C#が半開区間start..endを導入したのは2019年リリースのC# version 8.0
244:デフォルトの名無しさん
25/10/03 08:33:47.40 qYL3CF1r.net
『Cなら知ってるんですけど、C++ってできますか？』
Cた間違い
245:デフォルトの名無しさん
25/10/03 08:35:11.18 qYL3CF1r.net
CやC++初心者は間違い探し的に読むと良い記事。
246:デフォルトの名無しさん
25/10/03 10:41:32.04 WGTRKW6c.net
>>244
モダンC++と言いつつ大昔の古臭いC++11で草
さらにC++11と言いつつ中核のスマートポインタを割愛で草
247:デフォルトの名無しさん
25/10/03 11:02:03.70 gMkT4O8N.net
長文おぢウザい
248:デフォルトの名無しさん
25/10/03 23:27:23.05 DEcBymr7.net
>>241
>>211に挙げた「両方ある」の7言語のうち「半開区間に左右対称記号を使用」の3言語を除いた4言語、
つまりKotlin, Nim, Raku, Swiftが半開区間に左右非対称の記号を使用している（Kotlin, Nim, Swiftは
..<で、Rakuは...^）。Rakuには左半開区間^...と開区間^...^もあり、4種類すべての区間を書ける。
これらに含まれる...は…と1文字で書いても良い。
Rubyは閉区間..より半開区間...の方が長いから、>>165がやたらこだわっている情報理論的効率性とやらには
反しているな。
249:デフォルトの名無しさん
25/10/03 23:28:02.03 ft8WeviY.net
>>238
> 変数宣言でmutをいちいち書かせるなど
これはプログラマーに
mutable宣言を意味するmutなどを書かせるべきか
immutable宣言を意味するconstなどを書かせるべきか
どちらをデフォルトにすべきかという問題だね
これはimmutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
immutableをデフォルトとして必要不可欠な変数のみmutable宣言させるのが正しいと思われる
プログラマーの手間もその方が少ない
250:デフォルトの名無しさん
25/10/04 14:05:10.36 eyfPTg37.net
Qiita Conference 2025 Autumn というので
URLﾘﾝｸ(qiita.com)
> 今のコンピュータはAIにもWebにも向いていないので作り直そう
> 2018年にAttentionが発表され、2022年末にLLMが登場して以降、GPUを用いた生成AIがあらゆるコンピューティングの活用を塗り替えていますが、実はGPUが生成AIに向いていないことをご存知でしょうか？
> 他にも、現代コンピュータアーキテクチャ自体が約70年前に構想されて以来、スループット／レイテンシ／電力消費に根本的な課題を抱えたままで、WebやIoTなどの大量ユーザー利用／データ利用と言った現代に求められる様々は「エンジニアが無理やり何とかしている」と言う実態があります。
> こうした課題を生み出す裏側を解説した後、性能と省電力を圧倒的に引き上げるための考え方／イノベーションを共有し、実際の解決実装例をご紹介します。
コイツに講演させちゃうんだなあ。ゲスト講演ということだけどどうやって人選してるのだろう?
251:デフォルトの名無しさん
25/10/04 19:45:26.17 .net
>>250
課題を生み出すwwww
省電力を引き上げるwwwww
これだけで価値がないとわかる
252:デフォルトの名無しさん
25/10/04 21:38:51.49 MpcY569I.net
>>250
山崎かなと思ったら福岡Elixirって書いてあったから同族か
253:デフォルトの名無しさん
25/10/04 23:29:54.72 gLEEZL45.net
>immutableのみが許されてmutableを許さないプログラミング言語もあるくらいで
マイナーな言語しかなくね？
「そういう言語がある」だけで、多くの人にとってはそれが便利だと思われてないと思うぞ
254:デフォルトの名無しさん
25/10/04 23:33:11.13 qAgFTJKW.net
Elixirの軽量スレッドで並列処理が効率化できてスパコン的用途にも使えると思ってる人たちだからなあ、つける薬がない。
255:デフォルトの名無しさん
25/10/04 23:59:14.21 XZN99/my.net
>>253
immutableだけだと不便で制限が生じる
その一方でプログラムはなるべくimmutableを中心にしてmutableは補助的に使うと良いコードになる
256:デフォルトの名無しさん
25/10/05 23:10:55.15 W6M3iXcI.net
Elixirでフィボナッチ数列をいろいろ書いてみた Part. 5
URLﾘﾝｸ(qiita.com)
> Fibonacci with Matrix は素晴らしく速いですね！
Elixirで順に指定個数の素数を列挙する関数をEnum, Stream, Flowで作ってみた
URLﾘﾝｸ(qiita.com)
> 1000,10000個の時にはFlowが最速でした．
1000番目のフィボナッチ数計算すんのに 1.33m秒とか、ベンチマーク結果なんでか編集で消えてるんだけど
> prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms
20000未満の素数算出すんのに 84m秒って遅すぎね?
福岡Elixirってこんな記事ばっかりだな。んで、身内でいいね付けあってる。
257:デフォルトの名無しさん
25/10/05 23:41:25.21 .net
スキルがあるのに福岡なんかにある仕事の給料で耐えられるわけない
258:デフォルトの名無しさん
25/10/06 00:44:13.25 3OKVU+gM.net
>>256
> 20000未満の素数算出すんのに 84m秒って遅すぎね?
ベンチマーク出すのに84m秒って速すぎね?
84m秒のベンチマークを100回やるのがいいのか8.4秒のベンチマークを1回やるのがいいのかで遅いほうがいいと思うんだが
259:デフォルトの名無しさん
25/10/06 01:20:13.00 bQ0ntySb.net
フィボナッチ数は行列累乗を理解してないから乗数の数だけ掛け算やってるし、素数の方は「エラトステネスのふるいを純朴に利用して」と書いてる割に剰余計算で余りがでたものを倍数としてフィルタする処理になってて全然エラトステネスのふるいじゃないなあ、ダメだこりゃ。
どちらの記事もアルゴリズムへの理解がなくて効率悪いことやってるんだが、こういう記事平気で公開してる人が
地球温暖化とコンピュータのエネルギー消費の問題にElixirで立ち向かう〜「コンピュータと地球温暖化は
決して無縁ではない」(2022年版)
URLﾘﾝｸ(qiita.com)
なんて記事書いてて頭が痛い。
これで大学の先生ってなあ、冗談なら良いのに。
260:デフォルトの名無しさん
25/10/06 01:25:15.29 bQ0ntySb.net
>>258
84m秒は100回実行した中央値らしいしそこは問題ないと思う。
> ##### With input 10000 #####
> Name ips average deviation median 99th %
> prime_flow 11.84 84.48 ms ±1.22% 84.27 ms 89.85 ms
> prime_stream 1.14 874.15 ms ±21.02% 787.90 ms 1243.42 ms
> prime_enum 0.81 1233.13 ms ±0.51% 1235.09 ms 1241.00 ms