関数型プログラミング ..
751:デフォルトの名無しさん
05/11/13 22:17:02
>>749
母関数から特定の項を取り出す手間とボトムアップに解を構成する手間はいっしょ
752:デフォルトの名無しさん
05/11/14 06:49:45
>>751
母関数から特定の項を取り出すのは紙と鉛筆で簡単にできるでしょ。
わざわざプログラムなんて書く必要もない。
753:デフォルトの名無しさん
05/11/14 20:09:53
>>752
詳しく頼む。
俺は Polya の本にその母関数の一般項の計算には DP を使うと書いてあったので、無理だと思ってたんだが。
754:デフォルトの名無しさん
05/11/14 23:45:35
>>753
組み合わせ論の入門書やConcrete Mathに出てるようなんじゃだめなの?
755:752
05/11/15 00:16:35
>>754
Concrete Math の p.331 から 2 ページくらいで計算されてるやつ?
この例の最初のところに「一般の効果の場合に計算するのはとても難しい」とあるし,
その下で計算されてる {1, 5, 10, 25, 50} の特殊例においても「trick」と称される
計算をしないといけないし,さらに,最終結果に残ってる A_k は多項式を実際に展開しないと求まらない.
というわけで,これは一般性が無いという意味で >>744 が母函数から簡単に出るという
説明にはなってないし,特殊例を含めても >>752 の「簡単」ってのはどうかと思う.
コレじゃないならポインタください.
756:デフォルトの名無しさん
05/11/15 21:19:55
Haskellのデータ構築子が非正格なのは便利なんだけど、
一般の関数が非正格で嬉しいことってある?
デフォルトで正格でも良いような気がするんだが。
757:デフォルトの名無しさん
05/11/15 21:44:13
以下の二つが大きいそうだ
・相等性についての議論が楽になる(単純に置換するだけでOK).
・制御構造を自分で設計できる.
cond p x y | p = x
| otherwise = y
recip x = cond (x == 0) 0 (1/x)
は正格なら recip 0 = bot, 非正格なら recip 0 = 0.
758:デフォルトの名無しさん
05/11/15 22:37:48
>>757
反応ありがとう。
>・相等性についての議論が楽になる(単純に置換するだけでOK).
なるほど。気付かなかった。
でも、現状だとIntのaccumulator引数付きのちょっとした末尾再帰関数なんかを書くたびに
明示的に正格評価を指定しないとパフォーマンスに打撃があるわけで、
「議論が楽になる」って利点はこのコストに見合うんだろうか。
…などと思うのは俺が言語を使うだけの立場だからかな。
>・制御構造を自分で設計できる.
これはどちらかというと特殊なケースだから、非正格をデフォルトにする理由としては弱いと思う。
759:デフォルトの名無しさん
05/11/15 22:56:10
もともとは研究者の研究者による研究者のための言語だから、
コストパフォーマンスより性質を重視してるんじゃない?
ていうか、非正格の言語を統一する目的で作られた言語だしね。
正格がデフォルトの言語はMLを始めすでにいっぱいあるから
そっちを使ったらどうかな。
760:757
05/11/15 23:37:37
>>758
俺は前者も後者も重要と思ってるんだけどね。まあとりあえず前者について少し強く推しておく。
「three x = 3 」 と定義したときに、「 2 + three x == 5 」 が成立するかどうかを判定することを考える。
これを非正格に評価するとthree x を単純に 3 に置き換えて 2 + 3 == 5 にして、成立する、と結論が出るんだけど、
正格評価だと、x が絶対 bot にならないなら成立、そうでないなら不成立、というようにドメインまで考えないと駄目になる。
特に函数が複雑に組み合わさってる場合に、どこかで bot になる可能性があるとかそういうことを考えるのはしんどいし、
上の函数でもそうだけど、 bot 以外で成立、とかいうのは本質的に成立にしちゃったほうが有意なケースが多いんだわ。
761:デフォルトの名無しさん
05/11/16 00:02:49
相等性?(0.6 + 0.000000000000000041) == 0.6
浮動小数は代数的ではないとはいえ、言語的にこれでいいでしょうか?
762:デフォルトの名無しさん
05/11/16 11:02:44
>>756
バックトラックが、普通に全数探索するようなコードを書くだけで実装できてしまうとことか。
763:デフォルトの名無しさん
05/11/18 20:07:17
どうでもいいこと。
>>757
> recip x = cond (x == 0) 0 (1/x)
(x == 0) ? 0 : (1/x)
ちゃんとしたコンパイラなら動くきがす。
764:デフォルトの名無しさん
05/11/19 22:59:06
え、だから?
煽りじゃなく本気で意味がわからん。
765:デフォルトの名無しさん
05/11/20 16:33:55
Hugs.Base> let n C r = product [n-r+1..n] `div` product [1..r] in 5 C 3
10
766:デフォルトの名無しさん
05/11/24 22:06:26
なんとなくtak関数を書いてみたらCより速くてびっくりした。
thunkの絡まない計算は速いんだな。
767:デフォルトの名無しさん
05/11/27 20:34:53
Cのコンパイラオプションは?
768:デフォルトの名無しさん
05/11/27 21:57:49
>>767
-O2。
言われて気づいたけど、-O2 -fomit-frame-pointerとしたらCの方が速かった。
769:デフォルトの名無しさん
05/11/27 22:44:24
haskellには実行速度を求めないで美しいライブラリを書いて欲しいんだよね。
770:デフォルトの名無しさん
05/11/27 22:51:32
Cとかと違って本質的な速度向上がありうるしね.
簡単な記述のほうがプログラム変換に持ち込みやすいし.
771:デフォルトの名無しさん
05/11/28 00:09:59
贅沢を言うが、美しいコードが速いコードにコンパイルされて欲しい。
fac n = product [1..n]が末尾再帰のfacと同等なコードにコンパイルされる日は
来るんだろうか…
772:デフォルトの名無しさん
05/11/28 01:39:57
つ Clean (速いコード)
import StdEnv, BigInt
factB :: Int -> BigInt
factB n = foldr (\x y =y *% x) one [1..n]
//factB n = foldr (%*) one [1..n] // %* がないから
773:デフォルトの名無しさん
05/11/28 06:03:30
>>771
product は foldl で書けてるわけだから,もう末尾再帰になってると思うが.
774:デフォルトの名無しさん
05/11/28 11:51:06
乗算が全部遅延されるから末尾再帰の意味があんまりない。
775:デフォルトの名無しさん
05/11/28 13:49:20
コンパイラが正格性解析して最適化するから問題無し。
776:デフォルトの名無しさん
05/11/28 20:37:04
>>772
多倍長演算に時間をとられる階乗は例が悪かったかも。
興味があったのは、リストを作って壊すオーバーヘッドをなくすような最適化。
>>773
ごめん。明示的な再帰で書かれたfacのことを言いたかった。
fac = iter 1 where iter a 1 = a; iter a n = iter (a*n) (n-1)
777:デフォルトの名無しさん
05/11/28 23:57:12
>>774
標準 Prelude では sum とか product の fold は積極評価のオペレータを
導入して実装されてるんじゃなかったっけ.
>>776
リストを作って壊しているとは限らない.というか普通はそんなことしてない.
product n = foldl (*) 1 (take n (enumFrom 1)) で定義したとき,
product n
= foldl (*) 1 (take n (enumFrom 1))
= foldl (*) 1 (take (n-1) (enumFrom 2))
= foldl (*) 2 (take (n-2) (enumFrom 3))
...
= foldl (*) n! (take 0 (enumFrom n))
= foldl (*) n! []
= n!
みたいに評価されるから,陽に空リスト以外のリストを作る部分は無い.
778:デフォルトの名無しさん
05/11/29 00:46:37
>777
少し前にメーリングリストで「sumはfoldl'を使うべき」という議論があったね。
いま見直したら、議論は「可算は常にstrictと言えるか」とかいう方向にシフトしちゃってたけど。
んで、型クラスを使っている以上、+演算子が常に strict に評価可能である保証はできないので、ということで議論は終結してしまっていた。
実際、 GHC では sum とか product では普通の遅延評価版を使っているよ。
実際問題としては strict 版の sum' と product' が(Listにでも)用意されていればいいと思うんだけど。
ちなみに仕様上も、
URLリンク(www.sampou.org)
foldl を使うことになっているので、仕様が変わるまでは積極評価版にはならないと考えた方がいい気がする。
779:デフォルトの名無しさん
05/11/29 09:25:21
>>778
そかー…….
まあ product [-10000..1] とかを一回の乗算で終わらせられる可能性があるから
戦略上絶対に悪いというわけじゃないんだろうけど癪だなあ.
780:デフォルトの名無しさん
05/11/29 11:46:33
>>777
>リストを作って壊しているとは限らない.というか普通はそんなことしてない.
その過程は、細かく言うと(foldlの代わりにfoldl'を使って)
...
= foldl' (*) 1 (take (n-1) (enumFrom 2))
= foldl' (*) 1 (take (n-1) (2:enumFrom (2+1))
= foldl' (*) 1 (2:take (n-2) (enumFrom (2+1)))
= foldl' (*) 2 (take (n-2) (enumFrom (2+1)))
...
のように進むから、1ステップごとにconsを作っては壊す必要があると理解してたんだけど、違う?
>>778
>実際、 GHC では sum とか product では普通の遅延評価版を使っているよ。
IntとIntegerについては正格な版が使われると明言されてる。
URLリンク(www.haskell.org)
といってもDoubleやWord32やRationalは遅延評価版だけど。
781:デフォルトの名無しさん
05/11/29 21:24:51
『ふつうの Haskell プログラミング』2005 年度内発売予定
URLリンク(i.loveruby.net)
782:デフォルトの名無しさん
05/11/29 23:27:32
>>781
ネ、ネタにしかみえねぇ……
マジなのか?
783:デフォルトの名無しさん
05/11/30 02:16:17
ふつうの人は、Haskellでプログラミングしない。
784:デフォルトの名無しさん
05/11/30 03:23:53
>>781
年内ではなく、年度内かよ。
ホントでたら買わせていただきます。
それよりも誰か The Craft of Functional Programming を訳してください。英語で挫折してしまいました。
785:デフォルトの名無しさん
05/11/30 17:10:48
世界よ、ありがとう
786:デフォルトの名無しさん
05/12/06 08:44:52
出版も遅延評価で行なわれます。
宣言はされても評価はされません。
787:デフォルトの名無しさん
05/12/06 10:42:49
参照透明性の関係で版ごとにタイトルが違うか、IOモナドに包まれて出版されます。
後者の場合、読者もIOモナドに包まれないと読めません。
788:デフォルトの名無しさん
05/12/06 11:12:00
つまり必要が生じたときにその箇所だけ読まれるわけじゃなくて前から順番に読まれることが保証されているといいたいのか
789:デフォルトの名無しさん
05/12/06 11:45:40
読んだ知識をIOモナドの外で活用したい場合はどうしたらいいですか?
790:デフォルトの名無しさん
05/12/06 14:43:53
unsafePerformIO
791:デフォルトの名無しさん
05/12/06 17:22:33
年度内って、来年の四月までってこと?
792:デフォルトの名無しさん
05/12/06 20:00:58
URLリンク(i.loveruby.net)
12月内ってことじゃない?
793:デフォルトの名無しさん
05/12/06 20:06:08
出版前に査読してもらうってことだろ。
794:デフォルトの名無しさん
05/12/06 20:11:14
>>793
ごめん。reviewの意味を勘違いしていた。
795:デフォルトの名無しさん
05/12/17 10:02:29
ごめん、以下のプログラムが読み解けないです
「addの戻り値型は引数型の関数となっている、と指定している」
ということらしいのですが、誰か解説してくれまへんか
class Add a b c | a b -> c where
add :: a -> b -> c
796:デフォルトの名無しさん
05/12/17 10:41:58
functional dependency ってヤツだよ。
それは関数ではなくて、「aとbからcの型は一意に定まる」ことを示している。
URLリンク(www.cse.ogi.edu)
797:デフォルトの名無しさん
05/12/18 04:23:05
"100" から 100 を取り出すような関数はどうやりますか
798:デフォルトの名無しさん
05/12/18 08:25:32
readの作り方?
799:デフォルトの名無しさん
05/12/18 08:52:39
>>797
read "100" :: Int
800:デフォルトの名無しさん
05/12/18 09:26:10
>>798
そうです。
>>799
言葉足らずですみません。
801:デフォルトの名無しさん
05/12/18 11:11:46
foldl (\x y->10 * x + (ord y - ord '0')) 0
802:デフォルトの名無しさん
05/12/18 14:55:27
浮動小数の桁数指定で最後の桁の次を四捨五入の場合は?
803:デフォルトの名無しさん
05/12/18 15:29:40
何の話?
804:デフォルトの名無しさん
05/12/19 15:50:32
roundN :: (RealFrac a, Integral b) => a -> b -> a
roundN x n =
(frac (round (x * b))) / b
where b = 10 ^^ n
frac = fromRational . toRational
805:797
05/12/20 01:34:36
>>800
誰だ君…
>>798
そうです。
>>799
言葉足らずですいみません。
806:デフォルトの名無しさん
05/12/20 08:55:38
Webで以下のような定義を見かけたのですが、
data List a = Nil | Cons a (List a)
instance Eq (List a) where
Nil == Nil = True
Cons x xs == Cons y ys = xs == ys
_ == _ = False
Cons x xs == Cons y ys = xs == ys
の部分って正しいの?
このままだと (Cons 1 (Cons 2 Nil)) == (Cons 1 (Cons 3 Nil))
が True になるんだけど・・・
かといって
Cons x xs == Cons y ys = x==y && xs == ys
とかすると、最初のほうの x==y で
「add (Eq a) to the class or instance method `=='」
とか怒られるんだけど、じゃーどう定義したらよいのか
わかりまへん
807:デフォルトの名無しさん
05/12/20 09:00:55
>>796
ありがとうございます。まだよくわかってないですが
読んでみます。
808:デフォルトの名無しさん
05/12/20 10:37:50
>>806
リストという構造自体の等価性の問題ですから
中身は関係ない(というか見ちゃいけない)のです
add (Eq a) to the class or instance method `=='
とあるように,
中身の等価性まで考えようとしたら,List に格納できるデータ型
が Eq クラスのインスタンスに制限されてしまうのです.
809:デフォルトの名無しさん
05/12/20 10:47:45
>>797じゃないですがReadのインスタンスの作り方わからない…
readsPrecとreadListの作り方のチュートリアルか何かないでしょうか(できればShowの方も)
Haskell98Report読んでもサッパリです
810:デフォルトの名無しさん
05/12/20 13:02:57
instance Eq a => Eq (List a) where
Nil == Nil = True
Cons x xs == Cons y ys = x == y && xs == ys
_ == _ = False
811:デフォルトの名無しさん
05/12/20 18:59:40
>>808
なるほど。納得です。
>>810
こうすると出来ますね。
Eq クラスのインスタンスに制限されるってこういうことだったのですね
有難うございました。
812:デフォルトの名無しさん
05/12/21 23:26:59
>>809
チュートリアルじゃないけど、GHC.Readにいくつかinstanceの例がある。
URLリンク(cvs.haskell.org)
理解したら、是非チュートリアルを書いてくれ。
813: ◆SaiTAMaVxg
06/01/09 08:32:36
ミ ( ノ
/ ̄\ ♪
〜(゚ ∀ 。 )⌒
♪ \_/ 彡
ノ ι ヽ
♪ .ハ
,ヘ ((
)ノ .))
(( ∧∧//
\(゚∀゚ )
) ノ ヾ ♪
ミ シ´ / ,γ
ミ r´ ( ∧∧//
ヽ、 ヽ 彡 ♪ ( ゚∀゚)'
) ノ 彡 .,/ ヽ ミ
ノ ,、( ノ ノヽ l
r´/ ) ) ミ (´/ ノ ノ
( ( ( ( γ´ (´
ヽ) ヽ\ ノ ハ ヽ ♪
ノ ) . / ,,/ (,,ノ 彡
♪ (__ノ (_,,ノ
814:デフォルトの名無しさん
06/01/22 22:44:58
URLリンク(shootout.alioth.debian.org)
パフォーマンスが凄いことになってる。
815:デフォルトの名無しさん
06/01/23 00:03:09
shootoutって、普通のプログラマが見ても
「Cはやっぱり速いなあ」とか「インタプリタはやっぱり遅いなあ」とか
「Javaはやっぱりメモリ喰いだなあ」とか思うだけで、
「関数型言語頑張ってるな。ちょっと使ってみるか」とは全く思ってくれない罠。
816:デフォルトの名無しさん
06/02/02 21:41:39
複数の関数の挙動に影響を与える「オプション」を外部(コマンドラインとか)から指定したいとき
C++みたいな言語の「thisの省略」がすごく羨ましいんだけど、
似たようなことをHaskellっぽく書けないものだろうか。
implicit parameterでそれなりに書けそうだけど、
使われてるのを見たことがない。
みんな明示的に引数を持ち回るのが苦痛じゃないのか?
817:デフォルトの名無しさん
06/02/02 23:15:17
>>816
そんな君にReaderT。
StateTでもいいぞ。
818:デフォルトの名無しさん
06/02/02 23:46:36
>>817
おー、ありがとう。
この目的のためにReaderモナドで計算順序を導入するのには抵抗があったけど、
既にもなでぃっくなコードにReaderTを混ぜ込むなら面倒が少ないな。
819:デフォルトの名無しさん
06/02/05 07:29:06
この言語は素晴らしいですか?
820:デフォルトの名無しさん
06/02/05 07:47:59
最高ですかー!
821:デフォルトの名無しさん
06/02/05 08:28:42
この言語の、C++に較べて、劣っている点を教えて下さい。
822:デフォルトの名無しさん
06/02/05 10:42:57
・C++ではテンプレートを使ってコードの抽象性と実行時効率を両立できるけど、
Haskellでは困難。
・C++では名前空間・クラス・関数をかなり自由に相互ネストさせられるし、
ネストに従って細かくスコープを分けてくれるのに対して、
Haskellの名前空間はフラットで、レコードのフィールド名のスコープがモジュールレベルだったり、
関数に局所的な型の定義ができなかったりして不便。
・互いに関連のないものに同じ名前を与えるC++風の多重定義は難しい。
やってできないことはないけど、想定された言語の使いかたではないだろう。
823:デフォルトの名無しさん
06/02/06 00:21:58
俺は今酔ってるし、ニートだし、最強だ。
モナディウスを参考にシューティングゲーム作るぞ。うぉー!
824:デフォルトの名無しさん
06/02/06 00:33:36
>>823
マジ応援してる。
825:デフォルトの名無しさん
06/02/06 03:51:37
出来上がったコードの実行速度はめっちゃ遅いですか?
826:デフォルトの名無しさん
06/02/06 06:11:44
>>825
>>814
827:デフォルトの名無しさん
06/02/06 07:33:29
Haskell Hackerが超がんばってキモいコード書けばgcc相当にはなるらしい。
俺のような凡人が普通に書いたらめっちゃ遅い。
828:デフォルトの名無しさん
06/02/06 09:10:24
ハスケルハッカーがキモいコードを書けば、
バグは少ないわ高速だわの最強のコードが生成されるのですね?
それとも、キモいコードってのはバグを許す代わりに高速にするとかいう類の話?
829:デフォルトの名無しさん
06/02/06 22:46:13
URLリンク(shootout.alioth.debian.org)
URLリンク(shootout.alioth.debian.org)
・コンパイルが大変で、
・コードが読みにくい分バグが多く、
・遅い
830:デフォルトの名無しさん
06/02/06 23:05:14
確かに読みにくいね。
>・コンパイルが大変で、
どういう意味?
831:デフォルトの名無しさん
06/02/07 05:53:35
ハスケル勉強したいが
参考書がきっと1万とか法外な値段でしょ?
手が出ません><
832:デフォルトの名無しさん
06/02/07 06:09:11
数学やってる人がHaskellを直ぐに分かるのは、
集合論と一階述語論理について勉強済みだからなんだよね?
833:デフォルトの名無しさん
06/02/07 10:27:09
もうすぐ青木さんの本とかが出るでしょ。
使うだけなら数学の話は特に必要ないよ。たぶん。
834:デフォルトの名無しさん
06/02/07 11:00:55
数学の知識はいらないと思うけど、論理学の基礎なしじゃむりだぽ。
835:デフォルトの名無しさん
06/02/07 16:18:33
数学に基づいて作られた言語ではあるが,その理念を理解して利用するのと,ただプログラミング言語として利用するのとでは意味が違う。
836:デフォルトの名無しさん
06/02/07 16:28:17
「アルゴリズムのプロトタイピングなら C や Java よりも簡単で,早くできます」
とは大学の教官の弁。単位きたかなあ。
837:デフォルトの名無しさん
06/02/07 16:54:31
早く作れても速く動かないのではなぁ…
838:823
06/02/07 17:13:22
>>837
みんなで速くするんだと思います><
CやFORTRANが速いのは多分歴史が長いからだと思ってる
--以下チラシの裏
今日やったこと:eclipseの日本語化とFPの導入
一言:eclipseをeclispだと思ってて「HaskellなのになんでLisp?」とか考えてた。英語弱いな、俺
今からやること:エヴァの映画借りてきて見る
839:デフォルトの名無しさん
06/02/07 21:16:35
>>837
だからプロトタイピングなんだろ。
物好きがいろいろやってはいるけど、どう考えても研究用途の言語だよな。
だから意味がないというわけではないが。
840:デフォルトの名無しさん
06/02/07 21:46:46
>>839
ちょっとお前は論点ずれてるよな。
841:デフォルトの名無しさん
06/02/07 22:30:09
>>830
liftMとか素人なら完全に御手上げ。
あと、何この演算子?ってのを使ってる
(.|. (shiftL i 3)) -- google氏も無視
逆にhaskellが神言語になってる例
URLリンク(shootout.alioth.debian.org)
URLリンク(shootout.alioth.debian.org)
d 言語90行
haskell 11行
実行速度ほぼ同じ
理由
Integer型が使える
Monadを使う必要もMonad持ち上げをする必要がない。(配列を使う必要がない)
842:デフォルトの名無しさん
06/02/08 18:30:21
>liftMとか素人なら完全に御手上げ。
たぶん、すぐ慣れると思う。
>(.|. (shiftL i 3)) -- google氏も無視
そんなあなたにHoogle
URLリンク(www.haskell.org)
843:デフォルトの名無しさん
06/02/08 21:20:50
>>842
すげー。
型から検索できるのがHaskellらしいな。
844:デフォルトの名無しさん
06/02/09 09:48:51
みなさんは、式がどういう順番で評価されていくか
手にとるようにわかるのですか?
私はどう書いたら速いコードになるのかいまいちわかりません。
845:デフォルトの名無しさん
06/02/09 13:07:28
評価順序など考えない。何のための遅延評価だと思っとる。
速いコードを書くのが目的なら関数型言語など、いや、
高級言語など使うのはお止めなさい。
846:デフォルトの名無しさん
06/02/09 13:19:59
普段は評価順序なんか考えないでコーディングして、
効率が足らないことが分かったとき、そこをアセンブリで書き直す代わりに
既にあるHaskellのコードをいじって効率を確保する、というのは、
それなりに合理的だと思うんだが。
847:844
06/02/09 13:44:18
べつに速さで C と張り合おうとか思ってるわけではないのですが、例えばhead $ xs ++ [x]が O(1) かどうかというのは、評価順がわからないとわからないですよね?こういう簡単な例なら私にもわかるのですが、ちょっと複雑になると頭を抱えてしまうわけです。
848:823
06/02/09 14:15:14
>>847
多分、どんな順序で書いてもコンパイラが同じように並べかえてくれるんじゃないかなぁ?
コンパイラが考えうる中で最も効率的なコードが出るようにね
849:デフォルトの名無しさん
06/02/09 14:16:51
>>847
非正格になれてないだけ。
850:デフォルトの名無しさん
06/02/09 19:00:42
個人的経験では、Haskellerの半分はスピードレーサー(最適化おたく)だと思う。
851:デフォルトの名無しさん
06/02/09 22:26:31
マシン非依存の部分ならば、
Cよりhaskellの方が速いコードが書けるはず。
なぜならば、見栄え良く、簡潔に書け(簡潔じゃないとコンパイルできない)
無駄なく書けるから。
cだと、綺麗なコードを書くために無駄なコードを書きまくると思うし、
汚い普通のコードを書いても、Haskellと同程度しか速くならない。
cの有利な点は、
gcがない, 配列操作, アセンブラ的コードが書ける, 速いライブラリがある。
と言ってみる。
852:デフォルトの名無しさん
06/02/09 22:37:03
非正格だから遅いみたいな話は聞いた事がある。詳細は知らないけど。
>>851
>なぜならば、見栄え良く、簡潔に書け(簡潔じゃないとコンパイルできない)
これは速いコードとは関係ないんじゃないの?
早くコードを書く事は出来るのかもしれないが。
853:デフォルトの名無しさん
06/02/09 22:37:18
「マシン非依存の部分」なんてあるのか?
854:デフォルトの名無しさん
06/02/09 22:39:54
Haskellのソースはスリムだがバイナリがピザデブ杉。
855:デフォルトの名無しさん
06/02/09 23:28:22
>>853
add
856:デフォルトの名無しさん
06/02/10 03:01:51
Haskell学んでC++でメタプログラミング
これ最新最強。newなんていりませんから!
857:デフォルトの名無しさん
06/02/10 10:53:42
なんでCはいつも最速なの?
858:fortran
06/02/10 10:55:08
・・・
859:デフォルトの名無しさん
06/02/10 12:50:24
最速はアセンブリ言語
860:デフォルトの名無しさん
06/02/10 15:32:11
規模が大きければ
今となってはコンパイラが吐くアセンブラの方が速いことが多いけどね
861:デフォルトの名無しさん
06/02/10 15:53:17
あらまあ何言ってるのかしらこの子ったら
862:デフォルトの名無しさん
06/02/10 16:26:10
コンパイラに負けるなんて、無能を証明してるようなもんだろ。
863:デフォルトの名無しさん
06/02/10 16:27:27
>>857
危険だからさ。
お行儀の良いハスケルにはわからんだろうがね。
864:デフォルトの名無しさん
06/02/10 16:40:00
>>856
バカですか
>>857
バカですか
>>859
バカですか
>>862
バカですか
Haskellに関しての議論としては論点がずれているぞ。
Haskellを創った人たちは、お前らが気にしていることはすべて解っているし、そんなことを解決するための言語にしようとは考えていないんだよ。
言語仕様に関しては。言語仕様という表現も好きじゃないけど。
865:デフォルトの名無しさん
06/02/10 16:49:34
へぇ、、ハスケルって読むんだぁ。。
アライグマみたいだね。
866:デフォルトの名無しさん
06/02/10 16:54:41
>>864
必死だな。
マジレスすると、「Haskellを創った人たち」の意図などどうでも良い。
いったん言語ができあがってしまえば、それをどう使おうが勝手だ。
867:デフォルトの名無しさん
06/02/10 16:59:56
ネタっぽいんだが
868:デフォルトの名無しさん
06/02/10 18:57:08
Haskellを作った人達って誰になるのかな。
Hudak? Peyton Jones? Wadler?
869:844
06/02/10 21:21:30
あれれ、なんだか私の質問で荒れちゃったみたいで申し訳ない。
>>849
これでも、もう一年以上使ってるんですよ。ヘボプログラマーなもんで...。
870:デフォルトの名無しさん
06/02/10 22:11:16
書いたとおりに動くCとかと違って,書いたコードよりオーダー単位で計算量が
小さくなる可能性がある Haskell には期待してるんだがなあ.
871:デフォルトの名無しさん
06/02/10 22:23:04
O'Camlはむちゃくちゃ早いらしいけど、Haskellとは何が違うんだろう。
872:デフォルトの名無しさん
06/02/10 22:42:30
>>871
URLリンク(wiki.ocaml.jp)
デフォルトで遅延評価なのか、指定したときだけ遅延評価なのか。
破壊的代入を許さないのか、許すのか。
速度に影響しそうな所というとこの辺の違いかな?
873:デフォルトの名無しさん
06/02/10 22:46:32
>>870
そんな激しい最適化をするHaskellコンパイラはないと思うが。
874:デフォルトの名無しさん
06/02/10 23:59:12
Hudakじゃないだろ。やっぱりSPJが筆頭なんじゃない?
875:デフォルトの名無しさん
06/02/11 00:19:45
なんかShootoutのページで、あれ、Haskell速いじゃんと思ったら、
極端に遅い欠点がないのと、重みが高い数個のプログラムで稼いでるだけ
みたいだな。勝ってる数だけで見たらJavaにも勝てない。
876:デフォルトの名無しさん
06/02/11 05:57:50
ふつうの本は五月に延期だそうな。
877:デフォルトの名無しさん
06/02/11 09:05:41
take 5 $ reverse $ reverse [1..]
で死にやがった。遅延評価も万能じゃないんだな。
878:デフォルトの名無しさん
06/02/11 09:28:58
Haskellでは
reverse $ reverse ≡ id
だからなあ。
879:デフォルトの名無しさん
06/02/11 09:29:52
> reverse $ reverse ≡ id
reverse $ reverse ≠ id
の間違い。
880:デフォルトの名無しさん
06/02/11 11:29:59
reverse :: [a] -> [a]
reverse xs returns the elements of xs in reverse order. xs must be finite.
881:デフォルトの名無しさん
06/02/11 11:41:15
>>875
だけって・・・
俺の感覚ではそういうのは、
「なんでもそつなくこなす優秀なやつ」だよ。
一番になること以外には意義を感じないのかい?
882:デフォルトの名無しさん
06/02/11 12:26:06
>>881
でも半分以上は平均的に結構遅いんだよ。。。
他の言語みたいに極端に遅いってのはないけど、
そういうのはアルゴリズムの欠陥があったり、その言語での普通の
やり方と違うといった何かしらの事情があることが多いし。
883:デフォルトの名無しさん
06/02/11 16:01:00
No JDK -server
ってあるのはJDKでは苦手分野の可能性が高い。
負けてる sum-file や random なんて Cleanがトップだから、
似たようにやれば(内部含む)haskellでもトップになる可能性はある。
(reverse-components はocaml 一位 Clean2位)
javaには負けてるとはいえない。
884:デフォルトの名無しさん
06/02/11 16:42:24
Haskell最速! 欠点なし!
この訴えはム板のあらゆるスレで続けていくつもりです。
885:デフォルトの名無しさん
06/02/11 16:51:19
自分が作ったものでもないのにそんな風に誇られても。
886:デフォルトの名無しさん
06/02/11 16:53:58
>>884
頑張れ
Lisp厨やRuby厨に負けるなよ
887:デフォルトの名無しさん
06/02/11 17:34:34
shootoutのあれは、言語の優劣よりもcommunityの熱意とかを反映している気がする。
888:デフォルトの名無しさん
06/02/11 18:32:12
>>884
訴えにはそれ相応の証拠がいるんだ。
説得力がある資料を添えて出直せ。
889:デフォルトの名無しさん
06/02/11 19:54:29
証拠はshootout
890:デフォルトの名無しさん
06/02/11 20:01:18
確かにshhotoutだとcより速いことになってるなwww
891:デフォルトの名無しさん
06/02/11 20:04:00
姉は一級Haskeller 〜イケナイSTG-Machine
892:デフォルトの名無しさん
06/02/11 20:09:58
>>890
CPU Timeの重みを1にして他を0にしてみ。
OCaml 34.77 1
C gcc 32.82 3
D Digital Mars 29.86 2
Haskell GHC 28.69 0
C++ g++ 25.76 2
SML MLton 24.70 3
Eiffel SmartEiffel 24.36 5
Nice 23.45 3
Java JDK 1.4 -server 22.21 4
Clean 22.01 6
Java JDK -server 21.87 4
Ada 95 GNAT 20.25 4
Java JDK -client 18.84 4
Fortran G95
まあでも正直、この順位も絶対現実とはかけ離れてるよな。
やっぱ、コミュニティの熱意とかが反映されるんだろうな。
893:デフォルトの名無しさん
06/02/11 20:20:21
>>892
>Nice 23.45 3
プログラミング言語Nice (ワラ
894:デフォルトの名無しさん
06/02/11 20:35:56
だから、Shootoutは時々極端に遅いところがあるから
そういう変な順位になる。
例えば、CとHaskellを見るとCのchameneosとregex-dnaが
極端に遅いことがわかる。
こういうのはアルゴリズムの欠陥か何かの特殊事情だから除いて
考えるべきだというのは、具体的な数値を見てみるとよくわかるだろう。
895:デフォルトの名無しさん
06/02/11 21:07:44
まあ、Cだと書きにくいからアルゴリズムの欠陥が生まれるわけだ。
896:デフォルトの名無しさん
06/02/11 21:09:32
それもあるだろうが、コミュニティの熱意が大きいだろ。
いずれにせよ本来の速さとは違うだろう。
897:デフォルトの名無しさん
06/02/11 21:12:07
FortranがJavaより下とか、そういうの見ても相当いい加減な
順位であることがわかるな。
898:デフォルトの名無しさん
06/02/11 22:00:20
CとかFortranとか手書きアセンブリとか:熱意に対して指数関数的に速くなる
OCamlとかCleanとかHaskellとか:凡人がやっつけ仕事してもそこそこ速い
ってことでFA?
スレ違いだけど、今日初めてGoogle Earthをインスコしたんだ。
超セクシーだね! あんなのをHaskellで書いてみたい
899:デフォルトの名無しさん
06/02/11 22:08:03
ワラ^^;
900:デフォルトの名無しさん
06/02/11 22:46:14
>>898
後者は言語オタク・エキスパート・信者が、Shootoutのために
必死になってソース作ってそうだけどなw
901:デフォルトの名無しさん
06/02/11 22:46:47
はっきり言って、速いとか遅いとかどうでもいい
902:デフォルトの名無しさん
06/02/11 22:47:40
しかし最適化には興味があるという矛盾 誰か俺を(ry
903:デフォルトの名無しさん
06/02/12 01:24:02
こんなの見つけた。
URLリンク(item.rakuten.co.jp)
904:デフォルトの名無しさん
06/02/12 05:16:07
まあ、DとかC++とかにHaskellが対抗してる時点で
あきらかに実力以上の評価なわけで。
素人が普通に作ったらJavaといい勝負ってのが正直な感想。
905:デフォルトの名無しさん
06/02/12 09:51:08
東大生みたいな言語だな。
ノーベル賞とまではいかないがなかなか強力に安定した結果を叩きだし、堅物で融通がきかない。
906:デフォルトの名無しさん
06/02/12 12:18:48
いや、Haskell自身が速いってことはないと思う。
確かに言語仕様が優れていて、使ってる人が非常に優秀なのは
確かなんだが、速くはない。
Shootoutがいい成績なのも使ってる人が優秀なのと、他の言語が
力入れてないだけ。
907:デフォルトの名無しさん
06/02/12 12:33:29
てか、実は>>892は数日前までDやOCamlに勝ってた。
つまり、まだまだ未成熟段階ってこと。
Shootoutの順位なんてそんなもん。
908:デフォルトの名無しさん
06/02/12 12:38:23
あほな速度評価結果はってんなよ。
血液型占いと同じぐらいオカルト。
バカですか。
909:デフォルトの名無しさん
06/02/12 12:40:15
貼ってる奴もそういうコメントしてる。
910:898
06/02/12 13:19:09
最適化なんて弱者のいいわけです><
911:デフォルトの名無しさん
06/02/12 13:44:58
最適化無き者に実用無し
912:デフォルトの名無しさん
06/02/12 13:53:42
>>911
ごめんなさい><
ハードウェアが十分速ければ……ってのこそアレだと思った。
913:デフォルトの名無しさん
06/02/12 14:03:51
>>912
こここちらこそごめんなさい
そんな角をたてるつもりじゃなかったの><
914:デフォルトの名無しさん
06/02/12 14:53:46
Haskellは最速!
915:デフォルトの名無しさん
06/02/12 14:59:37
非常に残念なことですが、2ch haskellスレには
知的障害者が多数生息している模様です。
916:デフォルトの名無しさん
06/02/12 15:14:18
天才と池沼は紙一重
917:デフォルトの名無しさん
06/02/12 15:19:27
こっちのスレでやったら?
関数型言語Part IV
スレリンク(tech板)
918:デフォルトの名無しさん
06/02/12 15:21:41
いやいや。
そろそろ次スレだし、Haskell最適化スレと本スレを分ければ良い。
縮小する方向に強制するとろくなことが無い。
919:デフォルトの名無しさん
06/02/12 15:58:42
>>918
確かに。言語全般の最適化ってなさそうだし
920:デフォルトの名無しさん
06/02/12 16:45:19
Haskell最適化スレなんて建てても寂れることは目に見えてる。
このスレでここ数日発言した奴の大半はHaskellを知ってる訳でも学んでる訳でもなく
ただ「話題の」言語を冷やかしにきただけだろ。
スレ一つ消費するほど興味が続くとは思えない。
やるなら、
【数学者】Haskellはクソ言語【オナニー】
スレリンク(tech板)
を再利用したらどうだろう。
921:デフォルトの名無しさん
06/02/12 17:09:47
まあ最近の書き込みのうち大体半分は俺のだしな
922:デフォルトの名無しさん
06/02/12 17:31:42
>>920
実に的確な分析だ。
見事ここ数日冷やかしに来ていた事を当てられたから困る。
923:デフォルトの名無しさん
06/02/12 18:29:23
Haskellは遅い派だが、Haskellを学んでるのは俺だけか・・・
924:デフォルトの名無しさん
06/02/12 18:35:47
授業の課題で、
「MLやHaskellに代表される関数型プログラミング言語について調べ、
PascalやC言語に代表される手続き型言語との相違を説明するとともに、
関数型プログラミング言語が広く普及していない理由を議論しなさい。」
というのが出たのですが、さっぱりです。
頭のイイおまいら、教えてください!!
925:デフォルトの名無しさん
06/02/12 18:48:44
>>924
まず大学と教官の名前を言え。
926:デフォルトの名無しさん
06/02/12 18:54:53
>>924
マルチス=ルナカス
927:デフォルトの名無しさん
06/02/12 18:56:35
すみませんそれはいえない。。特定されるから。
でも、あまり理論的なことよりも実用を重んじると思う。
数学的にどうこう、っていうよりも、プログラミング技法としてどうか?
っていう点かな??
928:デフォルトの名無しさん
06/02/12 18:58:32
>>924
宿題は自分でやれ
929:924
06/02/12 18:58:47
>>926
すみません。間違って2箇所書いてしまいました。
以後、こちらに一本化します。
明日締め切りなんで、かなり焦ってます。
ほんと、箇条書き程度で良いので、書いてもらえれば助かるかる。
930:デフォルトの名無しさん
06/02/12 18:59:39
だが断る
931:デフォルトの名無しさん
06/02/12 19:00:31
>>924
どれが分からないの?
サッパリつーが、1 くらいは自分で出来るでしょ。
それ以外は、自分の思う所を書いてくれれば、ヒントくらいは出せると思う。
1. 関数型プログラミング言語に付いて調べる
2. 手続きが他言語と関数型プログラミング言語の相違を説明する
3. 関数型プログラミング言語が普及していない理由を議論する
その前に C や Java は理解してるのかな。
932:924
06/02/12 19:03:11
CやJAVAは分かります。
関数型言語もLispで軽く勉強したことはあります。
なので1はできそうなのですが、2,3に関してどういう観点から
話を広げていいのか分からないんです。
933:デフォルトの名無しさん
06/02/12 19:03:40
スマソ。
手続きが他言語 --> 手続き型言語
934:デフォルトの名無しさん
06/02/12 19:07:07
>>932
2 は関数型言語が利点として上げている事(FAQ とかに書いてある宣伝文句)を
裏返せば、手続き型言語との相違が見えてくるんじゃないかな。
3 は Lisp を勉強していて、何じゃこりゃと思った事を軸にすれば良い。
935:924
06/02/12 19:08:07
この板でCやJAVAと対比してHaskellの優位性を主張してる発言が多くあるのですが、
それってまとめるとどういうことになるんですか??
(全然専門的に知らないので、内容がちょっと理解できなくて)
それが分かればその点を広げて論ずることができるかなと思いました。
936:デフォルトの名無しさん
06/02/12 19:08:55
>>932
参考文献:なぜ関数プログラミングは重要か
URLリンク(www.sampou.org)
937:デフォルトの名無しさん
06/02/12 19:12:09
>>935
アルゴリズムの記述性、プログラムの安全性とか、自分でテーマを設定して、
具体例を少し添えてあげれば良いんじゃないの。
宿題みたいだし、直接的な答えは書かない方が貴方の為になるよね?
938:924
06/02/12 19:12:09
>>934
>2 は関数型言語が利点として上げている事(FAQ とかに書いてある宣伝文句)を
>裏返せば、手続き型言語との相違が見えてくるんじゃないかな。
なるほど、確かにそうかもしれませんね。参考にします。
>3 は Lisp を勉強していて、何じゃこりゃと思った事を軸にすれば良い。
いや〜難しい。。「括弧が多い!」ぐらいしか。。w
>>936
ふむふむ、参考にしてみます。
939:924
06/02/12 19:15:26
>>937
>直接的な答えは書かない方が貴方の為になるよね?
書いてもらえるなら書いてもらったほうが助かります!笑
あまりプログラムは自分の専門ではないので、、
てか、皆さんやさしいですね。
>プログラムの安全性
手続き型と関数型は安定性が違うんですか??
940:デフォルトの名無しさん
06/02/12 19:28:43
>>939
疑問を持ったら、あとは自分で調べてチョ。さっきも書いたけど、
手取り足取りは無しの方向で。個別的な事象で不明な所があったら
また質問して下さい。
941:924
06/02/12 19:31:47
>>940
わかりました。
でも、作業の方向は見えたので助かりました。
ありがとうございます。
>>みなさん。
お騒がせしました。気分を悪くしてしまいましたらすみません。
942:デフォルトの名無しさん
06/02/12 19:32:49
>>924
URLリンク(www.geocities.jp)
URLリンク(web.yl.is.s.u-tokyo.ac.jp)
ヌルポ
943:デフォルトの名無しさん
06/02/12 19:39:12
ここは教育的なインターネットですね
944:デフォルトの名無しさん
06/02/12 20:18:05
unko
945:デフォルトの名無しさん
06/02/12 20:30:55
一瞬undoと見間違った。
946:デフォルトの名無しさん
06/02/12 21:54:03
しまった! こっち見る前に>>924の宿題の答えを書いちゃったじゃないか。
まさかマルチするとは思ってなかった……
947:デフォルトの名無しさん
06/02/12 22:03:40
>>924の正解はこれ
「関数型の言語と手続き型の言語の相違は、柔軟性、記述性、簡潔性、堅牢性
などであり、どれをとってもはるかに関数型が優れる。また、ユーザーの頭脳にも
大きな違いがあり、関数型言語が優れる。
普及していないのは選ばれた優れた頭脳の持ち主にしか良さがわからない
からである。」
948:デフォルトの名無しさん
06/02/12 22:05:55
>>947 はネタとしても駄目だろ…
949:デフォルトの名無しさん
06/02/12 22:09:58
関数型が難しいとされるのは一番最初のプログラミング言語が機械語だったからじゃね?
機械語->アセンブリ->フォートラン->C みたいに発展せざるを得なかったというか。
もし手続き型なんて一切知らない人に関数型の教育をほどこせば同じ人が Java を
学ぶより簡単そうだ……。
或いはプログラマの90%が関数型しか知らない世界では「手続き型? あんなのオナニーだよ」
みたいな話になるんだろうな。
950:デフォルトの名無しさん
06/02/12 23:14:56
HaskellとAlgol60を比べることはできても、
関数型言語と手続き型言語を比べるのは難しいだろうな。
議論の前提となる関数型言語の定義すら定まってないし。
951:デフォルトの名無しさん
06/02/12 23:30:35
漏れみたいな凡人には再帰が理解しにくいよ。
階乗みたいな簡単なのは分かるけどさ。
「なんでループ使わせてくれないんだよぅ」ってなる。
952:デフォルトの名無しさん
06/02/12 23:38:45
え
953:デフォルトの名無しさん
06/02/12 23:40:33
間違い
954:デフォルトの名無しさん
06/02/12 23:44:37
行列積みたいな一般再帰は確かに嫌だね
955:デフォルトの名無しさん
06/02/12 23:47:20
>>951
Haskellだと再帰を使わずに済ませられることも多くないか?
たとえば階乗は\n -> product [1..n]と書ける。
IOが絡んだりする複雑な処理を書くときは再帰が要ることも多いけど、
個人的には再帰(やループ)は小さいほどわかり難いと思うから、
これはあまり問題じゃないような気もする。
956:デフォルトの名無しさん
06/02/13 04:23:49
俺にはループは再帰にしか見えない。
同じルーチンを何度も呼び出してるだけじゃん。
957:デフォルトの名無しさん
06/02/13 07:16:58
スタックオバフロー
958:デフォルトの名無しさん
06/02/13 07:48:01
遅延評価は俺の生き方そのものだ
959:デフォルトの名無しさん
06/02/13 13:15:16
ハスケル日本語参考書無いの?
960:デフォルトの名無しさん
06/02/13 13:15:45
3ヶ月くらい待て
961:デフォルトの名無しさん
06/02/13 22:56:43
>>903 のが予定通り出るのなら1ヶ月程待てばOKだ。
962:デフォルトの名無しさん
06/02/14 21:16:16
5月に延びたらしいぞ。
963:デフォルトの名無しさん
06/02/14 21:36:00
>>962
それは「ふつうのHaskellプログラミング」の方じゃないか?
964:デフォルトの名無しさん
06/02/14 22:18:39
>>958
漏れなんかいつも先行評価だぜ。
値が必要とされたことは一度も無いがな....orz
965:デフォルトの名無しさん
06/02/14 22:26:28
漏れの人生はcall by nameなので同じ失敗を何回も繰り返してますorz。
966:デフォルトの名無しさん
06/02/14 22:28:40
>>964
イ`
投機的であるとはそういうことだ。
967:デフォルトの名無しさん
06/02/14 22:30:19
人生で成功するのは Unlambda のコードを読むより難しい
968:デフォルトの名無しさん
06/02/15 03:36:00
WinXP+GHC+wxHaskell でHello,WorldをコンパイルしてみたんだけどGHCに怒られました
>C:\Documents and Settings\Owner\workspace>ghc hello.hs
>
>hello.hs:2:0:
> Failed to load interface for `Graphics.UI.WX':
> Bad interface file: C:\wxhaskell\lib\imports/Graphics/UI/WX.hi
> mismatched interface file versions: expected 6041, found 6040
wxhaskell-register.batは実行したし、確かにC:\wxhaskell\lib\imports\Graphics\UI\WX.hiに
ファイルはあります。ぐぐったらブログの記事みたいなんがひっかかったけど
そこでも解決法はみつかりませんでした。CUIなHello,Worldは問題なくコンパイル出来ました。
wxWidgetsもインスコしなきゃダメかな、と思ってmsiファイルで入れてみたけど、どうも違うようです。
偉い人、どうか教えて下さい。
969:デフォルトの名無しさん
06/02/15 03:40:04
>>968
--makeか-package wxでよかったはず。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5381日前に更新/259 KB
担当:undef