【アンチ】関数型言語は使えない【玩具】 ２

1 ：デフォルトの名無しさん：2012/02/28(火) 20:45:47.95 .net

前スレ
http://toro.2ch.net/test/read.cgi/tech/1320743217/

2 ：デフォルトの名無しさん：2012/02/28(火) 21:08:37.06 .net

オブジェクト指向言語で関数型風味(？)に書いたらこんな感じ？
http://ideone.com/CXMrq

要素数と実行時間が何の関係無くなるけど
そもそも何を比較してたんだっけ

3 ：デフォルトの名無しさん：2012/02/28(火) 21:38:51.34 .net

今時の技術についていけなくなったら辞めてくださいね

4 ：デフォルトの名無しさん：2012/02/28(火) 22:28:08.33 .net

前スレで関数型言語は玩具にすぎないと結論出たからスレは不要

5 ：デフォルトの名無しさん：2012/02/28(火) 23:03:54.55 .net

>>1乙

前スレ>>992-993
なら、Haskellもコンパイラの進歩でpythonに並ぶ余地はあるって事か

元々、length関数や、++演算子（リストの連結演算子）が初心者にも簡単に作れるってのが気に入ってるだけだから、体感できない速度差は気にならんけど・・・
Haskellに惹かれるのは、defとか、forとか、（モナド使わない限りはifも）そう言うキーワードをなるべく見ないで済むってのが、一番大きい気がする
（というか、forとifが一番見たくない）

あと、基本的に右辺と左辺が=（等しい）なのも気に入ってる

コンパイラのmain=...と言うのも、あながち間違ってない

速度こそpythonに劣るだろうけど、自作のmap関数や、++演算子などの":"で区切られて、状態を次の再帰に引き摺らないものは、単純再帰でも、ループとして扱われる
（だからこそ、末尾再帰は、次の再帰に状態を引き摺らないのでループになる）
結局、アセンブラに実現できることは、関数型言語でも、命令型言語でも、最終的な最適化の形は同じになるだろうけど、それは時間が解決する話

関数型言語の最終的な最適化の形は
http://ideone.com/SaMJe と　http://ideone.com/kzkty が同じ速度になる事

これは、参照透明性が確保されて無いと、最適化できない事の一つ
（まだ実現されてないけし、逆に言えば、参照透明性が確保された関数に限れば、命令型言語でも理論的には最適化可能なはず）

6 ：デフォルトの名無しさん：2012/02/28(火) 23:24:52.82 .net

>>5 最後の行について
Fortran95には、純粋関数/手続きというのがあって、これは副作用を持たない
ということなのたが、ベクトル演算ができるようになる。
が、write文が使えなくなるとか、グローバル変数が使えないとかいろいろ
制約があって非常に使いにくい。

7 ：デフォルトの名無しさん：2012/02/29(水) 00:07:48.89 .net

●過去スレ
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1277215506/
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1286791669/
【アンチ】関数型言語は使えない【玩具】
http://toro.2ch.net/test/read.cgi/tech/1320743217/

●関連スレ
関数型言語Part5
http://toro.2ch.net/test/read.cgi/tech/1252470706/

8 ：デフォルトの名無しさん：2012/02/29(水) 00:20:49.11 .net

速度比較は、よくネタになるけど、最も抽象度の低い言語でも出来る例での比較→言語自体の優劣の流れは無意味だろ。
VBとアセンブラを比べるようなもんだけど、単純作業での比較にこだわる人が多いのはなんでだろう？

9 ：デフォルトの名無しさん：2012/02/29(水) 00:25:12.28 .net

なぜ関数型言語は普及しないか - プログラミング日記
http://d.hatena.ne.jp/morchin/20110614/p1
「なぜ関数型言語は普及しないか」に対する言及
http://togetter.com/li/149656
関数型言語が普及しない理由 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321046483
関数型言語が普及しない理由その2 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321128525
関数型言語が普及しない理由 - 偏見プログラマの語り！
http://d.hatena.ne.jp/kura-replace/20111114/1321236695
関数型言語が普及しない理由 - より良い環境を求めて
http://d.hatena.ne.jp/n314/20111114/1321290502

10 ：デフォルトの名無しさん：2012/02/29(水) 01:47:42.56 .net

>>8 パッと見て、いろいろ言えるからではないだろうか。
そこそこ重たい数値計算をやりだすと、関数型言語が謳う理想通りにいかない
場面はいろいろあるのだが、2chのように限られた字数でしかも関係者外にも
わかるように問題点を説明するのはなかなかうまくいかない。

