Vimの読み方

もうひとつ最近気になっているのが Vim の読み方で正しくは「ヴィム」という発音に近い、ってことです。Vim の解説を読んでみると

http://vimdoc.sourceforge.net/htmldoc/intro.html#pronounce

にあるように「Jim っていう名前はジェー・アイ・エムじゃなくてジムって一つで読むだろう、だからVim はヴィー・アイ・エムじゃなくてヴィムなんだ」というようなことが書いてあるのです。

個人的には、「だったら、USAも名前の一種だから「ウサ」って読むってことなのか？」とか思ったりで（そもそも Vim も Vi IMproved から来ているので一単語ではない）、やはりこのあたりは英語のネイティブに聞いてみないと分からないのかも、と思ったりする日々なのです。

「査読」という古い文化について

最近、Githubをそれなりに使い始めていろんな機能があるなぁ、と思い始めているわけですが、その中で「査読」っていうプロセス自体はGithubの時代には古いやり方なのかもしれない、と思ったりしています。（個人的な感想だけど。）

Githubの機能にはたくさんの機能がありますが、そのなかでも Issues と Pull Request が良い機能だと思います。
従来の査読の問題点だと思うのは

１．基本的に密室で行われているので、査読者と編集者の意向に左右されやすい（査読者などには当たり外れがある）
２．一度 publish されてしまうと、そのあと間違いがあっても余程の間違いでないと修正されない
３．論文を読んだ人が新しいアイデアとかできても、それを掘り下げるような議論をする場所がメールだったり国際会議だったりに限定されてしまう
４．arXivにあがっている原稿と比べると、査読を通ったあとの最終稿のほうが質は当然上回るけど、ほとんどの場合はarXivの原稿の時点で研究の核となるアイデアは理解できる。つまり、arXivの原稿を読んでいるだけでも、かなりの研究ができる時代になり、査読の相対的重要性が下がった

などなどだと思います。
このあたりが Github で論文を公開して、そのあとを Issues なりでフォローしていくようになれば、かなり改善できる考えられます。


まぁ、実際にやろうとしたら脈々と続いてきた古い文化をなくすので相当大変だと思います。その一方で例えば「Githubの運営者が勝手に編集できてしまうのでは？」とかいう疑問などについては「Gitlabとかを複数たててミラーリングする」なり「論文掲載にブロックチェーンの情報を追加して改ざんすると分かるようにする」なり、いろんな疑問も現在のITを使うと結構クリアできるのでは？と楽観的に考えたりもしています。

もちろん、査読にもいい面が当然あるわけで、世の中で使われているわけです。
ただ、Github など最近のものに触れていると、そういったものも変わっていくのが世の中にとっては必然なのかもしれないなぁ、と思ったりする、というところです。

TeXのソースは、コマメに改行すべきである

TeX のソースで、一段落ごとに改行していたりすることがあるわけだが、やはりもっと少ない文字数で改行をすべきであると個人的には思ったりしている。

もちろん、最近の TeX のエディタは右端で折り返してくれるので、TeX のソースを読んだり書いたりするときには改行はたいして重要ではない。
ただ、コマメに改行すると以下のようなメリットがある。

1. TeXのコンパイラは「何行目にエラーがあるか」を教えてくれるので、各行の文字数が短いほどどこにエラーがあるのかを人間が確認しやすい。TeXの統合環境ならエラーのある行の番号にジャンプする機能もあるので、数行に分かれているほど作業しやすい。
2. git も行ごとに認識しているので、１行が300文字もあると1文字修正しただけで300文字の修正として登録しないとならない。

もちろんひたすら改行すればいいってものではないけど、できれば80文字ぐらいでTeXの場合は改行してほしい。

LaTeXとヴィルトの法則

ここ最近になって「LaTeX のコンパイルがどんどんと遅くなっている」と思っていて「個人の感想です」かと思っていたら、他の人も似たようなことを思っていたそうで「少なくとも２人の感想です」ということが分かった。

世の中には「ヴィルトの法則」というものがあるそうで、「ハードウェアがスピード向上はソフトウェアのスピード低下に打ち勝てない」ということで、「あぁ、まさに LaTeX のことだなぁ」と思ったりする。
2000年ごろの論文を見ると LaTeX が既に使われていて（いつから使われているのかはよく分からないけど）、20年ぐらい経って数式とか論文を書くとかいうのには、どんどんと遅くなりつつあるかと思う。

個人的に「ヴィルトの法則」だと思うもう一つはエディタの Atom で、使っている人が減っているのは、やっぱり動作の遅さが原因なんだろうなぁ、と思う。前に使っていた時は、起動するためのアイコンクリックから文字を書き始めるまでに２０秒ぐらいかかって、「これはしんどいなぁ」と思ったこともある。

逆にWindowsは Windows 7 よりも Windows 10 のほうが動きが速いように感じるので「ヴィルトの法則」からは外れているのかもしれない。ただ、半年ごとのアップデートでは少しずつ遅くなっているようにも感じる。

Juliaの型宣言は、かなり厳密

数値実験をやっていて気がついたけど、Juliaの型宣言はかなり厳密に行われているようだ。

たとえば、xを変数ベクトルとして定義したときに
x[1], 1.0*x[1], x[1]+0.0
などは数学では等価として計算してほしいけど、Juliaでは異なるものとして処理されるようで、最適化ソルバーに入れて結果を見ると違う結果が出てくることがある。

JuMPなど複数のパッケージを使っているので、どのパッケージで異なる処理が入るのかを特定できていないけど、このあたりは気をつけたいところだ。

（理由として推測できるのは、C言語の int 型だと 3/2 が 1 になって、double 型だと 3.0/2.0 が 1.5 になる、みたいなこと、かと思っている。）

論文読み：On Polyhedral and Second-Order-Cone Decompositions of Semidefinite Optimization Problems

Optimization Online に出てきていた
"On Polyhedral and Second-Order-Cone Decompositions of Semidefinite Optimization Problems"
http://www.optimization-online.org/DB_HTML/2019/09/7392.html
をザックリと読んでみた。

基本的には、半正定値条件をＬＰだったりＳＯＣＰだったりで近似する、という話だった。
近似して解いた後に、半正定値条件を満たしていなければ、切除平面を入れて解きなおしている。

数値実験は Sparse PCA と nuclear norm 最小化を扱っていて、やはり、問題が大きなものには近似でやったほうが大きなサイズが解けるようだ。
SOCPで半正定値条件を近似すると、切除平面法の収束は普通には結構な反復回数が必要なので、Sparse PCA や nuclear norm 最小化は問題の構造が比較的簡単なのかもしれない。

台湾でタピオカミルクティーも飲んできた

今回は50嵐で２回、タピオカグリーンミルクティーを飲んできた。
１杯35元なので、120円ぐらい。
結構手軽に飲むことが出来て、日本でいうと駅の自動販売機で飲み物を買うぐらいの手軽さ。

50嵐はドリンクバーなのでタピオカ以外を選んでもいいのだけど、2011年に台湾でタピオカミルクティーを飲んでから、台湾に行くたびに、ついついタピオカを注文してしまう。個人的には紅茶のものよりも緑茶ベースの方が美味しいと思う。さらに個人的には、もともと甘めのタピオカミルクティーに砂糖を多めにしてもらうと、もっと美味しいと思う。さらにさらに個人的には、砂糖は70%か100%、氷はなしにしてもらっている。


カロリーについては個人的には気にしていないが、そういう人ばかりでもないと思うんで、自分が楽しめるように好きなようにアレンジしたらいいかと思う。