関数型プログラミング言語Haskell Part34 (694ﾚｽ)
上下前次1-新
368(1): 2024/09/29(日)08:45 ID:3/NLN/+f(1) AAS
コーダーが数学の学習に使える時間なんて限られている
時間や基礎知識が足らないので、難解な数学を攻略するのはほぼ不可能
大学生時CSや数学の講義で身に付けておくしかない
369: 2024/09/29(日)09:32 ID:twIz68VA(1) AAS
難解な数学を攻略できるなら
日本ではコーダーにはならないよな
370: 2024/09/29(日)10:15 ID:AteoOTMZ(1) AAS
業界入るのに難解数学不要
プログラミングにも不要
数学分からんのでgoogle入るのは無理だけど
371: 2024/09/29(日)11:01 ID:bBvJfaeS(2/2) AAS
人工的なルールに依存するのがクソパズルだが
自然界でなおかつ野生のマウンティング的なルールにも依存しないことが数学の目的のひとつだね
372(2): 2024/09/29(日)20:36 ID:JU2vTa1F(1) AAS
圏論が全てのプログラミング言語の裏で動いてるとか適当なこと書くなよ
373(2): 2024/09/30(月)00:30 ID:Kh4w53R0(1/2) AAS
>>368
高卒の自分でも理解できるんだから、難しいわけではないんだけど。
何度も出てる通り、必ずしもモナドを理解する必要はないし。
そもそも自分がプログラマーの頃だって、12－13時間働いた後も新しいプログラミング言語や数学勉強してたぞ。
（新しい仕事のために学びたくない言語に時間使う事も）
高卒が圏論みたいな大学数学学ぶには専門用語がそもそも分らんから、用語が分かるまで遡った。
（アーベル圏のアーベルが分からないレベルからのスタート）
省1
374: 2024/09/30(月)00:59 ID:Kh4w53R0(2/2) AAS
>>372
適当じゃない。
モナドは(主に)逐次処理に現れる構造なので、Haskellのような遅延評価で逐次処理自体を作らないといけない（逐次処理をエミュレートするためのモナド）言語でない限り、意識することすらない。
（だからC言語で言う i = 0; の「；」とか言われる）
375: 2024/09/30(月)03:08 ID:g+sPZSfB(1) AAS
>>372
沈黙させる努力をするよりも（全ての）人の話を聞くのをサボる方が良い
努力は時間がかかる
一瞬で報われるものは努力ではない
376(1): 2024/09/30(月)12:40 ID:+8KmLjt4(1) AAS
圏論の極々一部のモナドを主語をデカくして圏論ガーとか言ってる人は何も分かってないんだなと思うけどね
俺みたいに数学かじってた人からすると
圏論を勉強すると「あ、この概念はこの分野のこれのことか」ってわかるけど
そうじゃない人は何のことを言ってるのかわからんと思う
専門家でも自分の担当外の圏なんて知らないのに
圏論という括りで語ろうとする人はそういうのすら理解してない
377: 2024/09/30(月)13:52 ID:CD9F70e/(1) AAS
やっと普通の人が出てきて安心した
378: 2024/09/30(月)13:59 ID:pkON+G7q(1) AAS
>>376
数学者向けの圏論の教科書の応用、具体例は全て数学。
数学知らない人が読んでも分かるわけがない。
応用、具体例、演習をCSの分野から採った教科書が望まれるが、書くのが難しい上に面白くするのも困難。
大体CSすらちゃんと修めてないエンジニアはやはり読めない。
CS自体ベースに位相、代数、グラフ理論と数学使うし。
379: 2024/09/30(月)14:09 ID:rwCIuc1C(1) AAS
趣味でやる人に良くいるんだよね。
応用各分野に囚われずに、圏論そのものを学習したい、一般圏論を研究したいって人。
これは数学で言うと、集合論と同じく数学基礎論の分野。
380: 2024/09/30(月)19:05 ID:8C0MP56i(1/3) AAS
操作的意味論とか表示的意味論でプログラムを数学の話にして、その数学を圏論で整理するって話
だからアーベル圏とか具体的な圏はあんま出てこない。
やるとすれば
デカルト閉圏：ランベックがλ計算のモデルになると発見して関数型プログラミング的に重要
クライスリ圏：Moggiが計算効果をカプセル化したときの根拠の圏
ローベア理論：代数的効果をちゃんと理解するときは必要らしい。操作的意味論と表示的意味論と同じようにモナドの理論と妥当性が成り立つようだ。
ぐらいじゃね。
381: 2024/09/30(月)21:09 ID:CVtPTYpb(1/2) AAS
じゃあラムダ計算（のモデル）だけを考えよう
タプルや代数的データ型は使わない
それでもモナドの具体例を作れるのを知ってるのが専門バカ
知らないのが一般国民だ
382: 2024/09/30(月)21:29 ID:8C0MP56i(2/3) AAS
一般国民。
λ計算のモデルでモナド作ってなにかいいことあるの？計算効果結局表現できないんじゃ？
拡張してcomputational lambda calculusやるって話？
383: 2024/09/30(月)21:47 ID:CVtPTYpb(2/2) AAS
ないんじゃないか
ただ「具体例を出せば、いいことがある」とは誰も言ってない
というファクトをチェックするのは悪いことではない
384: 2024/09/30(月)21:53 ID:8C0MP56i(3/3) AAS
いいこと（メリット）があるから具体例が作られると思うんだが。
それは単に具体例の適用が間違ってるって話じゃね？
なんとなく作れるから群構造作ってみましたとかとか目的不在で作ったらそら何がいいかわからんし。
モナドだったら、各計算効果を圏（クライスリ圏）の中に閉じ込めることに成功しました（カプセル化）。
計算効果は強モナドの構造を取っているようです（計算効果の研究のとっかかり）。
みたいないいことあるから流行るんでしょ。
385: 2024/10/01(火)04:04 ID:PZ96E01/(1/2) AAS
別にそれ圏論を持ち出す必要ないよね
ハイおしまい
386: 2024/10/01(火)09:39 ID:KbL1rq/V(1/2) AAS
>なんとなく作れるから群構造作ってみました
ルービックキューブのことか
387: 2024/10/01(火)09:46 ID:y60InQ2q(1) AAS
数学屋さんもね
研究では圏を使うが
学生に教えるときは
圏を記述に使わず教えたりする
388: 2024/10/01(火)19:23 ID:7kn4RxVI(1/2) AAS
圏論の話題になったから振ったのに。まあいいよ。
圏論根拠で（ソフトウェア工学的にじゃなくて）数学的にカプセル化が実現されてるってすごい
ことだと思うけどね。
>ルービックキューブのことか
ルービックキューブ解くという目的あるんなら構築する意味あるんじゃない。
389: 2024/10/01(火)19:34 ID:YZm15ve9(1) AAS
群持ち出したところで解けないよ
390(1): 2024/10/01(火)20:18 ID:PZ96E01/(2/2) AAS
圏論がプログラミングの問題解決に寄与するわけないのにね
ただ当てはめてみたってだけのことを過大評価しすぎ
391(1): 2024/10/01(火)20:52 ID:u1x9FxNe(1) AAS
雪田修一の「圏論入門 Haskellで計算する 具体例から」ってどうなん？
392: 2024/10/01(火)21:10 ID:YpLGkLDy(1) AAS
板チ
目的と手段を混同したら予選敗退
393: 2024/10/01(火)21:16 ID:7kn4RxVI(2/2) AAS
どうなんって何を知るのに？出たときに立ち読みしただけだけど。
394: 2024/10/01(火)21:16 ID:Ig6Tf0ue(1/2) AAS
>>391
青本と似てて定義の後に具体例を出すみたいな感じだけど
具体例が数学科の人じゃないとわからない内容ばかりなので
結局個別の分野をやらないと理解できないと思う
395: 2024/10/01(火)21:38 ID:Ig6Tf0ue(2/2) AAS
圏論をやりたいならまず代数学をやるべき
それだけでだいぶ見通しが違う
396(1): 2024/10/01(火)21:42 ID:4kH314XL(1/3) AAS
>>390
モナドの効用で自分の把握してるのは
・数学やHaskellの様な遅延評価の場合、逐次処理を表現できる
（これは変数を使いまわさない場合は、関数合成で十分だが、変数を使いまわすときはモナドじゃないと使いまわせない）
・副作用のある関数を使っても参照透明性は保たれている
・モナドは入れ物前提の概念なので、空の状態を使って例外処理をまとめることができる
正直、普通のプログラミング言語にも役立ちそうな3つ目は実感はしてないけど、ネットで例外処理よりモナドの方が優秀っぽい記事を読んだ
省2
397(1): 2024/10/01(火)22:05 ID:4kH314XL(2/3) AAS
圏論全体だと…当たり前のことを構造として研究してるだけなので、圏論というよりはHaskellの型クラスとの合わせ技で関手（Functor）の方がfmap的なのを他の言語にも導入すれば役に立つかも
圏論の関手を一言で言えば（関数も含めた）型変換
（Hakellだと入れ物前提にすることで、関数ごと型変換を実現。本来はもっと柔軟）
自然変換は一言で言えば単位変換とか、大文字小文字の変換
398(1): 2024/10/01(火)22:16 ID:4kH314XL(3/3) AAS
モノイドは条件が結合法則だけなので、ほぼ結合法則そのものがモノイド
（その割には繰り返しとか数え上げに現れる構造）
そしてモナドも構造はそっくりなので、入れ物前提のモノイドとも考えられる
（モナドの再帰はループ処理でスタックを消費しないし、数え上げは逐次処理と考えられる）
399(2): 2024/10/01(火)23:08 ID:KbL1rq/V(2/2) AAS
バグを無くすこと自体が目的になりがちなのが数学とプログラムなんだよね
真の目的のため、デバッグを二の次にするやつが正しいと言われても・・・
それって証明とかあるんですか
400(1): 2024/10/01(火)23:21 ID:syLuNokt(1/2) AAS
>>397
大文字小文字の変換が自然変換の部分kwsk
>>399
目的と手段を区別したら、手段は二の次だと言うのは予選敗退者のポエム
401: 2024/10/01(火)23:25 ID:syLuNokt(2/2) AAS
>>396
> 2番目もマルチスレッドとか最適化には役に立ちそうではある
それもう一人のsimonが取り組んだけどモナドは否定された
402(1): 2024/10/02(水)05:35 ID:OAhBXB+m(1) AAS
やっぱり数学的に表現してみただけってことか
まぁ実際のプログラミングに利益はないわな
403(1): 2024/10/02(水)07:50 ID:AFS53MaU(1/6) AAS
>>400
よくよく考えたら特別な事じゃないんだけど、普通のプログラミング言語でも大文字・小文字の変換関数を自作するってなったら、文字をInt型に変換して処理する。
それって文字の圏で直接大文字小文字の変換するを作れない場合、一旦整数の圏を経由する関数を作る。
A(a) → B(a)
↓ ↓
A(A) → B(A)
可換図のA(a) → B(a)の逆射が作れれば、B(a) → B(A)が作れる。
省1
404: 2024/10/02(水)07:53 ID:AFS53MaU(2/6) AAS
この場合、整数同士の足し算に対応する、文字同士の足し算が作れる。
（ただし、整数と文字列で集合の大きさを合わせる必要がある。0－25とか1－26とかで循環する集合）
405: 2024/10/02(水)07:55 ID:AFS53MaU(3/6) AAS
んで、プログラマーはいちいち集合を合わせないで、エラー処理だったり循環リスト作ったりで対応するわけだぬ。
406: 2024/10/02(水)08:30 ID:VSz9kg2E(1) AAS
数学の圏論テキストではカリー化の操作は良く使うが、カリー化の名前を付けて引用することはまず無いね。
407(1): 2024/10/02(水)08:47 ID:wonXK6QE(1) AAS
>>403
大文字小文字の変換が自然変換になる事を(Haskellの例で)証明して、と言う話
(自然変換が何かは分かっているで、直感的に違うと思ったから訊いた)
408: 2024/10/02(水)09:21 ID:ZmuRtoMU(1/3) AAS
大文字の文字列の型から小文字の文字列の型への変換と考えると簡単
409: 2024/10/02(水)09:24 ID:ZmuRtoMU(2/3) AAS
リスト関手から集合関手への自然変換も分かりやすい。
410: 2024/10/02(水)10:25 ID:xCLOcr8o(1) AAS
すまん嘘を書いた
自然変換では無くリストの圏から集合の圏への関手だった
411: 2024/10/02(水)10:27 ID:ZmuRtoMU(3/3) AAS
大文字列、小文字列も同様に間違い
412: 2024/10/02(水)16:24 ID:H02uk4bf(1) AAS
>>402
ただの記号で表現したら「0の逆数」とかいう表現を禁止するのが難しい
ただの記号ではない方がベター
413(1): 2024/10/02(水)20:27 ID:AFS53MaU(4/6) AAS
>>407
圏論の自然変換だと文字コード前提じゃないので、[0..25] = ['a'..'z'] = ['A'..'Z']ってする。
んで、大文字と小文字は同じ文字の圏、[0..25]は自然数の圏とする。
lCharToInt c = (length.takeWhile (c /=)) ['a'..'z'] -- 小文字からIntへの変換（関手）
uCharToInt c = (length.takeWhile (c /=)) ['A'..'Z'] -- 大文字からIntへの変換（関手）
toLChar = (['a'..'z']!!) -- Intから小文字への変換（関手）
toUChar = (['A'..'Z']!!) -- Intから大文字への変換（関手）
省4
414(1): 2024/10/02(水)20:45 ID:AFS53MaU(5/6) AAS
可換図にすると
Char（小文字）
⇗
Int ⇑toL ⇓toU
⇘
Char（大文字）
ここで、小文字→Int, 大文字→Intが作れればtoLower, toUpperを直接作らなくても、関手の合成で作れる。
415: 2024/10/02(水)20:53 ID:4E8lSXKR(1) AAS
出番ですよ >>399
416: 2024/10/02(水)21:03 ID:AFS53MaU(6/6) AAS
圏論の地平線でも書かれていたけど、圏論は直接的に役に立つというより、発想の転換の源泉になるそうな。
（なので、別に圏論分かったから偉いとかない）
417: 2024/10/02(水)21:18 ID:JUMm5MLB(1/2) AAS
数学の研究には有用かも知れないが
プログラミングで
直接役に立つようなことはまず無い
418: 2024/10/02(水)21:42 ID:Xrjxo4NT(1) AAS
どっ白け
419: 2024/10/02(水)21:51 ID:OPLMo7z3(1/8) AAS
プログラミング言語もどんどん数学に寄せているし、上のカキコみたいにプログラムの記述を
そのまま数学的対象とみなせるように改造していってると思う。本来は別物と考えるべきだと思う。
数学の研究といってもプログラム意味論の研究で、プログラムを数学の世界に写像したら
どう表現できるかということを研究していると言えるんじゃないかと思う。
数学の世界には、式の評価途中に発生する副作用といった概念がないので、現実のプログラムを
そのまま数学の世界に移そうと思ってもできないことの方が多い。
計算効果を圏論的に表現できたというのは、そういうプログラミング言語の数学化の一端みたいな
省1
420: 2024/10/02(水)22:00 ID:YWEZQEUD(1/7) AAS
副作用ってどうでもよくね
Haskellとかだとそもそも副作用ないし
421: 2024/10/02(水)22:12 ID:OPLMo7z3(2/8) AAS
現実のプログラムだと式を評価する途中で発生する副作用というのは普通だけれど、
これを表示的意味論、操作的意味論で数学の世界に写そうと思うと途端に難しくなる。
数学で式の途中に文字列をディスプレイに映し出す、みたいな概念はないから。
それを整理して副作用と呼んでも差し支えない概念を提唱してHaskellに実装しているんだよ。
実際、ＩＯモナドの圏論的定式みるとこれが副作用？という表式してる。
全部後回しにしてフラッシュするというアイディアみたい。副作用をプログラムの最終局面で
実行しているから、式の評価途中の参照透明性も壊さない。なるほど、って感じ。
422(2): 2024/10/02(水)22:20 ID:sFAdPyYV(1) AAS
ID:OPLMo7z3 = ID:AFS53MaU 本人か同レベル
複おじってレベル
423(1): 2024/10/02(水)22:24 ID:YWEZQEUD(2/7) AAS
途端に難しくなるか？
副作用のない計算に変換する手順が教科書に書いてあるはずだが？
424(3): 2024/10/02(水)22:29 ID:OPLMo7z3(3/8) AAS
>>422
別の人。自分ならプログラムの記述を一回数学の世界に写すし。
>>423
副作用のある数学的関数ってある？
プログラム→数学
に変換するんだぜ。
副作用のない計算に変換する手順が数学の本に書いてあんの？
425: 2024/10/02(水)22:43 ID:+kVmY7U4(1/3) AAS
>>424
別人とのことなので便乗
ID:OPLMo7z3 は ID:AFS53MaU が
> 大文字小文字の変換が自然変換になる事を(Haskellの例で)証明して
と問われて
>>413,414 を出してきたのは数学的証明だと思ってるの？
426: 2024/10/02(水)22:46 ID:+kVmY7U4(2/3) AAS
>>424
或いはもっと直接的に、>>424は「大文字小文字の変換が自然変換」の真偽をどう考えているの？
427(1): 2024/10/02(水)22:51 ID:OPLMo7z3(4/8) AAS
定義が何もないのに何も言えるわけないじゃん。
数学でこういうものを定義します、これをプログラムのこれこれと対応付けます。
てプロセスないじゃん。
428(1): 2024/10/02(水)22:52 ID:YWEZQEUD(3/7) AAS
>>424
先に副作用のないプログラムに変換するって言ってるんですけど
Haskellなら最初から副作用がないからそのままでいいけど
プログラミング言語の理論の本ならどれにでも書いてないか？
429: 2024/10/02(水)22:55 ID:+kVmY7U4(3/3) AAS
>>427
了解
>>422の指摘通りだと納得しました
430: 2024/10/02(水)22:56 ID:OPLMo7z3(5/8) AAS
いや。プログラム意味論の本結構探し回ったけど副作用の記述は漠然としてて
扱えないわけじゃないらしいけど、具体的な変換なんて見たことない。
ちょうど伝統的なプログラム意味論で副作用どう扱われているか調べているんだ。
なんて本に書いてありましたか？
431: 2024/10/02(水)23:02 ID:YWEZQEUD(4/7) AAS
どれにでも書いてあるだろ、whileプログラムをラムダ計算に変換する手順とか書いてないなんてことがあるわけがない
432: 2024/10/02(水)23:06 ID:OPLMo7z3(6/8) AAS
なんだ。いや聞きたいのは入出力とかの副作用だよ。
433: 2024/10/02(水)23:17 ID:YWEZQEUD(5/7) AAS
入出力なんて代入に比べたら自明だろ…
そんなのいちいち教科書に書くかよ
434: 2024/10/02(水)23:26 ID:OPLMo7z3(7/8) AAS
書いてないのは自明だからではなくて、研究の方向性がどう転ぶかわからないからだと思う。
表示的意味論も出た当時の文献では副作用について語ってることが多い。
現代的な本になるほどD∞モデルつくってはいおしまいで数学的にきれいなところしかやらない。
435(1): 2024/10/02(水)23:36 ID:JUMm5MLB(2/2) AAS
プログラムの仕様とその証明を数学で記述する本にあるだろうね。
436(1): 2024/10/02(水)23:37 ID:YWEZQEUD(6/7) AAS
どこが非自明なのかさっぱりわからん
代入と違って入出力は垂れ流しだし、入出力は代入の特別な場合だろ
437: 2024/10/02(水)23:46 ID:OPLMo7z3(8/8) AAS
>>435
ホーア論理とか公理的意味論か。いやそれはないな。あっても一般に適用できないし。
>>436
関数型プログラミングだとプログラムをλ式に対応させて、プログラムの実行をそのλ式の簡約に
対応させるというのが理想的なモデルとして想定されることが多いと思う。
でもλ式はλ項からλ項への対応でしかないから、λ項を値(value)と呼ぶとすると
value から valueへの数学的関数でしかない。これには入出力とかの副作用を表現する余地がない。
省4
438: 2024/10/02(水)23:54 ID:YWEZQEUD(7/7) AAS
代入が書けるんだから、入出力なんて自明だろ…
こいつ何いってんだ…
439: 2024/10/03(木)00:02 ID:B2Xmf+Xl(1/9) AAS
だから、入出力がある数学的関数なんてないだろって言ってんの。
数学的関数で入出力は非自明だと思うんだが。
440: 2024/10/03(木)00:09 ID:B2Xmf+Xl(2/9) AAS
Haskellでいうと、
純粋関数は、λ式（valueからvalueへの数学的関数）
に対応付けられるけど、
IOモナド使ったプログラムは、その現実のプログラムが持つ特徴を表現できるλ式がないので対応付けられない
って言ってんの。
441: 2024/10/03(木)00:21 ID:omgk7HiD(1) AAS
入出力なんてただの値のリストだろ…
442: 2024/10/03(木)03:50 ID:KCHr29fD(1) AAS
圏論持ち出して愚にもつかないことをグダグダと…
それで何か効率良くなるならいいんだけど，何のメリットもないんだよね
443: 2024/10/03(木)04:21 ID:zyXzLypu(1/6) AAS
圏論なんかより、遅延評価ならIOがwhnfの先頭に出てきたら実行すればいいって人類が気づいたのが本質なんじゃねーの
444: 2024/10/03(木)08:29 ID:LNI2TnSo(1) AAS
最近の人類はseqのメリットを直接的に利用するコツに気づいとるんか
順調に進化しとるな
445: 2024/10/03(木)14:31 ID:1wv2Oz28(1) AAS
コンパクトな言語仕様だが表現力は強力
数学をプログラミングに取り入れるメリットってまぁこんなもんでしかないでしょ
一方で静的に性質を決定しようとするやり方は一般的な人間の能力を簡単に超えてしまう
446: 2024/10/03(木)16:46 ID:TkNlnb1D(1) AAS
急にポエマーだらけw
447: 2024/10/03(木)19:56 ID:B2Xmf+Xl(3/9) AAS
入出力があるプログラムをどう数学的に整合する概念に対応させるかについて書いてみる。
こういう説明が通るものなのか興味があるし。
まず、仮想的なシェルスクリプト風の行番号付き手続き型言語を想定して、
その言語で入出力があるプログラムを定義するとする。
000 procedure prog1(int n) {
001 double res
002 （なにか込み入った計算）
省12
448: 2024/10/03(木)19:57 ID:B2Xmf+Xl(4/9) AAS
現実のよくあるプログラムとはこういう感じのものだけれども、実行 $(prog1) をしてその結果が返ってくるという現実的に
必要な点だけを考えると、途中の行番号020を評価したとかそういう情報はいらなくて、結局 $(prog1) して
hogehoge
fugafuga
を表示して、複雑な計算の結果 res が返ってくれさえすればいいともいえる。
だったら、数学的に取り扱いがしづらい、式の評価途中で入出力が発生するみたいな部分を取っ払って
000 procedure prog2(int n) {
省15
上下前次1-新書関写板覧索設栞歴
あと 246 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s