なあ、再帰関数好きな人いる? パート3 [転載禁止]©2ch.net
ループで書けるものはループで書く。
再帰使うのは仕方ない場合だけ。 スタック的なメモリ確保が必要かどうかがループと再帰を使い分ける分岐点じゃね。
末尾再帰最適化とかは本末転倒なイメージ。 >>5
ループ実装を隠せるのは大きいよ
抽象化はプログラミング言語の進化のベクトルと一致するからね ループより再帰のほうが抽象度が高いと言っている?
そこは俺にはよくわからん。
俺的にはプログラムには必要最小限の機能を使うべきで、
本質的にループより再帰のほうが強力なのだから
可能な限りループを使うべきと思ってる。
もちろん再帰をループにするためにスタックを自前で用意するといったことでは本末転倒だが。 ツリーの巡回は再帰を使ったほうがいいだろう。
リストの巡回はループでいいんじゃね? >>8
> 俺的にはプログラムには必要最小限の機能を使うべき
そういうのはコンパイラなりインタプリタなりが頑張るべきところだと思うね
人間はより抽象化された対象を扱うようにするのがモダンなプログラミング言語の方向だし うーん。必要な抽象化は歓迎するが無駄な抽象化は歓迎しないというか。
この例は再帰とは関係ないけどJavaのファイル入出力なんかは
結構複雑な作りになってて無駄な抽象化なんじゃねーのとか思ってしまう。
まあ、俺個人の感想だが。 アルゴリズムが再帰なら普通に再帰で書く
スタックサイズ制限とかあるなら別だけど アルゴリズムが再帰であってもクイックソートなど
再帰のままじゃあ使い物にならんものがいくらでも。 書いたことはあるけど10年以上昔の話だな。
これは拾い物だけどクイックソートなんてこれだけのことだろ。
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs) クイックソートは単純な巡回とは違うだろ。
だからスタック的なメモリを必要とするかどうかだよ。 filterの実装がどうなってるかまでは知らんがな。 なんか変なテンションだなぁ
俺がC++とかでfilter相当の関数書かにゃならんくなったらループで書くよ。 クイックソートはhaskellでfilterはc++なんか?
なんか変な奴だなぁニヤニヤ 何が変か、わからん。
まあ関数型言語なんかは再帰推奨らしいがあんまり好きになれん。 推奨なんて生易しいもんじゃないで。
理論に囚われすぎて原理主義に陥いった餓鬼共やw >>8
ループでquicksort書いてみてくれ
上のコードと比較で見るだろ
言語は好きに選んでいい ループでクイックソート書こうとするとスタック的なものを自前で用意せにゃならんのじゃないか。
めんどくさすぎ。 なんかやたらと再帰がお遊びだと連呼する奴がいるが、どういう意図で言っているのか分からん。
お遊び感覚で動くものが作れるのだから、苦労しなくていい分優れているってこと? >>25
関数型言語は変数再代入禁止(のものが多い)から、そもそもループは書けないんだよね 再帰がお遊びだ
再帰がお遊びだ
再帰がお遊びだ
>>32が可哀想だから連呼してあげたよ あ、意味は「お遊び感覚で動くものを作るな」という事です。 関数型は関数脳にならないと書けないからねー
手続き脳がしみついてると貶す対象にしかならないよね せっかく埋め立てたのに何またスレ立ててんのゴミクズ ぼくたん初心者なのでわからんけど僕が今作ってる
関数から値を求める計算プログラムで再起型関数が大活躍してるお
たぶん今僕がやってる書き方が一番きれいだと思うんだけどなー > たぶん今僕がやってる書き方が一番きれいだと思うんだけどなー
いろんな方法で書いてみないと比較できないんじゃね? クイックソートで再帰なんてありえんと
さんざん言われ続けているのに、まだバカが湧いとるんだな。
ライブラリのループ版を使えば何の手間もかからず高速処理ができるのに
わざわざ問題ありまくりの再帰で書くなんてテロ同然の暴挙。 >>44
それって結局真の再帰を見たことがないからそう思い込んでるだけだよね。
見せてやるよ、真の再帰ってやつをな。
https://ideone.com/EDtRIH もうソーティングの話は良いよ、仕事で使う大抵の言語ではライブラリとして用意されてるんだから。 >>45
再帰じゃあ、10件程度のソートに控えるという事なんだよな。 10件程度のソートならソーティングネットワークによるソーティングが一番速いから
十分少ない要素数に対してはそいつを呼び出して終わりだろ。
書いてないだけだろうけど。 >>9
俺の見解では、ツリートラバースに再帰を必要とするのはデータ構造に問題があると思うんだよな。
イテレータの実装を考えると再帰はちょっと無理があるんじゃないかと思う。
もちろん出来ないわけではないのだが。
ノードが子ノードを保持するような原始的なデータ構造は良くないのではないか。 代表的なツリーの一つとしてHTMLがある。
HTMLのフラグメントを切り出し、別のノードの子として加えるような操作を考えるとき、
これはやはりループに軍配が上がると思う。
もちろん、ノードに子ノードを保持するような原始的なデータ構造ではかなりメンドクサイ。
というのもHTMLの一部を切り出す時、ノードの種類によって、ノードの分割や併合が起こる。
再帰と原始的なデータ構造では非常にめんどくさい。
私はこの用途のために直列化ツリー構造というデータ構造を考案した。
(おそらくすでに一般的に使われているとは思うのだが。) ループは再帰の特別なケースに過ぎない
ループの方が無駄がなく見える事もあるだろう
だが結局はその程度の話だ >>49
> イテレータの実装を考えると再帰はちょっと無理があるんじゃないかと思う。
問題はデータ構造の方じゃなくて言語の方だと思う。
というのも、yieldを持つ言語なら再帰を使ったやり方が最も簡潔に書けるから。
-- language:lua
function traverse(node)
if node then
traverse(node.left)
coroutine.yield(node.value)
traverse(node.right)
end
end
co = coroutine.create(traverse)
not_end, value = coroutine.resume(co, node) >>52
ちょっとそのやり方で、HTMLの一部をコピペするコード書いてみて。 >>53
一部ってのはどういう風に探すのん?
特定の属性を持ってるタグを探す感じ? >>54
HTMLのコピペがいつ起こるかというと、ユーザーがその操作をした時なので、
そういう前提で設計してはどうでしょうか。 HTMLをユーザーの直観に適合する形で操作するのは意外と難しいですよ。
HTMLフラグメントの移動なんてどうですかね。
面白い題材だと思うのですが。 >>52>>53を繰り返しで書ける人はいないみたいだね。 そういやC++のstd::mapのイテレータとかってどうなってんるのん? >>62
ノードオブジェクトに親を指すポインターもあって愚直に辿ってる。
赤黒木使ってるのが殆どだから、
レスしてる奴もコード読めない奴の方が多いんじゃないかw データを吐き出す方法として前方イテレートしかしないの前提ならB+木がループでトラバース出来る上に高速なんだけど
挿入と削除を頻繁にするなら、そしてデータがキャッシュに乗り切らない程度に沢山あるなら赤黒木が高速になる
全部キャッシュに乗る程度の小さなデータ数ならAVL木が高速で
更に小さいならベクタ上にヒープ木でも作ればって話になる。
どの構造でも再帰で列挙出来るけど、ループでAVL木や赤黒木のデータを列挙するのは骨だな 再帰・ループの相互変換が難しいとかさあ
アルゴリズムの根本的なところ理解してないだけ
恥ずかしすぎるこのスレ f(0,b)=b+1
f(a,0)=f(a-1,1)
f(a,b)=f(a-1,f(a,b-1)) >>66
>>67をループに変換するのは難しくないんだね?
ちょっとやってみせてよ。 再帰・ループの相互変換が難しいとかさあ
アルゴリズムの根本的なところ理解してないだけ
無能の>>68 は、勉強しろ。 >>71
無能でーすチッスチッス
インターン先はGoogle(技術職8週間、コンパイラを改良するお仕事)でしたが何か?
今The Art of Computer Programmingの英語版の2巻読んでるんだけど
次に読むべき本は何?
>>72
数式から雰囲気掴むことも出来ない重度のアスペだから仕方ない。 >>73
uyの残した名言
何で出来ているか?というのは愚問過ぎる
例えばそれを「uy」としましょう
「uy」から派性したAやBといった概念から「uy」を辿る事は出来る
例えばこの世界にある「オブジェクト指向」という概念や「量子ビット」といった概念から
「uy」を辿る事が可能なので、
それらで世界が出来ているといった勘違いが可能なのです
でもそれは、一体いくつ「uy」から継承がネストしていて、プログラム等でいえばメソッドが追加されてしまった純粋性のない概念なのでしょうか?
それを知っているのは「uy」だけです
この世界にあるすべての概念は「uy」へと通じているので、
料理人は料理を通じて世界を知り、スポーツ選手はスポーツを通じて世界を知ります
誰も「uy」からは逃げられないんだよ >>74
酉とIDくらい見なさいな
# どうでもいいけど最近障害者3級取ったわ あぁ、俺がuyと同一人物だと勘違いされたのではなく、
uyって人がそういう名言を残したって話か
ごめんごめん んでuyちゃんのループ問題はまだ解決しないのかしら まさにuyがアルゴリズムの根本的なところを理解しているかどうか問われているなw それな、今までC++スレ読んでてこいつ頭おかしいなとは思ってたけど実力が問われるよな はてさてuyの実力は如何。
# 俺自身の実力はさておき。 uy自力で頑張ってんのか?
なかなか根性あるじゃないか。
俺ならググって解答見てしまうがw 再帰で書かれた超有名な関数をループにするだけの簡単なお仕事なのに
何ですぐに出来ないんだろうね?
# 全然簡単じゃないからです 末尾再帰に書き換えてから蓄積引数を中に押し込んでループにするんだよ。
やり方を書いたのだからきっとuyにもできるはず! >>85
普通に悩んだけど再帰なら一瞬でとけんのに
ループじゃまず何のデータ構造を使っていいかわからん。 スタックだろ。
再帰とループ+スタックは等価。
理屈ではそうだが実際やるのは結構難しいんじゃね。 >>70
http://ideone.com/KDSDTc
「この程度」が難しいとか言われても
は? としか思えない
再帰というのは単なるスタック付きのループであって
君たちがどこら辺で躓いているのか理解できないんです
やっぱわからない所がわからない状態なんだろうけど、
つうかSTACKUって知っていますか? ちなみにここ一週間のuyの生活は、朝起きて、ネトゲして朝寝る です。
ちょうどいま、起きたところではなく24時間起き続けていたので今から寝る前でした
とあるゲームであと100戦程の対戦をこなし、誰よりも速く称号を獲得しようとしてる最中です
2chのム板なんて頻繁に開いてる暇とかないし結構忙しいんですわ 自分には分からなかったわ
じゃあ質問なんだけど、再帰は全てスタック+ループで書き換えられるの? 連投だけど分かったかも、
再帰で帰ってくるべき値をスタックしておくってことでループ+スタック=再帰なのね >>89
問題のすり替えはいけないな。
俺は「難しくないならやってみて?」って言っただけで
そもそも「再帰のほうがループより圧倒的に簡潔に書けるよね?」って文脈だろ。
君が「難しいから出来るもんならやってみろ」って捉えたかどうかなんざ知らんがおつかれさん
うんうん、言いたいことは分かった。
それで、そのコードのどこら辺が綺麗なの?
ちなみに機械的に変換したのがこちら(rubyじゃなくてごめんよ)
https://ideone.com/XsZh4c
fとhは機械的に変換したという意味では等価だし君のコードとほぼ同じ事をしてるのだけど、
h関数をパッと見て>>69式と等しいって言うのは凄く度胸が居るよね?
>>92
そもそも再帰をどうやってソフトウェア実装してるかというとコールスタック+ジャンプ≒スタック+ループな訳で
# ちなみにスタックの正しいスペルはstack。stackuなんて子は知りませんね。 >>96
そうなのか、、、
ならできるようにならなきゃだな >>92
再帰は機械的にCPSに書き換えることで末尾再帰にできて
そうしたらそれをループに書き換えられる
両方証明されてる >>97
アセンブリ言語によくあるcall系命令の挙動を正確に言えるようになれば
どんな再帰もスタックとループで書けるようになるよ
何しろスタックとループで再帰を表現してるのがcall系命令だからね。
それをそのまま書くとこんな具合に超汚くなるけど。
https://ideone.com/0QXd8O