11 ：デフォルトの名無しさん：2012/02/29(水) 02:30:51.04 .net

個人的にはHaskell、lispはアプリ言語が欲しい時によく使うし、C、Javaはインフラで使ってる。
各言語には目的によって向き不向きがあるから、用途を論じるとか、用途拡大方法を考えるならまだ判る。
同じような単純作業の比較で何を得たいのか判らないんだよね。

12 ：デフォルトの名無しさん：2012/02/29(水) 06:20:45.06 .net

>>8
抽象度が低くてもチューリング完全なら最終的にできることは一緒
どれだけ簡潔に書けるかという意味でいうなら、reverseという簡単な例ですら
CとHaskellには大きな差がちゃんと在った

つーか前スレの配列版HaskellはCの次に速かったぞ
コード量もC並みだが

13 ：デフォルトの名無しさん：2012/02/29(水) 08:54:55.81 .net

>>12
>reverseという簡単な例ですら

そういう単純な例で実行時間が違うのはわかるけどさ、それを言語全体の優劣判定に短絡するのが無意味だと思うんだが。

コンピュータの利用範囲が広がるに連れて、アセンブラだけでは実現に手間がかかるから色んな言語が開発された訳だから。
例えば金融商品企画のようなアプリを、リソースを大量に使えばCでも開発は理屈上は可能だが、
それはもはやHaskellのインタープリターをCで再発明するくらいの問題になる。
だから疑問は、リソースには色々あるのに、なぜ単純な例で時間だけに拘るのか？という事。

単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。

14 ：デフォルトの名無しさん：2012/02/29(水) 11:44:51.88 .net

誰かHaskellが遅いから言語として劣ってるって書いてたっけ？

事実としては「Haskellは遅い」それだけ
言語の優劣は各自で判断すべき

15 ：デフォルトの名無しさん：2012/02/29(水) 11:56:48.77 .net

はっきり数字出ましたし。

16 ：デフォルトの名無しさん：2012/02/29(水) 12:14:19.99 .net

関数型のリファレンス言語と見られる言語が遅かったら
そりゃ価値を見出せないよ

17 ：デフォルトの名無しさん：2012/02/29(水) 13:22:34.34 .net

速さならOCamlがC並ってのは良く聞く
自分はdefとかrecとか関数定義にプログラミング言語特有のキーワード使う機会が少ないのが気に入ってhaskell使ってるけど

18 ：デフォルトの名無しさん：2012/02/29(水) 14:33:26.94 .net

>>13
>単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。

このスレは、既存のHaskellコンパイラより早いHaskellインタープリターを自作出来る猛者が集う場所ですよ？

19 ：デフォルトの名無しさん：2012/02/29(水) 14:33:56.41 .net

遅い遅いって一生言ってろ、でいいんじゃね？

シートベルトって窮屈じゃん、って言ってるバカと同じなんだから。

20 ：デフォルトの名無しさん：2012/02/29(水) 14:40:32.02 .net

>>14
>事実としては「Haskellは遅い」それだけ

そのとおり。
Haskellでできる事は全部、C、Pythonならもっと早く出来る。
時間は重要なリソースだという事は学生にはわからんだろうな。

21 ：デフォルトの名無しさん：2012/02/29(水) 15:16:18.78 .net

>>20
えっ。Haskellの遅延評価のようなことがC、Pythonなら
もっと速くできるなんていっていいのですか。
少なくとも「早く」はできませんよね。

22 ：デフォルトの名無しさん：2012/02/29(水) 15:29:25.53 .net

>>21
そういうときは、コードを書いて「これを書いてみろ」って言うくらいじゃないとね

ていうか、遅延評価は手段のひとつであって、それ自体が目的であることは滅多に無い

23 ：デフォルトの名無しさん：2012/02/29(水) 16:21:54.03 .net

時間という点では開発時間も重要だね

でも長いコードと、それと同性能で短いコードで
前者の方が早く作れたりするのは良くあることだから
コード量と開発時間の相関も割りと微妙なんだよね

学習コストだとか、命令型と関数型の両方を扱える人のうち
関数型の方が早く開発出来る人の割合とかも気になるところ

24 ：デフォルトの名無しさん：2012/02/29(水) 17:05:05.52 .net

