台湾オペレーションズ・リサーチ学会に参加をしてきた

11月23-24日に開催された台湾オペレーションズ・リサーチ学会（＆国際学会）に参加をしてきた。

今回は、台南にある国立成功大学 (National Cheng-Kung University) での開催で、23日はレジストレーションとバンケット。

レジストレーションでは、国立成功大学に在籍中という日本人学生さんがサポートしてくれたので、言葉には全然問題なし。（国際学会を兼ねるのは今回が初めてで日本からの参加も多かったので、日本人学生さんもサポートをしてくれているらしい。）ちなみに、建物の中で道が分からないときに、他のサポート学生さんに英語で聞いてもちゃんとすぐに答えてくれるので、たぶんどの学生も英語は相当にできるのではないかと思う。レジストレーションではカバンをもらった。台湾OR学会の研究発表会は年に１回の開催だけど、カバンは毎年配っているらしい。

バンケットの会場は Shangli-la ホテルという台南駅すぐ隣で台南市内でもかなり高層階（３８階）の建物で、今回はフルコースだった。東坡肉は日本の５倍ぐらいあるし（聞いた話では台湾でも東坡肉の大きさは店によって大きく変わるので、ここのレストランのコックが大盤振る舞いしたのかもしれない）、魚は種類までは良く分からなかったけど、あっさりとした味付けがおいしかった。かなり美味しかったので、最後に出てきた白いドラゴンフルーツなどはお持ち帰りしたかった。あと、お茶が柚子茶と書いてはあったけど、韓国の柚子茶とはまた違った印象で、これも美味しい。

学会自体は24日が本番で、9:30に開始で最初は会長の挨拶。そのあと、受賞会。受賞会は中国語だったので正確なところは分からないけど、最初のあたりが大きい賞で、そのあとに若手研究者の賞、学生の賞、と順番になっているようだった。

10:00ぐらいから keynote が２件あって、約1時間ずつ。keynote の２件目は NVIDIA の OpenUSDや Omniverse の話があって、講演者は国立成功大学の出身で今はNVIDIAで勤務。Ominiverse のフレームワークで作った Digital Twin の動画などがあって面白かった。このあたりの動画の作り方などからすると、学生とかに興味を持って分野にどんどん参入してもらいたい、というのがこのkeynoteの話の構成だったのかもしれない。個人的には「Digital Twin がコンピュータ上の単なるシミュレーションではない」ということが分かって良かった。

12:00ぐらいからお昼ご飯で、参加者にお弁当が出ていた。お弁当はルーローハンや魚介類つみれのスープ、台南名物の海老巻き揚げ。あとはおかず類。これだけのボリュームだとちょっと足りないかな、というところに最後で豆花が追加されていた。しかも、ちゃんと台南名物の安平豆花。バンケットといいお弁当といい、食事が楽しくてしょうがない。この食事をチョイスした人にあと３食ぐらいチョイスしてほしい。

午後はパラレルセッションの時間枠が２つ。つまり、1時間半の枠が２個あって、その間に Tea Break。

パラレルセッションは１０個あるけど（つまり、合計で２０セッション）、今回は国際学会を兼ねているので１０個のうちの２個のセッションが英語でのセッション。

一つ目のセッション(13:30-15:00)では、配送計画問題で複数のトラックの配送分担を決めるときに最適化ギロチンカットを用いる手法や、暗号資産の VaR などをけいさんするのに SVCJ (Stochastic Volatility  with Correlated Jumps) が使われていたり、 stochastic PERT に対して追加資材無しで最適化する手法もあった。他にも SDGs についての話があったり、飛行機の表面の加工に関して Taguchi method や ANOVA を使っている話もあった。

Tea Break (15:00-15:30) では、マレーシアからきた発表者と話をすることができた。マレーシアでは日本もそれなりに学生の進学先として人気があるけど、最近では地理的な近さから台湾も人気があるし、オーストラリアも人気、とのこと（自分の英語があっているなら）。日本人は日本からの距離で各国の位置を把握するけど、マレーシア人もマレーシアからの距離で考えるようなので、自分の中心がどこにあるかで見方が変わるのも面白いなぁ、と思ったりした。

