2015/07/02  吉野発表　(文責　三木)

羽藤：
この論文をどう使おうとしているのか

吉野：
タイムスペース図を列挙していって、近い人を組み合わせるみたいなことはできるのでは。
一番わかりやすいのは、一つの車でどのくらいの範囲をカバーしていくべきかみたいなの
に応用することだと思う。

羽藤：
空間の問題というよりは人だよね。
人があるエリアにいるという前提で解いてるけどもっと動的な、具体的な位置座標として
与えられているときにどう解けるのか。

吉野：
それは、時空間ネットワークにした方が良いのか

羽藤：
矢作の場合は4，5人でサービスやろうとしているのでもっと具体的にその4人の問題として
描くべき。それでも場合が非常にたくさんあって、いろんなアクティビティの場合を考え
たときにどうなるのかが考えられる。

浦田：
塗り分けパターン数を9万に切った理由は？

吉野：
特に何もない。

浦田：
30万でも列挙はしているからプロットはできる？

吉野：
できます。圧縮しているのでいくらでも出力はできる。

浦田：
図示しやすいように切ったという感じなのか。
ある条件で切った時に、一番いい解を求めることができるという意味での最適解ですよね。

吉野
そうですね。

羽藤：
全部列挙してるというのが強いよね。
圧縮しちゃえば全部列挙してるから次からもう計算早くできる。そういう意味でオペレー
ショナル。

福田：
今回はセルの塗り分け問題のようだが、ネットワークでも適用例はあるのか。

吉野：
ネットワークでもあります。電力網ネットワークで適用している例もある。
何かしらのルールがきちんと定められるような経路探索であれば、適用できる。

羽藤：
全部計算してこそ意味があるみたいな問題に適用しないと意味がないよね。
最適化ならば近似解でいいという話になるから。

浦田：
制約条件が必要ということ？

吉野：
そうですね

羽藤：
なぜ？

吉野：
ZDDで縮約していくときにいるので。まあ制約条件なしで全部列挙することもできるんで
すけど。あんまり意味はないかなと。

羽藤：
全部列挙しなきゃいけない問題って何？
まあでも、最適化問題解くのに必要だということだよね。

吉野：
これは確かに、厳密解出すのに列挙する必要があるかというとないですね。

羽藤：
まあでもなんか使えそうな気がする。

吉野：
実務上使いやすいですね。

羽藤：
陸前高田でどのくらいのサービスを担当させるかを割るときは必要なんでしょう？
それには良い気がするけども。

近松：
ゾーンを与えて、ゾーン間の遷移確率を定めてやって、その遷移でトリップチェインを表
し、最終的にn回の移動で家に戻る経路の列挙みたいなことはできるのか。

吉野：
次数を循環を作るように与えてやることでできるのではないか。
でも遷移確率を出す時点でこれを使う意味がないのでは。

浦田：
時空間パスを作って、それの上を車でどう回すかというのを、各ノードにデマンド貼り付
けてやれるのでは。

羽藤：
なるほどね。需要の側がタイムスペース図にあるから、それを全部通るような経路として
、どれが一番頑健かみたいなのを調べるのはいいのでは。
それだと回るところがたくさんあるから列挙は大変だしZDDの使い手があるのでは。

吉野：
デマンドとしては観測値を与えて、デマンドのルートが列挙対象ですね。

羽藤：
そうそう。全部あげたときに売上とか拾える人数とかで解のバリエーションも出る。

羽藤：
ハミルトン閉路はZDDで列挙できる？

吉野：
できますね

羽藤：
圧縮したネットワークが何を示しているかとかって言えるの？
階層化しているわけだからネットワークの構造を解釈できるような気がする。

吉野：
そうですね

羽藤：
実ネットワーク上にあるアクティビティを回る経路列挙とかもできるよね。

浦田：
デマンドの話だけど拾うところは良いけど降ろすところが難しそう。
その人の行きたい場所をどう入れるか

吉野：
列挙したうえでそれの評価関数を入れるみたいな感じでしょうか。