haskellが遅いってのは、
c/c++より遅い、あるいは静的言語の中では平均的に遅い、という意味なんだが、
時々文脈を（意図的に？）混同して、スクリプト言語よりも遅いとか言い出す輩が後を絶たない。
前スレで可変長配列と片方向連結リストを混同して勝利宣言してる馬鹿を見た時はまたかと思ったよ。

25 ：デフォルトの名無しさん：2012/02/29(水) 17:06:08.59 .net

>>17
夢を壊して申し訳ないが...

OCaml

http://ideone.com/MqIzH  （リスト）
http://ideone.com/LH93F  （配列）

26 ：デフォルトの名無しさん：2012/02/29(水) 17:06:10.29 .net

藁人形製作乙です。。。

27 ：デフォルトの名無しさん：2012/02/29(水) 17:34:45.71 .net

>>24
Haskellは可変長配列に代表されるような速いデータ構造を
扱おうと思ったら途端に面倒になるのが問題なんだろ

悔しかったらPythonより速いコードをPython並みに簡潔に書いてみろ

28 ：デフォルトの名無しさん：2012/02/29(水) 17:37:02.40 .net

Haskell並みに安全で機械語にコンパイルされたコードをPythonから生成してから言え

29 ：デフォルトの名無しさん：2012/02/29(水) 17:44:34.78 .net

>>28
Haskellが安全？www

xs = head []

30 ：デフォルトの名無しさん：2012/02/29(水) 17:46:18.05 .net

実行速度の比較をしているときに安全とか抽象力とかいうから
虫ケラ、じゃなかった、ハスケラはコミュ障だっていわれんの！

31 ：デフォルトの名無しさん：2012/02/29(水) 17:47:33.28 .net

>>28
Pythonより速いコードをPython並みに簡潔に書けないという
ギブアップ宣言か

もう「Haskell = 遅い」が定着しそうな勢いだな

32 ：デフォルトの名無しさん：2012/02/29(水) 17:54:26.32 .net

pythonは永続データと破壊操作を巧みに両立させて速度稼いでいるからな。
どっかでhaskellの人が永続=透明性と書かない人は理解してない人と断定してたけど、
どうしてhaskellの有名人はみんなアレなんだ？

33 ：デフォルトの名無しさん：2012/02/29(水) 18:20:19.50 .net

おまえの脳内の勢いがすごい勢いで加速中ということはよくわかった

34 ：デフォルトの名無しさん：2012/02/29(水) 18:58:08.72 .net

vectorパッケージが見つからない、と思ったらGHC6.8とはね・・・
古すぎるだろ・・・・
ふふふ残念ながらMPが足りないようだ・・・


・・・とするのは悔しいので前スレのSTUArray版(お借りします)とVector版を手持ちの環境で走らせて計測してみましたよ
STUArray版（コードは省略）
結果（+RTS -sオプションから抜粋）

9 MB total memory in use (0 MB lost due to fragmentation)

Total time 0.12s ( 0.10s elapsed)

次はVector版
コード
module Main where
import qualified Data.Vector.Unboxed as V

main :: IO ()
main = print $ V.head $ V.reverse $ V.iterateN 1000000 (+1) (1 :: Int)

結果

5 MB total memory in use (0 MB lost due to fragmentation)

Total time 0.05s ( 0.04s elapsed)

まあこんなところですね

35 ：デフォルトの名無しさん：2012/02/29(水) 19:34:46.13 .net

隔離スレとして、ちゃんと機能してるようで何より。

36 ：デフォルトの名無しさん：2012/02/29(水) 19:37:34.53 .net

「なんで時間だけに拘るの？」
「遅いのは事実だ！！」
凄いコミュ力だなw

37 ：デフォルトの名無しさん：2012/02/29(水) 19:46:13.50 .net

>>23
>コード量と開発時間の相関も割りと微妙なんだよね

その言語に慣れている者が書くという前提で、一日に書けるコード量は言語による大差は無いというのをどっかで見た。

38 ：デフォルトの名無しさん：2012/02/29(水) 19:55:58.80 .net

コード書いてる時間より
ビルド, 実行, ソースとにらめっこ, ウロウロしながら思考
してる時間の方が長い希ガス

39 ：デフォルトの名無しさん：2012/02/29(水) 19:57:15.64 .net

コード量が同じなら抽象度の高い言語の方が多くの事が出来るだろうな。

