関数型プログラミング言語Haskell Part34 (688レス)
上下前次1-新
抽出解除 必死チェッカー(本家) (べ) 自ID レス栞 あぼーん
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
38: デフォルトの名無しさん [sage] 2022/01/03(月) 11:20:12.64 ID:TEX8BSo6(1/2) AAS
>>3737(1): デフォルトの名無しさん [] 2022/01/03(月) 08:08:25.82 ID:hLrwvjQQ(1/2) AAS
まぁコレは趣味による
Haskellでは性能面より可読性を重視するからな
それも使う人次第だけど
>>34のようにすればメモリも時間も節約できるけど可読性は失われる
どこまで我慢するかだけどオレは計算時間もメモリも線形までなら我慢して可読性を重視する
>>34だと入力に比例して要求されるスタック量が増える
線形までならしょうがないと思う
どのみち入力が大きくなるにつれてシステムが大きくなるのは元々しょうがないんだしその時の比例定数の違いまでなら我慢する
今具体的にやりたいことがあってその線形オーダーの無駄すら許されない状況なら考えるけど
今回のお題はワードカウント、ファイルサイズがギガになる場合を想定
スタックなりヒープなりを消費しない手法は?です
Cなどで実装した場合、ループでカウントして再帰なしスタックもヒープも消費なしとか(可読性は...)
他にマルチスレッドで分割カウントした時の手法とか(ディスクのIOで律速か)
40: デフォルトの名無しさん [sage] 2022/01/03(月) 15:29:08.17 ID:TEX8BSo6(2/2) AAS
>>3939(1): デフォルトの名無しさん [] 2022/01/03(月) 12:59:34.38 ID:hLrwvjQQ(2/2) AAS
今回の場合1ワード消費するたびにスタック一個消費するから必要なメモリリソースが倍以上になる可能性もあるから意味はあるかな
特にコレは>>34の方法だと必要なメモリリソースがデータ保持する分を除けばlogオーダーになるからな
しかも読み込んだデータは順次捨てていけるし(そこまでのカウント結果を保持しないといけないので有限オートマトンでは無理だけど有限オートマトン以上、チューリング完全以下、こういう計算クラスは名前ついてるのかな?)
個人的にはこういうときメモリ線形、時間線形までは許さないと大した事できないことが多いのでそれ以上のこだわりは持たないようにしてる
数学的研究対象とかにするなら別だけど
今回なにを確認したのか
それは、Cで組むような単純繰り返しを同じ感覚でヒャッハーとhaskellの遅延評価で行うと
ヤバイと言う教訓とそれを回避する手法
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.029s