二つ目のセッション(15:30-17:00) は、せっかくの機会だったので中国語のみのセッションに参加をしてみた。こちらのセッションはさっきのセッションと異なって学生の発表が多かった。学生が多いのが、中国語で発表できるからなのか、それとも二つ目のセッションの時間帯は学生が多くなるようにスケジューリングされているのか、そのあたりはちょっと分からなかった（誰かに聞いてみても良かったと思う）。内容としては最適化やロジスティクス関係の話で、NP-hardな定式化に対して VNS などのヒューリスティクスを適用していて、それらの調整方法などを話しているものや、RMFS (Robotics Mobile Fulfillment System) に関するGAの性能向上や Permanent Magnetic Clamping Blocks の利益最大化、他にも生産過程に対する２目的最適化にNSGA-IIを使って信頼性の最大化とコストの最小化を同時に行うようなもの、多目的最適化に対する Deep Reinforcement Learning, Job Shop Scheduling Problem に対する cloud + edge computing で Reinforcement Learning などしているものなどがあった。

このセッションでは、スライドは中国語で書かれていて発表も中国語で行われているわけだけど、スライドの漢字と数式を見ているとおおよその意味合いは推測がつくことが多い。（例えば、「最適化」は「最佳化」。）一方で、今回の学会は発表件数が多いからなのか発表一件当たりの時間は発表１２分＋質疑３分と短めで、言語の壁よりも時間の壁の方が意外にもきつい感じだった。

ちなみに、発表のアブストラクトについては印刷版はなく、インターネット上から自分でダウンロードしてくる形式なので、アブストラクトは誰でも読むことができる。そのうちに検索サイトのロボットが情報収集に来れば、検索サイトの検索対象にもなるのかと思う。

セッションは17:00に終わって、最後にクロージングのコメントが台湾OR学会会長兼実行委員長からあって、それで解散、という感じだった。最後の解散の時点でもオープニングの半分以上の参加者が残っていたかと思う。

今回の学会で他のところと違うなぁ、と感じたのは２点で、一つはどこでも写真を多く撮っているところ。受賞者が記念品をもらうときに写真を撮るのはよく見かけるけど、今回はセッション終わったところで発表者だけでなく聴講者も並んでの撮影があったりした。もう一つは、それぞれの発表が終わって質疑応答が時間ギリギリまでならなくても次の発表に移ってくこと。だから２つのセッションとも90分の時間のところ80分ぐらいで終わったかと思う。これらは今回だけなのか、それとも台湾の慣習なのか。

 

ということで、今回は台湾オペレーションズ・リサーチ学会に参加をしてきた。研究内容については自分がまだ知らない手法なども多く、とても勉強になったし、とても刺激になったし、もっと研究をしたくなったりした。あと、ごはん、美味しい。

Google Colab ってパッケージ開発者にとっていい環境かもしれない

Python プログラムの勉強をするときに Google Colab って便利だなぁ、と思ったりしている。

いろんなパッケージなどが入っていることもそうだけど、やはり一番の理由は「環境構築が必要ない」というところ。pipenv や venv あるいは conda と pip などの「複数ある手法のうちのどれを使えばいいの？」ということがないのが、かなり良いのではないかと思う。

特にパッケージ開発者の場合は「Google Colab でテストして問題ありませんでした」だけにできれば、pipenv, venv, conda などの複数の環境でテストする必要もなくて、効率的にはなりそう。

ちなみに、Julia の場合は Google Colab を使ってもいいけど、Julia の環境構築は簡単なのでローカルにインストールするのも大変ではないかな、と思う。

Julia のベクトル計算高速化

 Julia についての本ということで「１から始める Julia プログラミング」を読んでみた。タイトルから見ると初心者向けのようにも見えるけど、Julia で基本的なプログラミングができる段階から読んでみると多くの勉強になるかと思う。

 例えば、ベクトル x = [5; 3] に対して, a = 7, b = 4 のスカラーのときに
a*x .+ b
とすれば、数式で言うa*x+b*[1; 1] が計算できるわけだけど、これは
a.*x .+b あるいは @.(a*x+b)
の方が良い。

これがなぜ良いのか、という理由が分かりやすく書いてある。上の例だと小規模なのであまり影響が出ないが、最急降下法などで反復回数が増えるとパフォーマンスに違いが出そうにも思う。（この違いをコンパイラが最適化で吸収すると、パフォーマンスの違いはなくなるかもしれないけど。）

