パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

遺伝的アルゴリズムでカーネルチューニング」記事へのコメント

  • by Anonymous Coward
    > 理論上は時間と共に特定の環境に最適なパラメータに収束する。

    本当に?最適解への収束性が理論的に保証できるようなやさしい問題なら、そもそもGAなんてくだらない方法は使わない方がいいのに。

    保証で
    • 同じGAの話をするなら、PostgreSQLはGEQOというGAを使ったオプティマイザを古くから持っています。これはプランの最適化に使うものですが、RDBMSの問い合わせプランは殆どのケースで最適解への収束が行われるでしょうから、あなたの言い分だとGEQOはくだらない方法になるでしょう。

      にもかかわらずGEQOを使うのは、大量のJOINを伴うようなプランの取りうる組み合わせが爆発した場合に時間がかか

      • Re:収束性 (スコア:0, フレームのもと)

        by Anonymous Coward on 2005年01月08日 22時52分 (#675867)
        殆どのケースで最適解への収束が行われるでしょう
        そういうのは「保証」って言わないんですよ。
        親コメント
        • by L.star (163) on 2005年01月08日 23時01分 (#675876) ホームページ
          そういうのは「保証」って言わないんですよ。
          言ってません。勝手に「保証」なんて前提をつけないでください。
          親コメント
          • Re:収束性 (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2005年01月09日 5時23分 (#676000)
            > 言ってません。

            いや、だからそこが問題なんだって指摘されてるんですけど、わかりませんか?

            ここで問題になってるのは「理論的に最適解への収束を保証できる問題にGAを適用することの意味」です。そこへいきなりあなたが「理論的な最適解への収束保証」のない事例を持ち出してきたから、的がはずれてるのです。他の人も指摘してますが、あなたが出してきた例では、GAによって得られるのはあくまで近似解(最適解の保証なし)で、もちろん最適解への収束保証もありません。

            理論的な最適解への収束保証ができない場合にGAを使うことについて、馬鹿らしいなどと言ってる人は誰もいませんよ。そう言ってる人間がいるとあなたが思い込んでるだけで。もうちょっと落ち着いて、他の人のコメントを読むようにしたらいいと思います。

            それから、最適解と近似解の違いや、収束保証の意味も勉強された方がいいですね。基本がまるで理解できていないようですから。
            親コメント
            • by Anonymous Coward
              >ここで問題になってるのは「理論的に最適解への収束を保証で
              >きる問題にGAを適用することの意味」です。
              へー、カーネルチューニングの問題は理論的に最適解への収束を
              保証できるんだ。へー。
          • by Anonymous Coward

            DBの問い合わせプランの最適化って、大抵は、最適解じゃなくて、近似解だと思うのですけど。

            最適化には二種類あって、コンパイラとかタスクスケジューラの最適化って、基本的に最適解を求めないってのが大半で、それでも最適化っていってる気がします。そういう場合は、最適解への収束をそも

            • by L.star (163) on 2005年01月09日 11時00分 (#676034) ホームページ
              DBの問い合わせプランの最適化って、大抵は、最適解じゃなくて、
              いいえ。少なくともPostgreSQLの場合、基本は全数検索評価で、最も良い評価を得たプランを採用します。これはいわゆる最適解だと思いますが。

              もちろん評価関数の問題で、それが現実には最適解じゃない可能性もありますが:D

              親コメント
              • by Anonymous Coward
                「大抵は」という議論をしているところで、「PostgreSQL」という単一の事例だけを持ってきて議論をすること自体に意味がないということに気づいてください。
                あなたがPostgreSQLに詳しいのは分かりましたから。
              • by L.star (163) on 2005年01月10日 13時44分 (#676475) ホームページ
                私が本当に確実なことが言えるのがPostgreSQLだけだから(商用なんてソース無いし)そう言う言葉をつけたのですが、噛み付きますね。

                はっきり言っておくと、DBの問い合わせプランは順列組み合わせ問題に近く、テーブルのJOINやインデックスの選択肢が少ない殆どのケースでプラン数が数個~数十個しかなく、通常全件調査してもコスト場問題ない、と書けば満足ですか?

                あなたがPostgreSQLに詳しいのは分かりましたから。
                あなたが数学に詳しくても実世界の適用例に詳しくない上、言葉遣いは最悪で自分の言いたいことをここの方々にまともに説明できてないこともわかりましたから。
                親コメント

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

処理中...