投稿
すべてのコメント
このまえのワークショップで面白そうと思った論文の手法などを調べているが、生成系AIで質問していると「学会とかワークショップで発表の直後に質問するような時間はだんだんと不要になっていくのでは？」と思ったりする。
30分とか１時間の時間では説明に含められないような詳細内容についても確認できるから、「今聞いて、パッと思いついた質問」だけでなく２時間ぐらいいろいろと考えたうえで気になるようなことも聞くことができるのは、個人的には面白いと思ったりする。
インターネットができて学会の開催の仕方もだいぶ変わったわけだけど、生成系AIによってもだいぶ変わっていくのかもしれない。
DOxML 2026 という discrete optimization と machine learning のワークショップがあって、これに参加してみた。
全部の発表を完全に理解できたわけではないけど、 面白い発表がいくつもあって良かった。たとえば、「BFGS の大域的収束」とかの話もあったりして、これはBB-stepの解析にも使ったりしたら面白そうだと思う。あとは、AI に関する計算とかもあって、例えば LLM の内部での最適化計算を高速化する手法とかあったり、そもそも「計算可能とは何なのか」とか、そういう話もあった。あとは Magic Square を超高速に計算する、とか、ネットワークの中でどのように影響力をあげていくか、っていう話もあった。
ふつうの国際会議だとパラレルセッションになって、どうしても自分の研究に近いところに行きがちだけど、こういう風にシングルセッションだと自分が普段は聞きに行かないような話もあって、非常に勉強になる。
とりあえず、A5ノートで30ページぐらいメモを取ったので、どれをより詳しく調べようか整理を始めたところ。
いま、RAMP2023の原稿を読み直しているところ。
いろいろと参考になるところが多くて、勉強になる。
論文っていうのは、手元に置いておくと、いつまで経っても再度読みなおせるところがいいところかと思う。
量子コンピュータで Ising モデルや QUBO に定式化して問題を解く、というときに例題として巡回セールスマン問題を定式化するのは良くあるパターンだと思うが、実際に「量子コンピュータで巡回セールスマン問題を上手く解けた」という話はあまり聞いたことが無い。
ちょっと調べてみたら、ちょっと面白い話があって、
「物理現象で巡回セールスマン問題として定式化できるものがほとんどない」
というのがあった。確かに「N個の頂点を順番に巡る原子」とか、あまりイメージしづらい。
一方で、通常のコンピュータ（古典コンピュータ）に使われる電気とかも、「N個の頂点を順番に巡る電気」とかあまり聞いたことが無いので、上の話をそのまま鵜吞みにするのも良くないとは思う。ただ、量子コンピュータのほうが純粋な量子状態を維持する必要があるから、古典コンピュータほど人間が介入できないのかも、とは思ったりもする。
勉強の一環として、内点法の論文を参考に、内点法の「証明」のプログラムを作ってみた。
連続最適化関係だと first-order methods については既に証明のプログラムが存在するので、内点法で行ってみた。
現時点でやるのは、線形代数や基本的な解析のあたりをそれなりに自前で準備しなくてはいけないので、そのあたりが結構大変ではあるけど、プログラムとしては書くことができる。そのうちに、Mathlib などが整備されると、もっとスッキリとしたプログラムとして証明を書けるようになるかと考えられる。
ノルムを計算したりするときに sqrt(a^2+b^2) とプログラムを書いてしまうことがあるが、これをちゃんと精度よく計算する方法が
An Improved Algorithm for hypot(a,b)
https://arxiv.org/pdf/1904.09481
で議論されている。 数値誤差に関しての議論は、こんな基礎のところにもあるんだな、と思ったりする。
7月に行われたICCOPTについて、参加する前の週に発表プログラムの中から自分が聴講するべきセッションについて挙げさせてみた。その感想を書いておく。
という感じで、現状としては使える部分もあれば使えない部分もある、というところ。セッションが実際に存在するかどうかは自分で確認する必要がある。
事前に試してみればよかったと思うのは「このセッションは何人ぐらい聴衆が来るか」と予測させること。どういったデータを元に予測するのか、というのは面白そう。
あと、ICCOPT ではプログラムなどがPDFではなくてウェブページにしかない状況だったので、これが一つのPDFとなっていたら情報がより上手く取り込めたのかもしれない。
Julia を VScode で書いている場合、正しいコードにも関わらず、Possible method call error という警告表示がでることがあって、Githubのページを見るとバグとして起きているようです。
例えば、行列A,Bに対して
C = kron(A,B)
とすると、kron に Possible method call error が付きます。
この場合、
C = kron(A,B)
とすると、警告が消えます。no-undef は種類によって変更が必要かもしれません。
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分ぐらいで終わったかと思う。これらは今回だけなのか、それとも台湾の慣習なのか。
ということで、今回は台湾オペレーションズ・リサーチ学会に参加をしてきた。研究内容については自分がまだ知らない手法なども多く、とても勉強になったし、とても刺激になったし、もっと研究をしたくなったりした。あと、ごはん、美味しい。
Python プログラムの勉強をするときに Google Colab って便利だなぁ、と思ったりしている。
いろんなパッケージなどが入っていることもそうだけど、やはり一番の理由は「環境構築が必要ない」というところ。pipenv や venv あるいは conda と pip などの「複数ある手法のうちのどれを使えばいいの？」ということがないのが、かなり良いのではないかと思う。
特にパッケージ開発者の場合は「Google Colab でテストして問題ありませんでした」だけにできれば、pipenv, venv, conda などの複数の環境でテストする必要もなくて、効率的にはなりそう。
ちなみに、Julia の場合は Google Colab を使ってもいいけど、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 を使うことがあるが、だいぶ Julia に慣れてしまうと Python は難易度が高いように感じる。
個人的に難しいと思うのは主に３点で
1. conda と pip が混ざると環境が壊れることがある
2. python のバージョンが上がったときに対応できないライブラリがあって、複数の python を維持しないといけない
3. インデントでループ範囲を特定するため、コピー＆ペーストが簡単にできない
２番については Julia でも他のライブラリで同じことは起きるので本質的な解決はできないことは同じだが、Pythonのほうがバージョン管理をきちんと行わないといけないような印象がある。
３番については、どこか別のプログラムで書いた一部分をコピー＆ペーストしたときに、ループ範囲のインデントのスペース数が異なるとややこしいことになってしまう。このあたりは、for～end などで特定できると整形はエディタにお任せできるので、だいぶ楽ではある。
ただ、Julia が完璧かというとそういうわけでもなくて、例えば using の遅さなどはそのうちに改善されていくのではないかと思っている。Python もパッケージ管理や仮想環境管理は、もっといいものが出てくるのではないかと思っている。
SIAM Optimization と IFORS 2021 に参加してみた。
２つともに元々は2020年に開催予定だったものが、延期でオンライン開催になったものだ。
SIAM Optimization はアメリカ東海岸の時間に合わせて、基本的にはリアルタイムでの参加、IFORS は開催国の韓国の時間に合わせてビデオ上映＋リアルタイムでの質疑応答、というスタイルになっていた。
IFORS については、開催前に発表ビデオをアップロードしておくスタイルだったので「質疑応答をリアルタイムでする意味あるのかな？」と疑問ではあったけど、やってみるとSIAM Optimization のように全部をリアルタイムで行うよりも良いスタイルのように感じた。
やっぱり発表するというのは、それなりに体力を使うので、そのあとの質疑応答まで続けると、発表者にも疲れが出ていることがあるけど、先に発表の部分をビデオ撮りしているからか質疑応答もテキパキと進んでいる感じがあった。あと、質疑応答の時間だけなら時差があっても何とか乗り越えられる、という印象も多かった。
開催する側にとってはビデオのアップロードをサポートしたり、それをちゃんと発表時間に合わせて再生したり、などなど手間暇もかかると思うだろうけど、個人的には結構な好印象だった。
まぁ、IFORSは日本との時差が０時間で体力的に楽だったというのは、あるかもしれない。
いまのところ、２つの学会で収集した論文などの情報を整理しているところで、どの内容が面白いかも、少しずつ確認していきたいところ。
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はフォントを変えることができないのが長時間読む場合でも辛いので、なんとかならないものかな、と思ったりしている。
それなりにプログラミングをしている時間もあるので、フォントを変更したらもっと便利かもしれない、と思ってやってみたけど、結局ダメだった。
Ricty Dimished や Migu 1M などが良さそうなので、それを試してみた。（個人的には0は中にドットが入っているものよりもスラッシュが入っているほうが見やすいので、そういうので選んでみた。）
確かに見やすくはなったのだけど、これらのフォントでは自分の環境では
εが正常に表示できなかった。
自分のプログラムでは0とOやIとlと1を見間違えることはほぼないので、それらの差が見た目で分からなくても対して困らないのだけど、さすがに \epsilon が \cdot になってしまうのは致命的なので、結局フォントはデフォルトに戻した。
たぶん自分の環境で上手くいかないだけで他の環境では上手く表示できているんだろうけど、逆にどうやって解決したらいいのかが情報収集できず断念。
個人的には Migu 1Mは見やすいと思う。
「ヤマザキ 春のパンまつり」では、各パンに点数がついていて合計点数が28点を超えるとお皿を１枚もらえる、ということになっている。
こうなると最適化の視点では当然のことながら「１枚もらえる最小金額がいくらだろうか ？」というのが気になってくる。
そこでサクッとJuliaで最適化を行ってみた。
[1] まずはデータが必要ということで
https://gameboku.com/archives/21020003.html
に纏めてくれてあるデータを使わせてもらうことにして
【表1】全対象商品（338品） 点数・カロリー効率一覧
の表部分をExcel にコピー＆ペーストして UTF-8 の CSV として保存する。ファイル名については、今回はあまり深く考えずに Book1.csvとしておいた。
[2] 以下の Julia コードを実行する。
==========================
using CSV
using DataFrames
using JuMP
using GLPK
using LinearAlgebra
df = CSV.File("Book1.csv", header=true, delim=',') |> DataFrame
point = df.得点
price = df.価格
name = df.商品名
n = length(price)
model = Model()
set_optimizer(model, GLPK.Optimizer)
@variable(model, x[1:n]>=0, Int) # 商品は整数個
@constraint(model, dot(point, x) >= 28) # 合計28点以上
@objective(model, Min, dot(price, x)) # 合計金額を最小化
optimize!(model)
x_value = Int.(value.(x)) # 最適解を得る
optimal_value = Int(objective_value(model)) # 最適値を得る
nz_index = findall(x_value .!= 0) # 0 個になっていないところのみを抜粋
println("--最適合計金額 = $(optimal_value)円")
println("--最適解--")
for index in nz_index
print("$(name[index])")
print("[$(point[index])ポイント, $(price[index])円]を")
print("$(x_value[index])個購入する")
println()
end
==========================
[3] 結果を見る
プログラムにバグとかがなければ、これで求めることができる。
Julia を使うのが面倒であれば、Excel のソルバーを使っても同様に求めることができる。
ちなみに、点数が0.5,1.0,1.5,2.0,2.5と0.5点刻みとシンプルなので、最適解も結構シンプルな組合せになるようだ。
TeXLive を 2020 に上手く更新できなかったので再インストールすることした。
scheme を full にして完全インストールすると5GB以上のディスクを消費するが、試しに scheme を basic にしてインストールしてみた。
もちろん、いろいろと足りないパッケージがあって、例えば algorithm.sty が入ってなかったので、
$ tlmgr search --global --file algorithm.sty
として algorithms パッケージを特定して、これをインストールしてみた。
$ tlmgr install algorithms
他にも足りないものがあれば逐次インストールして、あと platex も入ってなかったのでplatexもインストールしてみた。
結果的には500MBぐらいの容量だけで自分が使っているTeXソースをコンパイルできた。
どうやら、自分のところではTeXLiveの機能の10%だけで十分なようだ。
Termuxを使っているときに気がついたけど、ssh だけでなく ssha というコマンドもあり、これが結構便利。
ssha の場合は、https://wiki.termux.com/wiki/Remote_Accessにも 書かれている通り、
ssh-agent を自動的に処理してくれることになっており、例えば
$ ssha server01
としてsshのパスフレーズを入力してserver01 にログインした後に、もう一度 Termux の別のセッションから
$ ssha server01
とすると、今度はパスフレーズの入力を省略してログインできる。
片方のセッションでエディタを使っていて、もう片方でコマンドラインで実行する、と言ったときに便利。（似たようなことは screen コマンドで複数のウィンドウを使ってもできるけど。）
Matlab R2020a のmexでコンパイルするには、gcc のバージョンが6.3.0とかなり古いものが必要となるが、gcc 6.3.0 はそのままではgcc 10.1.0 ではコンパイルできなかったので（途中でエラーが出る）、コンパイル方法をメモしておく。
$ wget http://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-6.3.0/gcc-6.3.0.tar.gz
$ tar xzf gcc-6.3.0.tar.gz
$ mv gcc-6.3.0 gcc-6.3.0-source
$ cd gcc-6.3.0-source
$ ./contrib/download_prerequisites
$ cd ..
$ mkdir -p build
$ cd build
$ ../gcc-6.3.0-source/configure --prefix=[インストールパス]/gcc-6.3.0 --disable-multilib --disable-libsanitizer
$ make
make が途中で止まったら、
emacs +61 x86_64-pc-linux-gnu/libgcc/md-unwind-support.hn
で
struct ucontext *uc_ = context->cfa;
を
ucontext_t *uc_ = context->cfa;
とする。
これで再度 make をする。
$ make
また停止したら、 `find . | grep java-signal.h`
./include/java-signal.h:31:10: note: forward declaration of ‘struct _Jv_catch_fpe(int, siginfo_t*, void*)::ucontext’
struct ucontext *_uc = (struct ucontext *)_p; \
の部分を
ucontext_t *_uc = (ucontext_t *)_p; \
にする。
これで再度 make をする。
$ make
あとは make install する
$ make install
インストールした後の環境変数の設定方法としては、
export PATH=[インストールパス]/gcc-6.3.0/bin:$PATH
export LD_LIBRARY_PATH=[インストールパス]/gcc-6.3.0/lib64/:$LD_LIBRARY_PATH
