2011年6月30日木曜日

Grammarly の結果を反映

昨日まででひと通り済んだ Grammarly での文法チェックの結果を TeX のほうに反映しておいた。
この状態で、とりあえず Abstract と Introduction だけを英語が上手な人に見てもらうことにした。

これで、どの程度 Grammarly が自分に使えるのかが解かると考えている。
(ただし、Grammarly は修正ポイントを示してくれるだけなので、使用する人の英語力で性能が大きく変わる可能性あり)

あと、SDP を使わない SNL のプログラムを見ていたときにバグがあることがわかったので、これを修正する必要がある。このプログラムは git では管理していなかったので、git の管理下に持って行こうと思う。

今日の作業内容:Grammarly 反映 1h + SNL チェック 3h
今日のランチ:味庵 翡翠麺の冷やし中華
明日の予測作業時間:4h

2011年6月29日水曜日

Grammarly を使い始めてみた

昨日のTeXのための準備に続いて、今日はどれくらい Grammarly で修正できるかを箇条書きで書くことにする。

なお、Grammarly の場合は自動的に変更するのではなく、「ここを直した方がよい」というのが列挙される形で、修正は自分で行う。

[1] それなりに修正される
機械的に判断される割には、それなりに修正が入る。
[2] 受動態はすべてチェックされる
受動態全部について「修正するべき」というコメントがつくので少し面倒ではあるが、本当に必要が受動態かどうかを判断することになるので、それなりに使える。
[3] 類似語に分野の内容が反映されない
たとえば、sparse は scattered にされるし、parallel factorization の parallel は matching にされるし、thread が line にされそうになったり、専門的な用語は類似語で変更されてしまいやすい。
[4] 主語と述語の対応がずれると、ほぼ指摘される
とくに分詞で Being accurate, we use this result. などのようなことをすると指摘されやすい(ただし、この例文だと、なぜか指摘されない[すりぬけてしまう])
[5] collocation が反映されない
たとえば、be interested in などで in を with に間違えると
I am interested with this song. が interested のsynonyms が表示されてしまう。

ここまで使った印象では、まだまだ改良の余地はある感じであるが、3日ぐらいしてくると何ができて何ができないのか解ってくる。
あと、オンライン上での校正システムなので、改良なども逐次反映されるのかもしれない。
そうそう、Office の Add-in は、Word 内で校正できるわけではなく、自動的に Internet Explorer などが立ち上がるだけなので、今の段階では特に必要性は感じない。
また、オンラインであるため、Linux でも Windows でも、そのまま利用できる点は便利である。


とりあえず、SDPARA の論文については一通り Grammarly でチェックしてみたところだ。
(システムに慣れるのも含めると12時間ぐらい?)
これをあとで TeX に反映させることにする。


今日の作業内容:SDPARA 校正 3h
今日のランチ:日高屋 盛岡冷麺と半チャーハンセット
明日の予測作業時間:4h

2011年6月28日火曜日

Grammarly を使いはじめてみた(TeX 用の準備編)

SDPARA の論文の校正にあたって、オンラインで英文法をチェックしてくれる Grammarly というのを使いはじめてみた。

Grammarly は
http://www.grammarly.com/
からアクセスできるが、有料のシステムである。クレジットカード または PayPal の支払いとなるが、1ヶ月、3ヶ月、1年間の利用期限ごとに金額が決まっていて、期間が延びるほど割安になっている。1年間の使用でも100$未満になっている。

基本的な使い方は Grammarly のサイトにログインして、そこに英語の文章をコピー&ペースト。あとは文章のスタイル(技術的なのか、とか、カジュアルなのかなどのタイプ)を選択してボタンを押すと、インターネット経由で英文法を解析して表示してくれる。



SDPARA の論文は TeX で書いているが、このままで Grammarly にかけるのは大変なので、TeX ソースを加工しておいた。
まずは、
$ sed "s/%.*//g" source.tex > grammarly-1.tex
として、コメント行を削除。
次に grammarly-1.tex を emacs で開いて、改行をなくしていく。これは、Grammarly の場合に改行までを1文とみなすことに影響している。具体的には、
I like
apples.
と改行が入っていると、"I like" の文章にピリオドがない、という指摘を受ける。
emacs では、Ctrl-x f で 各行の長さを変更できるので、ここで 10000 ぐらいにしておいて、あとは段落ごとに Meta-q をして、各段落を1行にしている。