40 ：デフォルトの名無しさん：2012/02/29(水) 20:13:38.52 .net

>>39
一般に低水準の言語の方がワード単位の入力時間が短くなる。
極端な場合、倍位にはなる。だから、よほど難しい問題でないかぎり、
>>37がいうように一日に書けるコード量は同じに、近い。
しかし、それだけ体力もいるから、プログラマの定年が若くなる。
高水準な言語だと60歳でも十分。この差は大きい。

41 ：デフォルトの名無しさん：2012/02/29(水) 20:28:55.82 .net

高水準な言語とはもしかしてCOBOLのことを言っているのだろうか。

42 ：デフォルトの名無しさん：2012/02/29(水) 21:33:07.14 .net

リスト操作の速度を比較しようって決まって、
ベンチマークも決まって実装計測して結果が揃ったところで
どうして時間だけとか言い出すのは完全にコミュ障だろw

43 ：デフォルトの名無しさん：2012/02/29(水) 21:38:19.97 .net

数行の「リスト操作」って、何を比較したことにもならんぞw

44 ：デフォルトの名無しさん：2012/02/29(水) 22:18:59.01 .net

>>43 くやしいのうw

45 ：デフォルトの名無しさん：2012/02/29(水) 22:59:57.73 .net

gccがhaskellになったら考える
なったらなったでメンテする人がいなくなりそうだけど

46 ：デフォルトの名無しさん：2012/02/29(水) 23:38:01.82 .net

>>43
まあ元々、アッカーマンとか無視してる時点で、無意味だから。

47 ：デフォルトの名無しさん：2012/03/01(木) 00:21:41.07 .net

haskellが一行で配列を高速にreverseしたのがそんなに悔しいんですか？

48 ：デフォルトの名無しさん：2012/03/01(木) 06:12:44.47 .net

reverse関数「を」どれくらい簡潔に実装できるかって話してたのに
（しかも言い出したのはHaskeller）
ライブラリのreverse関数呼び出してドヤ顔して馬鹿じゃないの？

49 ：デフォルトの名無しさん：2012/03/01(木) 06:19:26.14 .net

>>31を「1行」とかいう人は
目か頭のいずれかもしくは両方とも悪い。

50 ：デフォルトの名無しさん：2012/03/01(木) 06:23:35.74 .net

>>49
???

ああ、自分の頭が悪いって告白ですか
そういうのはパパやママに言ってください
我々の所為じゃないので

51 ：デフォルトの名無しさん：2012/03/01(木) 06:48:15.28 .net

>>46
アッカーマンを無視するってどういうこと？

52 ：デフォルトの名無しさん：2012/03/01(木) 08:08:18.25 .net

>>48
ん、ああそういう流れだっけ？
じゃこれで
module Main where
import Prelude hiding (length, head)
import Data.Vector.Unboxed

rev :: Vector Int -> Vector Int
rev v = generate (length v) $ \ i -> v ! (length v - 1 - i)

main :: IO ()
main = print $ head $ rev $ iterateN 1000000 (+1) (1 :: Int)

9 MB total memory in use (0 MB lost due to fragmentation)
Total time 0.06s ( 0.05s elapsed)

今度はgenerate自作しろって言い出すんでしょうかね（笑）

53 ：デフォルトの名無しさん：2012/03/01(木) 08:26:52.95 .net

っていうか『プリミティブなアルゴリズムが簡潔に書ける！』とか言って
車輪の再発明繰り返して喜んでるだけのhaskellerに問題があるよねえ
（どういう意味にせよ）少しは実用的な話をしようぜ？

54 ：デフォルトの名無しさん：2012/03/01(木) 09:13:52.23 .net

>>50
ああ、43のtypoだと解らない程度の頭なんだね。
カワイソス

55 ：デフォルトの名無しさん：2012/03/01(木) 09:17:06.03 .net

>>52
おそ！

56 ：デフォルトの名無しさん：2012/03/01(木) 10:16:55.81 .net

2chで”流れ”を感じ始めたら、少なくとも二重の意味でヤバイな。

57 ：デフォルトの名無しさん：2012/03/01(木) 11:00:27.41 .net

>>51
関数型が得意なベンチマークでなきゃヤダヤダ


ってこと。

58 ：デフォルトの名無しさん：2012/03/01(木) 12:27:42.50 .net

Rは関数型に入りますか？

59 ：デフォルトの名無しさん：2012/03/01(木) 12:38:56.07 .net

