
■アルゴリズムについての質問です
http://bekkoame.okwave.jp/qa7697154.html
いろいろ術語飛び交ってる割に
解決に向かってるように見えないんだけど…??
まぁ、【技術者向】 コンピュータカテで
【アルゴリズムについて】質問したのが運のつきよね。
Officeカテなら「使える」回答がついたかもしれんけど。
============================================
◆#2氏
>「重みtab」はrangeオブジェクトのまま使用すべきではありません。
>別途テーブル用のクラスを作り、そこで管理すべきです。
[重みtab]はRangeオブジェクトぢゃアリマセン。現状でVariant配列デス。
# Longにすれば多少速くなるけどね。
-----------------------
◆#4,7,9氏
>EXCELにも【そのための】ソルバーがあります。
違イマス。
ソルバーは「線形計画」には強力なツールデスガ
価値が離散的に変化する「整数計画」には【向キマセン】
追記)
・移動数が多い
・重み表のサイズが相対的に小さい
・"労力"の単価が相対的に小さい
・誤差を許容する
状況では、線形計画っぽく、つまりソルバーの領域になる可能性があります。
>実際にはEXCELではなく【Rubyで】やっています。
>この場合は100個で総当たりの実行時間が1秒程度です
他言語のタイム出しても無意味な気がシマスガ?
-----------------------
◆#5,8氏
たぶんそれが正解なんデショウケド、
質問者さんのレベルではコード出さなきゃ絵に書いた餅デハ?
-----------------------
◆#4,7,9氏
>要するに図2を100組です。
Officeカテではあまりみかけない方のように思イマスけど
BA率75%ってのはたいした数字デスから、きっと実務家タイプなんデショウネ。
おそらく【ゴ自分の土俵では】
とても経験豊富で、細かい仕様や挙動やTipをよく知ってラシテ
コードなんかもさらっと書ける有能な回答者さんでイラッシャルンデショウケド…。
【 "100個のデータ" と "8個のデータ100組" ぢゃ全然違イマスガ! 】
【 100! と 100*8! ぢゃまったく違ウデショ! 】
>プログラムをざっと見たのですが、
>重みtab(t01(a), t02(a))
>などように重みtabのなかにt01(a)のように配列がはいっているのをやめて、
>(略)A群数×B群数の大きさの配列(抜き出した重みtab)をつくってしまったらどうでしょうか
[重みtab]がまさにソレデスガ。 (ーー;)
# Variant型だけどね。
追記)
寝言をほざいてたのはわたしの方でした。
完全な読み違えで、たいへん失礼いたしました。<(_ _)>
他言語の人からみたら、
重みtab = Range("重み表")
で配列ができちゃうってピンとこないのかもしれマセンガ、VBAではそうデスカラ。
>再帰呼び出しは一般的にはかなり遅くなります。
>普通にぐるぐるループを回した方が速いです。
具体的に、どういう点をもって遅いと考えてるのかワカリマセン。
・再帰で総当りするケースを想定している
# 確かにときどきいるよね。
・大きな変数を値渡しするケースを問題にしている
# 確かにときどきあるよね。
・スタックを問題にしている
# コーディングによるけどね。あと、たぶん言語によってもかなり違う。
・普通にぐるぐるループを回す場面でなぜかわざわざ再帰するケースを想定している
# まぁ、普通にぐるぐる回して済むならその方が軽いよね。
クイックソートもディレクトリ探索も
普通の実装は再帰だと思イマスガ??
モシカシテ普通にぐるぐる回す人デスカ?
追記)
たいへん失礼な表現を謝罪します。 <(_ _)>
-----------------------
◆#5,8氏
だから、クイズぢゃないんデスガ。
正解出せばいいとか、そういうハナシではナクテ。
# まぁ、技術者でもないのに
# 【技術者向】 コンピュータカテで
# 【アルゴリズムについて】質問してる質問者さんが
# 悪いっちゃ悪いんだけどね。
-----------------------
◆#4,7,9氏
うん、(実務的には)有能な人ではあるんデショウケドネ。
この後に及んでコードオ出シニナラナイところをみても
VBAに関してはマッタク門外漢なんデショウシネ。
【技術者向】 (略)質問者さんが悪いっちゃ悪いんデスケドネ。
-----------------------
◆#3,6氏
おそらく、いちばん状況が見えてるし
いちばん実際的なアプローチな気もするけど
いかんせん数理屋さんよね。
【 ココはごりごりやる場面でしょ 】
# えっ?
============================================
◆いるか
コードざっと見ただけでも、
コーディング見直して、がっちり枝刈れば、
とりあえずそれだけで相当速くなるよね。
# つか、現状が遅すぎ。
-----------------------
技術屋さんや数理屋さんが
しばしば見逃す(あるいは見ない振りする)ポイントだけど
事務系実務における組み合わせ最適化問題って
【 「逆スケール」するのよ 】
技術屋さんや数理屋さんはしばしば
「指数関数時間かかるアルゴリズムは、スケールアップすると終わらなくなる」
ことを問題にするけど
実際のところ
「指数関数時間かかるアルゴリズムでも、スケールダウンすると意外と終わる」
のよね。
「要素が1つ増えるだけで、所要時間がN倍になる」
「枝1層分刈るだけで、所要時間がN分の1になる」
どちらも同じことだけど、どちらに注目するかというハナシ。
-----------------------
技術屋さんや数理屋さんが
しばしば見逃す(あるいは見ない振りする)ポイントだけど
事務系実務における組み合わせ最適化問題って
【 スケールの天井が決まってるものなのよ 】
技術屋さんや数理屋さんはしばしば
「要素数が百倍になったら…」とか考えるけど
実際のところ
「要素数の上限は普通動かない」のよ。
たとえば、ソートアルゴリズムを考えるような場面であれば
要素数が10のときもあれば10000のときもあるよね。
だけど、事務系実務で組合せを考える場合
これまで30個程度だったものがいきなり3千個になったりしないのよ、ふつう。
-----------------------
技術屋さんや数理屋さんが
しばしば見逃す(あるいは見ない振りする)ポイントだけど
事務系実務における許容所要時間って
【 分単位なのよ 】
大きなシステムの内部処理であれば
1件解決するのに【何ミリ秒も】かかるような処理は「論外」だろうけど
事務系実務の場合は
【たった3分で】片付くなら、普通オッケーがでるよ。
# 場合によっては「昼休み中に終わるなら、まぁ…」なんてことも
# 基本、比較対象が「人力」「手作業」だからね^^;;;;;;
この質問者さんが期待してるのも
「10ミリ秒で終わるコード」ではなくて
「せめて数分で終わるコード」よね、きっと。
============================================
と、コードも出さずに、どころか、コードも書かずに騙ってみたけど(ぉ
どうすっかなぁ…。
ぃゃ、回答する気はないんだけどね。さすがに。ほんとに。
ちょっと書いてみたくなったので。でも回答できないしな。
でもここまで書いちゃった以上、書いてみないわけには…。
実際書いてみないことには「昼休み中に終わる」かどうかわからんしね。
現状8まではなんとか動くっぽいし、
上限100でよさそうな雰囲気だから、
「昼休み中」レベルの条件なら
なんとかなりそうな気がするんだけどね。
# 要素数100だと総当りで9E157やね。
# どこまで刈れるか…。