Qiita 7 - キータぞ、来たぞ、キータだぞー

Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次 1-新

27: 2025/09/15(月)08:41 ID:7N5dcPCF(1) AAS
一番シンプルにわかりやすい>>19を再帰呼び出しのままは厳しいな
appendするたびに作り直すらしいGoの仕様が足を引っ張ってるのだろうか

28: 2025/09/15(月)09:31 ID:G/lRv3X8(1) AAS
今のQiitaはこの程度の話すらコメ欄ではできないのがクソなんだよなあ。

29: 2025/09/15(月)12:47 ID:aenReHhk(5/8) AAS
なんか同じパラメータでの呼び出しを2回繰り返すと ReverseArray13 と ReverseArray19 だけ 2回目の速度が向上するな?

外部ﾘﾝｸ:ideone.com
> 1000:
> ReverseArray9: 0.000003
> ReverseArray13: 0.000089
> ReverseArray19: 0.000174
> ReverseArray24: 0.000007
> 1000:
> ReverseArray9: 0.000004
> ReverseArray13: 0.000005
省13

30: 2025/09/15(月)13:03 ID:aenReHhk(6/8) AAS
要素数を1000から1000刻みで増やしていくと6000でガクッとパフォーマンス落ちてるな。
外部ﾘﾝｸ:ideone.com

再帰呼び出しを深く行うことでスタックが足りなくなりスタック領域の拡張が行われそれでパフォーマンスが落ちてる気がする。
予めスタック領域が十分拡張されてれば ReverseArray13 と ReverseArray19 のパフォーマンスも 1回目から比較的マシになりそうな気がする。

31: 2025/09/15(月)13:16 ID:aenReHhk(7/8) AAS
AA省

32: 2025/09/15(月)13:23 ID:aenReHhk(8/8) AAS
>>25で
> ReverseArray24が案外良いのは恐らくは再帰呼び出しをループにする最適化が行われている感じ。

というのは多分間違いで、ReverseArray24 の前に実行している ReverseArray13 や ReverseArray19 のお陰でスタック領域が予め拡張されていたため ReverseArray24 の実行でスタック領域拡張処理が発生しなかったことがパフォーマンスが案外良かったことの原因と思われる。

33(1): 2025/09/15(月)19:24 ID:OSZOiNza(1) AAS
IDコロコロ切り替えてる人は自分の投稿に自信がないのかな

34: 2025/09/15(月)22:14 ID:wx2AhEF9(1) AAS
>>33
いや自信ないのはお前
いまはIDコロコロを言う流れでない
直前の投稿は同一IDで8件投稿してIDコロコロでない
安価なくIDコロコロと言われても何を言ってるのかわからない
お前が自分の投稿に自信ないのは空気を読めず日本語が不自由だから

35: 2025/09/16(火)01:27 ID:JSTZ1Kt/(1) AAS
IDコロコロに反応する人がいるのは面白いねえｗ

36: 2025/09/16(火)02:12 ID:NVXmEvhV(1) AAS
図っ星

37: 2025/09/16(火)09:08 ID:zaWo9xwV(1) AAS
Qiitaのコメ欄で有意義な議論ができない問題、バカなこと言ってる側が複垢使うとかで相手を攻撃的と通報する可能性までありそうだなｗ

38(1): 2025/09/16(火)19:41 ID:Wr/gNYaO(1) AAS
>>9や>>24のコードがダサくて>>19がシンプルなのは再帰の有無ではなくコードの抽象的な度合いが原因だと思う

39: 2025/09/17(水)08:59 ID:JW/5kEOI(1) AAS
数学的に言うと Σ(Sigma) は
再帰の方が抽象的なんか？
ループでも等価だと思うんだが

40: 2025/09/17(水)09:21 ID:0mQm0ojt(1/3) AAS
>>38
再帰を使わないシンプルな版を書いて主張すれば良い

41(1): 2025/09/17(水)09:26 ID:MzfCTW9l(1) AAS
>>9
arr[n - i - 1]が不格好ではあるな

42: 2025/09/17(水)10:55 ID:0mQm0ojt(2/3) AAS
>>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(1): 2025/09/17(水)21:20 ID:0mQm0ojt(3/3) AAS
しまったー！
ElixirChip初お目見え会今日だったじゃーん
忘れてたわー！ざーんねーん！
とか言ったりして。

44(2): 2025/09/17(水)22:01 ID:+QFNSyi5(1) AAS
配列などの各要素を巡る抽象化はイテレータだよ
抽象化の役割分担がわかりやすいRustで説明すると
今回の各要素の順番を逆順にしたベクタを作る関数はこうなる

fn reverse_value<T: Clone>(input: &[T]) -> Vec<T> {
input
.iter() // 各要素への参照を巡るイテレータ
.rev() // それを逆順に巡る
.cloned() // 各要素への参照から値を複製して値を得る
.collect() // それらの値を今回は返り型で指定のVecへ収集
}
省11

45: 2025/09/17(水)22:14 ID:Iu+PtAN6(1/2) AAS
改行CRとLFの真実：MS-DOS・BIOS・WIN10での挙動比較
外部ﾘﾝｸ:qiita.com
> Windows10
> '\r'で行頭に戻ることは確認できましたが、'\n'では下の行に下がるだけでなく行頭に自動的に戻されてしまうようです。

'\n'で行頭に移動するのはC言語の仕様で「\n 改行（new line）現表示位置を次の行の最初の位置に移動する。」となってるからで、WindowsではユニバーサルCランタイム (UCRT)が標準出力をテキストモードでオープンしてるため '\n' が '\r' + '\n' に変換されるからで、さらに最近の Windows Terminal は '\n' の動作が行頭に移動するようなってるので、とか説明せんといかんのかな、メンドい。

46(1): 2025/09/17(水)22:54 ID:Iu+PtAN6(2/2) AAS
せっかくなので>>44の関数のベンチマークをしてみた。
外部ﾘﾝｸ:godbolt.org

reverse_value() のほうがちょっと速いのかな。
Rustって知らんけどblack_boxなんてあんのは面白いな。

上下前次 1-新書関写板覧索設栞歴

あと 722 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.015s