ここまでして、grammarly-1.tex を作っておく。
これを grammarly-2.tex とコピーしておいて、Grammarly からの修正は grammarly-2.tex に反映させる。これで grammarly-1.tex と grammarly-2.tex の diff をとれば、簡単に修正箇所を発見できるようになる。
ただし、上の修正で各行が長いので単語レベルで diff をとる必要がある。Linux には wdiff というコマンドがあるので、これを使えば単語レベルで解かるが、このままだと[-Before-] {+After+} のようになって、色がつかず見づらい。これに色をつけるには、~/.bashrc に
alias wcc='sed -e "s/\[-/`echo -e \"\\e\[36m\"`\[-/g" -e "s/-\]/-\]`echo -e \"\\e\[0m\"`/g"  -e "s/{+/`echo -e \"\\e\[31m\"`{+/g" -e "s/+}/+}`echo -e \"\\e\[0m\"`/g"'
を入れてから
$ source ~/.bashrc をする。
このあとで
$ wdiff grammarly-1.tex grammarly-2.tex | wcc | less -R
とすると、違った部分に色がついて less で表示できるようになり、修正点を簡単に把握できるようになる。
上の例だと、 [-Before-]  {+After+}  となる。
ちなみに、wcc は36,31 でそれぞれ水色、赤色を指定しているので 30-37 の間で色を指定できる。(おそらく、もっと細かい色指定もできるはずである)

Grammarly で英文法がどれくらい指摘されるかについては、明日書くことにする。

今日の作業内容:SDPARA 校正 4h
今日のランチ:らく 鶏照焼
明日の予測作業時間: 5h

2011年6月27日月曜日

SNL についての発表

今日は、アウェイでの SNL の発表をしてきた(それほどアウェイってわけではないけど)。

SDP緩和の基本的なところも入れたのでだいぶ時間がかかったが、ひと通り話をできたのでいいにしておこうと思う。

いろいろと質問はあったけど、まずは SDPA-C でもできるのかどうか、いくつか問題を生成して確認してみようと考えている。(今になって思ったが、SDPA-C は最適値だけで最適解を返さないような気がしている)。

今日の作業内容:SDPARA の英語校正 4h + 発表 2h
今日のランチ:角笛 ホイコーロー
明日の予測作業時間:4h

2011年6月24日金曜日

校正をもう一度見直し

英語のチェックにはいる前に、もう一度全部の文章を見直しておいた。
ここまででだいぶ校正してはいるが、まだまだカットできるところもあったので、それをカットした。
これで、以前に調べた Grammarly を適用してみようと考えている。


今日の作業内容:SDPARA 校正 3h
今日のランチ:ちゅらさん ふーチャンプル
明日の予測作業時間:4h

2011年6月23日木曜日

gitk のフォントを綺麗にする(Ubuntu 11.04)

gitk を Ubuntu で使っているとフォントが綺麗でないので使いにくいのですが、それを綺麗にできます。

基本的な方法と原因はこちらに書いてありますが、ここでは alternatives を使ってファイル修正をしないで済む方法を使います。

方法としては、
$ sudo apt-get install tk8.5
$ sudo update-alternatives --config wish
ここで/usr/bin/wish8.5になるように選択肢の番号(自分の場合は3だった)を選択します。
このあとで
$ gitk --all
とすると、フォントが綺麗になります。

ちなみに、Ubuntu 11.10 からは同じ原因でフォントが綺麗ではない現象がなくなるはずです。(tk のバージョンがデフォルトで 8.5 になるため)


今日の作業内容:レフリーレポートへの返事の下書き 4h
今日のランチ:シッダルータ グリーンピースとジャガイモのカレー
明日の予測作業時間:5h

2011年6月22日水曜日

SDPARA の小さいクラスタでの実験の解析

論文用に準備している実験データを解析しているが、小さいクラスタの場合に予測値と結構かけ離れた数値になっており、気になっている。
この部分は、いわゆる F1,F2,F3 の影響を受けている部分なので、そのあたりのパラメータが影響している可能性があり、そのあたりをもう少し詳しく調べる必要がありそうだ。

論文校正はスリムアップが一通り終わり、次はレフリーレポートで指摘されていながらも、まだ追加してない項目をリストアップして、そのあたりを書きこむ予定である。

今日の作業内容:SDPARA 校正 4h
今日のランチ:婆娑羅 ミニつけ麺
明日の予測作業時間:4h