C言語プリプロセッサは関数型に入りますか？

60 ：デフォルトの名無しさん：2012/03/01(木) 16:28:17.22 .net

バナナの皮は関数型言語に入りますか？
λ
形が似てるんですが

61 ：デフォルトの名無しさん：2012/03/01(木) 16:39:32.31 .net

お前、先生が許可したら人も殺すのか
関数型言語を殺すつもりか！

62 ：デフォルトの名無しさん：2012/03/01(木) 19:44:58.10 .net

haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
（一部のみ、先行評価より速い）

そもそも、reverseが単方向リストに不利なわけだが・・・
とりあえず、main/print（ＩＯモナド使った関数）以外の関数を自作してみた

http://ideone.com/15yhM

自分がHaskellに惚れたのは、IO関連以外は言葉遊びみたいな感じで自作出来るのが楽しいから
(rangeはもうちょっと作りこめたかも・・・）
速さよりも、その構造を調べるのが楽しい

data Natural = Zero | Succ (Natural) deraiving (Eq,Ord,Show,Read)

自然数の定義と、リストの定義が似ているのが分かる。
自然数は、その長さそのものが数字としての意味を持ち、リストは長さにも長さと言う意味はあるが、自然数との決定的な違いは、要素自体も値を持っているか？だけだと言うのが分かる


遅延評価生かしたプログラムなら、ファイル処理とかだろうけど、ideoneでファイルの読み込ませ方知らん（と言うか、在るのか？）
ので、一応、こんなのも作ってみた（1から1000000までの足し算の合計のリストを作って、先頭の１０要素を表示）

http://ideone.com/insk7

簡約の様子を見てみると関数同士が絡み合って、一番外側の関数の終了条件のみで、他の関数の終了条件を満たして無くても、関数が終わるのが自然と理解できる

もちろん、最初から無駄の無い処理を書かれると負ける。foldllやmapみたいな、状態を次の再帰に引き摺らない様に書けば、スタック消費が抑えられるって言うだけで、Haskell自体の最適化は弱い

63 ：デフォルトの名無しさん：2012/03/01(木) 22:13:10.07 .net

不覚にも>>60-61の流れに

64 ：デフォルトの名無しさん：2012/03/01(木) 22:56:48.12 .net

なんで、list reverseだけでここまで引っ張ってるんだ!?
>>11を受けて関数型言語/命令型言語の適材適所の話題になると期待したのだが。

65 ：デフォルトの名無しさん：2012/03/01(木) 23:19:04.92 .net

>>64
まあここは隔離スレだし、目的が互いに異なる言語同士を単純作業で比較したがる人が集まる場所でもある。
鳥と魚を比較するのに、共通項目だからといって体重や肺活量で比較するようなもんで、最重要と言えるほどの意味は無いと思うが。

比較するなら、計算モデルからのアプローチ（CTMCPなど）も有るので、該当スレが宜しいかと。

66 ：デフォルトの名無しさん：2012/03/02(金) 10:52:02.59 .net

本スレで煽り質問しかできないバカは回線切って吊れ

67 ：デフォルトの名無しさん：2012/03/02(金) 11:57:42.38 .net

>>62
>haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
>（一部のみ、先行評価より速い）

評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？
遅延評価を使ったプログラムの総時間と混同してないか？

68 ：デフォルトの名無しさん：2012/03/02(金) 11:58:15.19 .net

>>67
X 尊えば
O 例えば

69 ：デフォルトの名無しさん：2012/03/02(金) 13:03:35.88 .net

>>67
>評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ？

遅延評価とか先行評価とかいうのは評価『戦略』であって、『評価するかどうか』を決めるだけだ。
実際に『評価する際』には評価戦略の段階は通り過ぎてるからその問は無意味だろう。

そして遅延評価は評価するまでに猶予を置く意味合いしか無いから、
無駄な計算をしないという仮定のもとでは、遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
>>62のいう『一部』というのはたらい回し関数みたいなもののことを言ってるんだろうが、
あれはグラフ簡約がたまたまメモ化の役割を果たし無駄が省けているためであって遅延評価だからではない。

そもそも速度で評価戦略を語ることがナンセンスだよ。
あれは（たらい回しみたいな）一部の計算を無駄なく書くのを簡単にするためのものだ。
無駄なく書くのが難しくなってる計算の方が多くね、ってのが遅延評価に対して意味のある批判だろうよ。

70 ：デフォルトの名無しさん：2012/03/02(金) 13:11:35.99 .net

>>69
>そもそも速度で評価戦略を語ることがナンセンスだよ。

別にそんな話はしてなくて、「先行評価より早いものがある」について具体例が知りたいだけ。
だから、総時間と混同してないか？って書いたんだがなあ。
どっかでの、Haskell=遅いって話のことなら俺は無関係。

71 ：デフォルトの名無しさん：2012/03/02(金) 13:15:22.81 .net

だからさ、評価戦略によって『評価するかどうか』が決まってからは遅延評価も先行評価も同じ道を辿るんだから、
評価戦略に対して「aはbより早い」とかいうのは論理的に間違ってるってこと。

72 ：デフォルトの名無しさん：2012/03/02(金) 13:20:50.03 .net

>そもそも速度で評価戦略を語ることがナンセンスだよ。
これはhaskellerの負け惜しみとかそう言うんじゃなくてさ、
速度と評価戦略が別次元の問題だってことを言いたいだけ。
haskellのたらい回しとcのたらい回しは記述が似てても、
『そもそもやってることが違う』んだから。

73 ：デフォルトの名無しさん：2012/03/02(金) 13:37:52.45 .net

遅延評価は計算量を減らす目的もあるけどそれが全てじゃないよね
それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし

割と手軽に計算量を減らせる(処理系にお任せ出来る)ってくらいだろう

無限リストとかを評価しちゃうと氏ぬのは言語に関係無いから
その辺はCでも配列でなく関数とかで仮想化するし

74 ：デフォルトの名無しさん：2012/03/02(金) 13:45:42.93 .net

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
いや、まったく同じ計算をするなら同じ処理時間になるよ。
ならないとしてもそれは遅延評価のせいではない。

75 ：デフォルトの名無しさん：2012/03/02(金) 13:47:20.92 .net

＞遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
よくみると俺もこんな発言をしていた。
俺も論理的に間違っているということだな（ｷﾘｯ

76 ：デフォルトの名無しさん：2012/03/02(金) 13:51:12.30 .net

>>64
ネタの投下も無しに贅沢な
それに、>>62はプリミティブな関数が自作出来るのが楽しいって言ってるだろ
python版出すなり、新しいネタ出すなりすれば良い

77 ：デフォルトの名無しさん：2012/03/02(金) 13:54:12.03 .net

＞それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
というか『適うわけない』と思った根拠はなんなのだ？
論理的に同じ計算をするならあとはなんというか、言語の基礎体力だけの問題になるはずだが。
あれか、haskellではIntがボックス化されているからとかなんかそういうのか。

78 ：デフォルトの名無しさん：2012/03/02(金) 13:56:34.33 .net

>>74
＞まったく同じ計算をするなら同じ処理時間になる
同じロジック書いても
遅延評価を実装するために発生するオーバーヘッドとかの影響で
まったく同じ計算(機械語レベルで)にはならないんじゃないの？

79 ：デフォルトの名無しさん：2012/03/02(金) 14:03:36.00 .net

>>77
＞言語の基礎体力だけの問題
そうだよ、そういう話
例え同じロジックでもインタプリタ方式の方が遅いとかそういうの

Cは安全性を犠牲にしてでも速度優先するってコンセプトがあるわけだし

80 ：デフォルトの名無しさん：2012/03/02(金) 14:11:15.32 .net

>>-79までの中に、62が居るとのお告げがあった。

81 ：デフォルトの名無しさん：2012/03/02(金) 14:18:12.44 .net

>>78
遅延させることに意味がある場合、それはオーバーヘッドとは言わないんでは？
計算結果を明示的にキャッシュするのだってもちろんスペース喰うわけで。
そういうことじゃなくてGHCの実装の深いところに基づくオーバーヘッドだというなら、
俺にもよく分からないが、お前にはそれが有意な差であると合理的に説明できるのか？

82 ：デフォルトの名無しさん：2012/03/02(金) 14:20:45.94 .net

>>80
そのレスバグだろ
開始インデックスの指定漏れてんぞ

83 ：デフォルトの名無しさん：2012/03/02(金) 14:35:31.40 .net

>>81
意味有る無しに関わらずオーバーヘッドと言うよ
機械語レベルでの違いによるものなら大小に関わらず有意だよ

84 ：デフォルトの名無しさん：2012/03/02(金) 14:38:40.45 .net

>>83
呼ぶのか。なるほど。
それは明示的に計算結果をキャッシュするコストと比べてどうなの？

85 ：デフォルトの名無しさん：2012/03/02(金) 14:39:21.82 .net

このコストっては手間的な意味じゃなくてね

86 ：デフォルトの名無しさん：2012/03/02(金) 14:41:06.81 .net

あと機械語レベルで差が出るというソースは？
簡易なものなら是非見てみたい。

87 ：デフォルトの名無しさん：2012/03/02(金) 14:44:46.65 .net

無いと思うならそれでいいよ
haskellはcと同じ速度ってことでさ

88 ：デフォルトの名無しさん：2012/03/02(金) 14:45:35.68 .net

まあ説明できないことは最初から分かってたさ

89 ：デフォルトの名無しさん：2012/03/02(金) 14:49:53.34 .net

オーバーヘッドがあったとしても遅延評価には利点があるという話だったんだけど
ここまで速度に拘るとは思わなかったからね

90 ：デフォルトの名無しさん：2012/03/02(金) 14:53:17.52 .net

あるかどうかもよく分からないオーバーヘッドの話を持ち出したのはそちらではなくって？
まあね。実際俺もあるとおもうよ。オーバーヘッド。
話として持ち出すからには根拠を持っていてほしいなと思っただけさ。

91 ：デフォルトの名無しさん：2012/03/02(金) 14:56:03.90 .net

ちなみに俺がオーバーヘッドがあると思ったのは
単にゼロオーバーヘッドでの実装は無理だろうと思ったのと
「c言語 haskell 速度比較」とかでググッた結果を見たというだけ
流石に個々の速度比較の詳細までは知らない

逆にオーバーヘッドが無いってのを示してくれたらもちろん前言撤回するよ

92 ：デフォルトの名無しさん：2012/03/02(金) 14:59:04.52 .net

こんなスレにいる駄民がそんなことを示せるわけ無いじゃないか！俺のことだよ！

ていうかよくよく読み返すと>>78は疑問文だねえ。
俺が謝ったほうがいいのかも知れない。
だがわたしは(ry

93 ：デフォルトの名無しさん：2012/03/02(金) 16:34:36.45 .net

遅延評価って、一見全部読み込んでから一部だけ出力するって処理で、必要な分しか読み込まないってので、>>62の上のmyreverseはリストを反転する必要があるから、全部読み込んでるけど、下のaddlistをmytake 10 してる方は、最初の10要素分しか読み込まない
先行評価だと、全部読み込んでから始まるか、最初の10要素だけ読み込む様に書き分ける

ファイル処理とかで、書き分ける必要が無い事になる

とは言え、最近の言語なら、オブジェクトにその辺の処理を押し込んでそうだが

94 ：デフォルトの名無しさん：2012/03/02(金) 16:37:16.86 .net

オーバーヘッドつーか、評価機構の構造自体が違うのに、
全体の処理時間が同じなわけがないだろjk

95 ：デフォルトの名無しさん：2012/03/02(金) 17:43:05.82 .net

正格評価でもありとあらゆるところにdelayとforceを忍ばせれば
遅延評価になると思うんだけど
計算量が減るところだけ遅延評価にした方がやっぱりいいと思うんだよね

96 ：デフォルトの名無しさん：2012/03/02(金) 20:31:03.15 .net

>>93
そのかわり、ファイル読み込んで同じファイルに書き出すときとか
「あー、この辺で正格評価するべ」的なこと考えんといかんけどな

97 ：デフォルトの名無しさん：2012/03/02(金) 23:50:52.90 .net

配列のreverseくらいならC++でも一行だな
std::copy(in.rbegin(), in.rend(), std::back_inserter(out));

98 ：デフォルトの名無しさん：2012/03/03(土) 00:36:28.38 .net

最近の関数型って実装まで気にするような段階なんだな
はてなあたりの選民気取りが「haskellはCより速い(ｷﾘｯ」とか言い始めたら俺もそろそろ関数型始めようかな

99 ：デフォルトの名無しさん：2012/03/03(土) 05:11:01.91 .net

速度稼ぐ必要があるコードだと結局はモナド頼りなんだろ？

関数型言語って名前捨てて”モナド型言語”とでも呼べばいいんじゃね？

100 ：デフォルトの名無しさん：2012/03/03(土) 06:46:14.07 .net

おめえらhaskell以外の話もしろよ