アカウント名:
パスワード:
私は最適化問題は重要だと思うので、「汎用じゃなくても最適化問題は高速に解けます」という方針は「有り」だと思うな。
使ってみたい人はそれなりにいると思うけど、お高いんでしょうなー。簡単にググったくらいだと価格が出てこないっすね。
問題を解くのはハードでなくソフトです。最適化問題を解くのに有利なハードができたとしても、それを活用するソフトも開発しなきゃならない。Windowsアプリを移植すればオッケーって訳にはいかないでしょう。既存のハードでは時間が掛かる問題を、高速で解きたいんだから。
アルゴリズムは「量子アニーリング」に固定で、入力が初期値のデータセットと幾つかのパラメータという感じなんじゃないのかな。
最適化問題って解き方自体はそんなにバリエーションないでしょう。
その「入力が初期値のデータセットと幾つかのパラメータ」に既存データを変換しなきゃいけない。しかし「量子アニーリング」なんてのはこれまで使ってなかったので変換アルゴリズムが確立されていない。当然逆変換アルゴリズムも必要でそれも確立しなきゃいけない。つまりアルゴリズムレイヤからデバッグしなきゃいけない。デバッグするにはテストしなきゃいけない。対象、つまり量子アニーリングに精通していなければ有効なテストができない。汎用化するまではそんな感じ、というかそれを経て汎用化するんですよ。
まさかテスト無しで盲信するつもりじゃないでしょ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
最適化問題の重要性 (スコア:0)
私は最適化問題は重要だと思うので、
「汎用じゃなくても最適化問題は高速に解けます」
という方針は「有り」だと思うな。
使ってみたい人はそれなりにいると思うけど、
お高いんでしょうなー。
簡単にググったくらいだと価格が出てこないっすね。
Re: (スコア:0)
問題を解くのはハードでなくソフトです。
最適化問題を解くのに有利なハードができたとしても、それを活用するソフトも開発しなきゃならない。
Windowsアプリを移植すればオッケーって訳にはいかないでしょう。
既存のハードでは時間が掛かる問題を、高速で解きたいんだから。
Re: (スコア:0)
アルゴリズムは「量子アニーリング」に固定で、
入力が初期値のデータセットと幾つかのパラメータ
という感じなんじゃないのかな。
最適化問題って解き方自体はそんなにバリエーション
ないでしょう。
Re: (スコア:0)
その「入力が初期値のデータセットと幾つかのパラメータ」に既存データを変換しなきゃいけない。
しかし「量子アニーリング」なんてのはこれまで使ってなかったので変換アルゴリズムが確立されていない。
当然逆変換アルゴリズムも必要でそれも確立しなきゃいけない。
つまりアルゴリズムレイヤからデバッグしなきゃいけない。デバッグするにはテストしなきゃいけない。
対象、つまり量子アニーリングに精通していなければ有効なテストができない。
汎用化するまではそんな感じ、というかそれを経て汎用化するんですよ。
まさかテスト無しで盲信するつもりじゃないでしょ?
Re:最適化問題の重要性 (スコア:1)
大ざっぱには「n変数の関数f(a1, a2,...,an)を与えたとき、fの値がなるべく小さくなるような(a1, a2,...,an)の値を求めてくれるブラックボックス」が有るだけなので。
ブラックボックスにも種類があって、特定の構造のfの場合しか解けないとか、aiが実数でしか使えない、整数でも使えるとか色々ありますし、 解きたい問題を関数fに落とし込むのにも多少のテクニックは要りますし、やり方次第で性能も変わるので、精通しておいた方がより良いのは確かですが。
まあ、既存のよく知られているアルゴリズムで同じ問題を解かせてみて、性能が良さそうだったらそっちを採用、ぐらいの感じでも良いんじゃないかと。 内部構造が分からない以上、とんでもない解が出てくる可能性もあって信用できない、例えば最短経路を求めるfのはずが最長経路が出てくる可能性もある、と言う懸念はありますけど。その場合でも、既存のアルゴリズムも別途走らせておいて良い方を採用する、ぐらいにしておけば、ほとんどの場合は性能が大幅に上がって、最悪、未知の原因で想定外のことが起こっても今よりは悪くならない、というのは保証できますし。