2011年6月21日火曜日

SDPARA の校正の続き

今日は校正の続きを進めた。内容的には formula-cost-based distribution のあたりまでである。
昨日の Introduction に比べると、内容を削るのが少ないので、比較的進んだ感じである。
明日は、Cholesky 分解のところで、山場のようなものなので、しっかりと進めたい。

今日の作業内容:SDPARA 校正 3h
今日のランチ:味庵 海鮮ミックス野菜炒め
明日の予測作業時間:4h

2011年6月20日月曜日

Linux Mint の Debian Edition をインストールしてみた

どれくらいの使い勝手かを調べるために、vmplayer の上で Linux Mint の Debian Edition をインストールしてみた。

結果として、Ubuntu と同じレベルで使い勝手はいい。あと、Ubutu は Unity だけど、こちらは GNOME2 なので GNOME2 のほうがしっくり来る場合は、かなり使えると考えられる。また、Debian の testing をベースとしているだけあって、ソフトウェアのバージョンも新しいものが目立つ。

欠点としては、Ubuntu Edition の Linux Mint よりもディスク消費量が大きいところである。Ubuntu Edition の場合はデフォルトインストールとそのアップデートで 5GB くらいになるが、Debian Edition だと 6GB 程度となる。Ubuntu Edition の LXDE 版 Linux Mint は 3-4GB 程度なので、1.5-2倍程度も消費する。やはり、フルで Gnome がインストールされることと、Libreoffice がインストールされることが LXDE 版と比較すると重荷のようだ。

全体としては、まだまだ改良点は多そうだが、Ubuntu と Debian の中間として、これからユーザをつかんでいきそうな雰囲気である。




あと、今日は SDPARA の論文の校正をしている。Introduction を 20% ぐらい短縮するのにだいぶかかってしまったので、このあとはてきぱきと進めていくことにする。

今日の作業内容:SDPARA 校正 3h
今日のランチ:らく 焼き魚定食
明日の予測作業時間:3h

2011年6月17日金曜日

Linux Mint の Debian Base

Ubuntu を使ったり Debian も使ったりしているが、最近はどちらも今一つな印象がある。
Ubuntu は半年ごとのリリースなので最新機能があるが、それ以上にバグが多く発生するようになってきている。そもそも3万近くのパッケージがあるので、半年のリリースでは毎日 150 のパッケージの整合性を確認できないといけないのであって、このリリーススケジュールでバグが残らない方が不思議である。
逆に Debian はリリースが遅すぎて、たとえば SDPA のパッケージも次期 Debian で普通に apt でインストールできるようになるが、おそらく次期リリースは 2013 年以降になりそうである。

そこで最近いろいろと調べているのだが、Linux Mint の Debian Base のものがそれなりによさそうである。これは Debian の testing をベースにしているので、Debian よりも機能はあたらしめ、でも Ubuntu ほどリリースは多くない、という中間程度に来る様子だ。
あとで vmplayer でインストールしてみて、どのような感じかを調べてみようと思う。

今日の作業内容:SDPARA 校正 3h
今日のランチ: ちゅらさん 豆腐のチャンプル
明日の予測作業時間:4h

2011年6月16日木曜日

SDPARA の校正の続き

SDPARA の原稿については、「同じことを繰り返し言っている部分がある」という指摘があったので、それを特定するために原稿を読み直している。
また、できるだけボリュームを減らすために要らない単語なども削るようにしている。
まだ半分程度までしか目を通せていないのでもう数日かかる見込みだが、これを進めてすっきりとした形式にしたいところだ。

今日の作業内容:SDPARA 校正 3h
今日のランチ:シッダルータ シーフードカレー
明日の予測作業時間:4h

2011年6月15日水曜日

SDPARA on 小さいクラスタ

SDPARA の論文校正用に小さいクラスタで数値実験をしてもらっているが、ELEMENTS のスケーラビリティが今一つになっている。
CHOLESKY の部分が遅れるのは、ネットワークが遅いのをわざと利用しているからで説明がつくが、ELEMENTS については本来はそれなりにスケーラビリティがでるはずである。
今までのクラスタとは CPU が異なるので、スレッドなどの扱いも異なる可能性もあり、そのあたりは調べてみる必要がありそうだ。

今日の作業内容:SDPARA の論文をスリム化 2h
今日のランチ:四川弁当 豚の角煮
明日の予測作業時間:4h

