■http://anond.hatelabo.jp/20120705091019

いや、再帰は使わんと思うぞ・・・Stack Over Flow対策があるから自前で再帰は展開するぞ。

「Cならswitchテーブルを使った再帰関数で実現する必要がある」に対するレスなんだろうけど、飽くまでも「C以外の、継承とオーバーライドの機能がある言語では例題とほぼ同じ形で実装できるのに対してその機能がない言語では『関数内でswitchをして値ごとにdispatch、その後更に再帰』という原始的かつ全てのロジックを詰め込むせいでひとつの関数の行数が膨大になる問題を孕んでいる」という意味しか持たない。

確かにTopCoderで再帰を使ったら撃墜される可能性がある事には同意だけど、今回の例ではプロコンの外側での事であってスタックがオーバーフローしたなら例外をキャッチして後処理を行えば良い。

更に

問題を解くためにバイナリーツリーを使うことはあっても、バイナリーツリーを使う問題は出てこないわなぁ。

C++なら、setもmapもあるし。

バイナリツリーを自前で構築して式を表現する例題（expression tree）と、set and mapは用途が違う。

setとmapは本来、順序が定義できる要素をキーにしてそれそのものを保持するか、或いはそれに伴う値を結びつけて保持しておくもの。

例題のexpression treeの構造は「（必ずしもオペランドがふたつとは限らない）式の木を表現して、オーバーライドされたevalで式全体の評価を行う」もの。

だから目的が違う以上

あと　加算するか減産するかはアルゴリズムが持つものであって、木そのものが持つわけじゃない。

は成り立たない主張であるし、

全般的にその木構造なんかへんやろ。例題なのはわかるけど、それにしても、なんか変。

即興で書いたので変である事は否定しないとしても

開発言語なんて問題を解く道具であって、文章の綺麗さを競うものではないからなぁ。

（C言語等のOOPが導入される前の言語で）綺麗に書く事ができないと問題を提供する側がそもそも「綺麗な解を前提とした問題」を出せない。

Permalink | 記事への反応(1) | 09:38

ツイートシェア