他にも、コードを関数の中に入れるだけで Julia は高速化されやすくなるのか、など、高速化の理由が書いてあり勉強になる。

あと、パッケージ管理や仮想環境などについても触れていたりなどなど、勉強になる点が多い。

Python が難しすぎる

数理最適化のアルゴリズムを実装するにあたって、たまに Python を使うことがあるが、だいぶ Julia に慣れてしまうと Python は難易度が高いように感じる。

個人的に難しいと思うのは主に３点で

1. conda と pip が混ざると環境が壊れることがある

2. python のバージョンが上がったときに対応できないライブラリがあって、複数の python を維持しないといけない

3. インデントでループ範囲を特定するため、コピー＆ペーストが簡単にできない

 

２番については Julia でも他のライブラリで同じことは起きるので本質的な解決はできないことは同じだが、Pythonのほうがバージョン管理をきちんと行わないといけないような印象がある。

３番については、どこか別のプログラムで書いた一部分をコピー＆ペーストしたときに、ループ範囲のインデントのスペース数が異なるとややこしいことになってしまう。このあたりは、for～end などで特定できると整形はエディタにお任せできるので、だいぶ楽ではある。

ただ、Julia が完璧かというとそういうわけでもなくて、例えば using の遅さなどはそのうちに改善されていくのではないかと思っている。Python もパッケージ管理や仮想環境管理は、もっといいものが出てくるのではないかと思っている。

 

SIAM Optimization 2021 と IFORS 2021

SIAM Optimization と IFORS 2021 に参加してみた。

２つともに元々は2020年に開催予定だったものが、延期でオンライン開催になったものだ。

SIAM Optimization はアメリカ東海岸の時間に合わせて、基本的にはリアルタイムでの参加、IFORS は開催国の韓国の時間に合わせてビデオ上映＋リアルタイムでの質疑応答、というスタイルになっていた。

IFORS については、開催前に発表ビデオをアップロードしておくスタイルだったので「質疑応答をリアルタイムでする意味あるのかな？」と疑問ではあったけど、やってみるとSIAM Optimization のように全部をリアルタイムで行うよりも良いスタイルのように感じた。

やっぱり発表するというのは、それなりに体力を使うので、そのあとの質疑応答まで続けると、発表者にも疲れが出ていることがあるけど、先に発表の部分をビデオ撮りしているからか質疑応答もテキパキと進んでいる感じがあった。あと、質疑応答の時間だけなら時差があっても何とか乗り越えられる、という印象も多かった。

開催する側にとってはビデオのアップロードをサポートしたり、それをちゃんと発表時間に合わせて再生したり、などなど手間暇もかかると思うだろうけど、個人的には結構な好印象だった。

まぁ、IFORSは日本との時差が０時間で体力的に楽だったというのは、あるかもしれない。

 

いまのところ、２つの学会で収集した論文などの情報を整理しているところで、どの内容が面白いかも、少しずつ確認していきたいところ。

SDPA with different compilers and linear algebra libraries

 2014年とかなり以前の記事だけど、

 SDPA with different compilers and linear algebra libraries

https://peterwittek.com/2014/08/sdpa-with-different-compilers-and-linear-algebra-libraries/ 

という記事を見つけた。

gcc, icc, pgi というコンパイラでSDPAをコンパイルしたときにどれくらいの差が出るか、というのをまとめてあって、結構コンパイラによっても性能に差が出るのが面白い。

 

ダークモードを止めてみた

 いろんなエディタなどでダークモードがあるので、ダークモードも使ってみたけど、結局はやめることにした。

一番の理由として「目が疲れる」があった。

論文を読みながらプログラムを作ったりするわけだけど、論文はPDFなのでフォントを自由に変更することができない。論文のフォントはダークモードを前提にしているものではないので、ダークモードだと読みづらい。結果的にPDFはライトモードでエディタがダークモードだと明暗の差に目を合わせるのが頻繁になってしまって、目が疲れてしまう。

やはり、PDFはフォントを変えることができないのが長時間読む場合でも辛いので、なんとかならないものかな、と思ったりしている。