2011年6月14日火曜日

SDPA の数値実験の終わりが見えてきた

ずっと以前から行っている SDPA の論文校正のための数値実験だが、ようやく終わりが見えてきた。サーバー再起動の関係でスキップしていた問題を解いている状態なので、あと40万秒程度で終わる。日数にして、ざっと5,6日程度である。

具体的な実験結果はここには書かないが(論文として採択された場合に、学術雑誌発行者とブログを運営している会社で著作権とかがどうなるかよく知らないため)、ここまでの計算時間を合計してみたところ、200日分にもなっていた。
どうりでいくら待っても数値実験が終わらないわけである。
とはいえ、終わりが見えてきた以上は、校正を頑張って行きたいところである。

今日の作業内容:SDPARA の論文の校正 5h
今日のランチ:らく うな重
明日の予測作業時間:4h

2011年6月13日月曜日

連立方程式につまづく

LP についていろいろと考えているが、連立方程式のところで躓いている。
方程式の係数行列は [D^{-1} P DQ] という形で、D は n x n の対角行列であり、P,Q は [P Q] と並べたときに直交行列となる行列である。
explicit に表現するのは難しそうだけど、なんとか LU 分解よりも簡単に計算したいところであるが、今ふと思うと LU 分解ではなく、QR 分解ならいいのではないだろうか?

今日の作業内容: LP の計算 3h , SDPARA 校正 2h
今日のランチ:味庵 豚肉と卵の炒め
明日の予測作業時間: 4h

2011年6月10日金曜日

LP の式変形のつづき

昨日に続いて、いろいろと式変形をしてみているが、結果が出るかどうかは不透明。
ただ、すぐに結果が解かるようなことはすでに研究されているだろうし、こういった解からないものも重要かも知れない。

とりあえず、LP は変形して行くと線形不等式になる。これの解を知るには Farkas の Lemma で解くことも考えられるが、Farkas の Lemma は結局 LP の解き方で解くので、直接は参考にならない。
ただ、LP の変形で現れる線形不等式は特殊な形をしているので、それを利用できる可能性はある。

今日の作業内容:LP の式変形の続き
今日のランチ:四川弁当 鶏たまねぎ炒め
明日の予測作業時間:5h

2011年6月9日木曜日

LP の形式を変換

昨日の計算の続きで、式変形を繰り返しているが、SDP だと行列が対称に限定されるのが面倒なので、まずは LP で行う方針にした。

一般に SDP の標準系としては、等式標準系と LMI 標準系があって、それらが主双対のペアとなるが、LMI 標準系は等式標準系に変形することができるので、主双対の両方を等式標準系にできる。
この変形をしたときにどのような効果が得られるかを調べてみている。

今日の作業内容:LMI 変形 4h
今日のランチ:シッダルータ ほうれん草とマッシュルームのカレー
明日の予測作業時間:4h

2011年6月8日水曜日

式を変形してみたけど

今日は、Chordal graph 関係の内容で式変形を繰り返してみたが、いろいろとやったあげく、「今までわかっていること」がわかった。
最後まで来て、「証明していたことと、証明しようとしていたことが違う」という初歩的なミスに気がつく。
まあ、こういう日もある。


今日の作業内容:Chordal graph 関係 5h
今日のランチ:四川弁当 チンジャオロースー
明日の予測作業時間:4h

2011年6月7日火曜日

Mac OS X の難しさ

SDPA などは Mac OS X でもコンパイルできるようにしてあるが、Mac OS X だとうまく行かないこともある。
これは、コンパイルするときの configure が OS 間の差を吸収できなかったりするが、Mac OS X 上の gcc まわりがトラブルの原因であることも多い。
どうやら、binutils と gcc のバージョンがうまく合わないと libgcc.a などが自動的にリンクされないことがある。

Mac OS X 自身がバージョンアップしたり、gcc がバージョンアップしたり、fink からインストールできる gcc がバージョンアップすると、整合性が崩れるこのような現象がそれなりに起こるようで、このあたりをどのように対処するかは今後の課題のひとつだが、難しい問題でもある。


今日の作業内容:Trust Region の論文読み 5h
今日のランチ:角笛 ドライカレー
明日の予測作業時間:4h

2011年6月6日月曜日

SDP の新しいハンドブック

