ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    スポンサーサイト

    このエントリーを含むはてなブックマーク はてなブックマーク - スポンサーサイト あとで読む
    上記の広告は1ヶ月以上更新のないブログに表示されています。
    新しい記事を書く事で広告が消せます。

    関数型言語の遅延評価とデバッグの関係

    このエントリーを含むはてなブックマーク はてなブックマーク - 関数型言語の遅延評価とデバッグの関係 あとで読む
    「簡単にできることを複雑にやる必要はない」

    簡単な問題を自分で複雑にしない - 武蔵野日記

    人工知能業界では「ある問題を解くとき、その問題よりも難しい問題を途中で解いてはならない」という Vapnik の法則



    プログラミングにおけるテストの面倒くささは問題となります。
    テストによるバグ発見&修正は、バグが少ないと簡単になります。


    ●データの変化
    プログラム(計算)は、「データ」と「処理」という二つの構成要素から成り立っています。

    (1)インプット=データを入れる。
    (2)処理=データを加工する。
    (3)アウトプット=データを出す。
    この(1)から(3)を繰り返すことで、計算が行われます。

    エンバグ(バグの作りこみ、混入)を防ぐために、「型」や「参照透過性」といった仕組みが考案されてきました。
    プログラミングのパラダイム変遷を調べると、他にもいろいろ工夫&改良がなされてきました。

    ●遅延評価
    関数型言語の「遅延評価」は、デバッグをやりにくくしているという指摘もあります。

    最近の人気プログラミング言語は「designer」が創ったもの | スラッシュドット・ジャパン

    2012年03月09日 21時38分 (#2114704) 日記
    自分は Haskell を独学て覚えてからもう5年以上遊んでいますが、言語仕様が難しいと感じたことはありませんね。
    Haskell で難しいと感じたのはデバッグで、遅延評価なので手続き型言語のように途中でブレイクして変数をインスペクトする、というのが非常にやりにくいのです。
    C/C++/Java/C# に比べてバグの数は顕著に減りましたが、ひとつのバグに費やす時間は増えました。



    関数型に手続き型の作法を持ち込むと苦戦する場合がありますね?

    遅延評価 - OCaml.jp

    関数型言語の比較
    OCaml lazy を付けると、Lazy.forceするまで評価が遅延されます。
    Haskell 全ての評価に遅延評価が用いられます。



    遅延評価の設定を切り替えられる言語や仕組みがあれば、デバッグがやりやすくなるでしょうか?

    デバッグの理論と実践 ―なぜプログラムはうまく動かないのか
    Andreas Zeller
    オライリージャパン
    2012-12-22
    ¥ 3,456

    ●評価とは何か?
    関数型(宣言型)プログラミングで無限をコーディングする「遅延評価」のわかりやすい解説【脱アルゴリズム宣言③】 - Qiita

    「遅延評価」の説明の前に、そもそも「評価」とは何なのか?
    評価(Evaluation)とは、
    数学世界 --コンピューティング(計算)-->  物理世界
    数学世界の要素を物理世界に展開すること、マッピングすることで、この操作を特に コンピューティング(計算)と呼ぶのでした。

    遅延評価あるいはLazyEvaluationには別の呼び方があって、
    Call By Need
    必要呼びとリンク先では訳されています。
    こっちのほうが概念的に本質的で正確で簡潔です。
    Call By Need = 必要に応じて呼び出される(評価、計算される)ので、 結果的に 評価が遅延したり、Lazy怠惰なように見えるのです。。



    先行評価 - Wikipedia

    先行評価(英: Eager evaluation)は、プログラミング言語における評価戦略の一種であり、多くの言語処理系で標準的に使われている戦略である。正格評価または厳密評価(英: Strict evaluation)とも。
    先行評価では、変数の値が得られた時点で即座に数式が評価される。
    一般に、評価の済んでいない数式を表す中間的なデータ構造を構築・管理する必要がないため、単純なプログラミング言語ではこれが最も効率的である。



    関数型言語の場合、無限を扱ったり計算量が発散しない場合は、遅延評価を止めて、先行評価でテストすればOK?

    ●時間の分離
    JavaScript - 数学と別離したプログラミング、時間を抽象化し数学を取り戻すプログラミング【時空プログラミング④】 - Qiita

    純粋関数型言語はこれまで問題に無自覚だった
    純粋関数型言語では、コードの数学性が担保され、コードの中に時間変化する要素の混入を徹底排除しました。
    排除され行き場を失った変化はモナドで隔離されるという道をたどることになります。
    隔離されたものの、本質的な「時間」という概念要素の取扱には無頓着なままでした。

    時間を抽象化し、数学世界の対象とする関数リアクティブプログラミング(FRP)
    一方で、FRPでは、時間変化を数学概念化し、数学世界に統合します。
    時間変化を数学概念化するということは、次元をひとつ引き上げ、物理学のように時空を俯瞰するということです。
    物理学のように時空を俯瞰する形で時間も数学的な時間軸と捉え直すと、時間変化に伴う状態変化は単なる時間軸上の数列となり世界は静止します。

    それはちょうど、動画を収録しているDVDの動画データが動的でなく静的なデータであるのとまったく同じです。
    DVDの動画はプレイヤーで再生すると動いて見えますが、DVDに収録されているデータ自体は生産時に焼き付けられたまま最初からまるごと全部ありますよね?

    静止した世界においては、すでに変化は変化でなくなってしまっている。モナドの圏論がどうのこうのと知恵を絞って数学世界で安全に隔離する対象ですらない、ということです。

    変化する値はすべて時間軸上の「ストリーム」という静的なデータである。
    静止しているわりに「ストリーム」というワーディングは誤解を招くと思います。
    FRPで、時空を俯瞰して静的なデータとして扱うアプローチにおいて、個人的にあまり好ましい表現だと思わないのですが、ストリームというのは歴史上結構この文脈で使用されてきたバズワードです。

    実際に「動いている」のはデータではなく、時間軸上を未来方向へ移動する我々の世界、あるいは我々の脳が創発する「意識」のほうなのですが、とにかく静的なデータとしての「ストリーム」です。



    データの量が、無限ではなく有限であれば、
    DVDディスクから、データを取り出して映像を表示するDVDプレーヤーのように、
    変化しない永続的なデータの塊(DVDディスクに焼き付けられた静的なデータ)の中から、必要な部分を取り出して扱うこともできる。

    ●全体は部分から成る
    ・データが有限の範囲内であれば、まず「最初に」全データを用意しておく。
    ・予測不可能な事象をなくして、全てを予測可能にできる。
    というわけですね。

    時間的変化に着目することで、
    エンバグの原因は、「処理」の作り方ではなく、「データ」の用意の方にある、
    という見方もできるのでしょうか?

    プログラミングにおいて、時間を止める(分離する)手法について、検討してみたいと思います。

    コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)
    西尾 泰和
    技術評論社
    2013-04-24
    ¥ 2,668

    関連記事

    コメント

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/1094-d4476f7d

    FC2Ad

    上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。