関数型プログラミング言語Haskell Part34 (667ﾚｽ)
関数型プログラミング言語Haskell Part34 http://mevius.5ch.net/test/read.cgi/tech/1639713446/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
37: デフォルトの名無しさん [] 2022/01/03(月) 08:08:25.82 ID:hLrwvjQQ まぁコレは趣味による Haskellでは性能面より可読性を重視するからな それも使う人次第だけど >>34のようにすればメモリも時間も節約できるけど可読性は失われる どこまで我慢するかだけどオレは計算時間もメモリも線形までなら我慢して可読性を重視する >>34だと入力に比例して要求されるスタック量が増える 線形までならしょうがないと思う どのみち入力が大きくなるにつれてシステムが大きくなるのは元々しょうがないんだしその時の比例定数の違いまでなら我慢する 今具体的にやりたいことがあってその線形オーダーの無駄すら許されない状況なら考えるけど http://mevius.5ch.net/test/read.cgi/tech/1639713446/37
39: デフォルトの名無しさん [] 2022/01/03(月) 12:59:34.38 ID:hLrwvjQQ 今回の場合１ワード消費するたびにスタック一個消費するから必要なメモリリソースが倍以上になる可能性もあるから意味はあるかな 特にコレは>>34の方法だと必要なメモリリソースがデータ保持する分を除けばlogオーダーになるからな しかも読み込んだデータは順次捨てていけるし(そこまでのカウント結果を保持しないといけないので有限オートマトンでは無理だけど有限オートマトン以上、チューリング完全以下、こういう計算クラスは名前ついてるのかな？) 個人的にはこういうときメモリ線形、時間線形までは許さないと大した事できないことが多いのでそれ以上のこだわりは持たないようにしてる 数学的研究対象とかにするなら別だけど http://mevius.5ch.net/test/read.cgi/tech/1639713446/39
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.031s