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はフォントを変えることができないのが長時間読む場合でも辛いので、なんとかならないものかな、と思ったりしている。

RictyやMigu 1Mを試してみたけど

 それなりにプログラミングをしている時間もあるので、フォントを変更したらもっと便利かもしれない、と思ってやってみたけど、結局ダメだった。

 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点刻みとシンプルなので、最適解も結構シンプルな組合せになるようだ。