SDP の新しいハンドブックがSpringerから、ついに出版されることになった。
http://www.springer.com/business+%26+management/operations+research/book/978-1-4614-0768-3
SDPA についても1章を書かせてもらっているが、それを抜きにしても
SDP の研究者には以下のような理由からおススメだと思う。

1. 内容的に新しい(5月に行われた SIAM Optimization でのいくつかの発表の内容は、このハンドブックに投稿した原稿に基づいている、などかなり最新の内容が含まれている。)
2. アルゴリズムや理論面だけでなくソフトウェア面などもカバーしている
3. 多項式最適化などの章も多いので、SDPが主に利用されている理由となっているSDP緩和についてもカバーしている



あと、原稿を投稿するときに、Handbook としてまとめる Anjos & Lasserre にはかなりお世話になったと思うので、自分としては本がたくさん売れるとこの二人にいいな、と思っている。


今日の作業内容:Trust Region 関係の下調べ 4h
今日のランチ:ちゅらさん テビチの煮つけ
明日の予測作業時間:5h

2011年6月3日金曜日

電力消費量チェック

今日はいつもと違うことを、ということで節電が重要になってきているので計算にどれくらいの電力を消費しているかを確認してみた。

結果として、仕事場にある計算サーバだけで1日 40kWh, 1か月で 1200kWh かかっていることが解った。
仮に普通の家で 30 A の契約にしていると、これだけで 28,000 円程度の電気代になるようだ(実際には基本料金を含んでいるので、もっと変化するとは思うが)。

あと、自分の仕事の部屋も、従来の消費電力だと月に概算で 13,000 円程度。
蛍光灯の消費電力が30%以上あり、蛍光灯を消すのは案外バカにできない。

いつもは電気代をあまり気にしていないが、こうやって数字にしてみるとまた違った視点が得られる。

今日の作業内容:電力消費量チェック 3h
今日のランチ:たちばな あじ
明日の予測作業時間:4h

2011年6月2日木曜日

SDPLR, SDPNAL の下調べ

SDPA の論文だけでなく SDPARA についても校正が必要なので、レフリーから指摘されていた「ほかのソフトとの比較」について予備的な下調べをしておいた。

レフリーから指摘されていたのでは、以下の4つのソフト。
[1] SDPLR http://dollar.biz.uiowa.edu/~sburer/pmwiki/pmwiki.php%3Fn=Main.SDPLR%3Faction=logout.html
[2] SDPNAL http://www.math.nus.edu.sg/~mattohkc/SDPNAL.html
[3] mprw http://www.math.uni-klu.ac.at/or/Software/software.html
[4] SDPAD http://math.sjtu.edu.cn/faculty/zw2109/pubs.html

ただし、SDPAD は SDPA とは全く独立のプログラムである。

このうち、mprw, SDPAD は対角ブロックを扱うことができないので、比較対象とはできない。
(mprw, SDPAD に圧倒的に不利な状況になってしまうため)

また、SDPNAL については、計算サーバにMatlabが入っていないため、比較が難しい。
Octave も調べてみたが、コンパイルまでは3時間かかって通したが、実行するとエラーが出て止まってしまう。(SDPT3 も Octave だとうまく動いていない)

残るは SDPNAL である。
これは C で書かれていたので、Linux で簡単にコンパイルできた。
これの実験も軽く行ってみたが、SNL から生成される問題でかなりの時間がかかる。精度が低いうちは問題ないが、精度が高くなるにつれて(反復が進むにつれて)、かなりの時間がかかる。SDPA で 10 秒以内で解く問題を 10 分以上かかるので途中でCtrl-Cで停止してしまった。

まだもう少し調べてみるとしても、これらとの比較結果は論文に載せるレベルにはならないような印象がある。

今日の作業内容:SDPARA 校正ですること確認 1h + SDP ソフト確認 4h
今日のランチ:角笛 豚の生姜焼き
明日の予測作業時間: 5h

2011年6月1日水曜日

SDPA の数値実験の集計

論文校正用の数値実験だが、まだ完全には終了していないが、とりあえず集計を始めてみた。
ある程度小さい問題は外すようにしているので、解ける問題の数は限定されているのだが、逆に1問1問はかなりの大きさのため、だいぶ時間がかかっている。

まだ集計用のpythonスクリプトが出来上がっていないが、やはり SDPA, CSDP が結構速いようだ。

今日の作業内容:SNL のプログラムの数値実験 2h + python スクリプト 2h
今日のランチ:信華園 かたやきそば
明日の予測作業時間: 4h