PDF を結合したりするときに使う pdftk だが、目次を入れ替えることもできる。
このときに、utf8 を使えば日本語でも大丈夫になる。
例えば、a.pdf の目次情報を取り出すなら、
$ pdftk a.pdf dump_data_utf8 output mokuji.txt
として mokuji.txt に取り出せる。
これをutf8 の文字コードのまま編集してセーブしたら
$ pdftk a.pdf update_info_utf8 mokuji.txt output a2.pdf
とすれば、他の内容を引き継ぎつつ、目次情報だけを更新できる。
あるいは、目次情報などが全くない PDF に対しても、
https://www.pdflabs.com/blog/export-and-import-pdf-bookmarks/
を参考にしつつ、以下のような mokuji.txt をutf8で作ればOKである。
BookmarkBegin
BookmarkTitle: 日本語目次
BookmarkLevel: 1
BookmarkPageNumber: 1
BookmarkBegin
BookmarkTitle: 目次ページ
BookmarkLevel: 2
BookmarkPageNumber: 3
2016年11月9日水曜日
2016年11月4日金曜日
Bixby がなぜ CPLEX を止めたか
Bixby がなぜ CPLEX を止めたのか、その理由が今回の OPTIMA (OPTIMA 101) に掲載されているインタビュー記事の途中に書いてあった。
このインタビューは、いろいろと書いてあるので、非常に面白い。
まだインターネットには掲載されていないけど、そのうちに
http://www.mathopt.org/Optima-Issues/optima101.pdf
にアップロードされるのだと思う。
このインタビューは、いろいろと書いてあるので、非常に面白い。
まだインターネットには掲載されていないけど、そのうちに
http://www.mathopt.org/Optima-Issues/optima101.pdf
にアップロードされるのだと思う。
2016年11月2日水曜日
Julia のエディタとして Visual Studio Code を試してみる
Julia を使うためのエディタとして Visual Studio Code を試してみた。
まず、Visual Studio Code は、
https://code.visualstudio.com/docs/?dv=winzip
から Windows 版の zip ファイルをダウンロードして、zip ファイルを展開して使ってみた。
次に Visual Studio Code を実行して、「表示」-「拡張機能」で検索できる状態にして、「julia」として検索。これで Julia のサポートが入る。
また、linter の設定として、settings.json に
"julia.validate.executablePath":"C:\\Users\\ユーザー名\\AppData\\Local\\Julia-0.4.5\\bin\\julia.exe"
を追加する。
ちなみに、パスの区切りはバックスラッシュが2個になるところに注意。
settings.json の構文を間違えると、Visual Studio Code のウィンドウの一番左下にある x マークの数字が増えるので、xマークのところをチェックすると理由を教えてくれる。
これで一通り設定は終了。
使ってみると、エディタとして、構文サポートをしてくれる。
なお、エディタとターミナルは連携しておらず、「デバッグ」-「統合ターミナル」と開いても、julia.exe が起動するわけでもないし、julia.exe のディレクトリに移動するわけでもない。
したがって、普通のエディタとコマンドプロンプトを起動して、それらのウィンドウを上下に並ぶように配置したぐらいの効果が得られる。
まず、Visual Studio Code は、
https://code.visualstudio.com/docs/?dv=winzip
から Windows 版の zip ファイルをダウンロードして、zip ファイルを展開して使ってみた。
次に Visual Studio Code を実行して、「表示」-「拡張機能」で検索できる状態にして、「julia」として検索。これで Julia のサポートが入る。
また、linter の設定として、settings.json に
"julia.validate.executablePath":"C:\\Users\\ユーザー名\\AppData\\Local\\Julia-0.4.5\\bin\\julia.exe"
を追加する。
ちなみに、パスの区切りはバックスラッシュが2個になるところに注意。
settings.json の構文を間違えると、Visual Studio Code のウィンドウの一番左下にある x マークの数字が増えるので、xマークのところをチェックすると理由を教えてくれる。
これで一通り設定は終了。
使ってみると、エディタとして、構文サポートをしてくれる。
なお、エディタとターミナルは連携しておらず、「デバッグ」-「統合ターミナル」と開いても、julia.exe が起動するわけでもないし、julia.exe のディレクトリに移動するわけでもない。
したがって、普通のエディタとコマンドプロンプトを起動して、それらのウィンドウを上下に並ぶように配置したぐらいの効果が得られる。
2016年10月31日月曜日
救急車配置問題を python で解いているサイトがあった
救急車配置問題を python で解こうとしているサイトがあった。
以下のような方向で発展できるかもしれない。
- p-median は LP に定式化できるので、今どきの LP solver なら、まず解ける。これを初期解として改良する、というのはありかもしれない。分枝限定法とも組み合わせられるのではないだろうか?
- いま思ったが、p-median に定式化するのと似たような感じで、最も時間がかかるところを最小化するのも LP になる。これも、今どきの LP solver なら、まず解けるだろう。つまり、1,2 のイイトコどりをするような解を構成できるはず。
2016年10月26日水曜日
カミフルについて
新潟に行ったときにカミフルのあたりも見てきたので、思ったことを少し書き留めておいてみる。
(やはり、どんな研究も実際の生活に役に立ってこそ意味があるので、どこかに出かけたときには、いろんな所を見れるだけ見るように歩いたりしている。)
1.場所がわかりにくい
新潟駅からで徒歩だと結構ある。というか、普通はバスを使うべき距離だった、と後で気がつく。しかしながら、バスが通る大通りの古町のあたりからだと、どこにあるのか、よくわからない。大通りからも、それなりに歩くので、途中で「道間違えたか?」と心配になって帰りそうになった。
大通りからも分かるような矢印とかほしい。
2.到着しても、ここがカミフルだって気がつかない
すでにカミフルに到着してから100メートルぐらい歩いてようやく、カミフルにすでに入っていると気がついた。例えば、通りにある柱に統一的なカラーをするとか、見た目だけで「このあたりは、何かの区域なの?」って分かるようになったらいいかと思う。個人的には、緑と青のパステルトーンにしたら似合いそうだと思うが、カミフルに引っ掛けてカラフルにするのもありだと思う。イメージとしては、ヴェネチアのパリーナみたいな感じのものが各お店の入り口にあったら、いいのでは?
3.アニメ・マンガ専門学校との共同作業があってもいいのかも
せっかくの新潟なので、このあたりで特色を出すのもいいかなと思う。例えば、東京にあるお店と同じようなお店は、もっと新潟駅の近くにあるラブラ万代でも見ることができたので、それとは被らないようにとも思うけど、こういった共同作業でいかにシナジー効果を出せるかが一筋縄ではいかないのも分かる。
今回、新潟の中でも特に「カミフルに行ってみよう」と思ったのは、マンハッタンでいうところのソーホーあるいはチェルシーのように若手の人が集まるアートエリアなのかな?と思ったところにある。
上にはいろいろと書いてはみたけど、実際に行ってみた感じでは、これからの成長力が面白いエリアになりつつあるのかも、と思っている。
2016年10月24日月曜日
arXiv のフォローを外す
今まで arXiv の math.OC カテゴリを RSS でフォローしていたが、このフォローをやめてみることにした。
理由としては、
「面白そうな論文が多すぎて、全部追いかけるのが大変になった」
というところ。
1日に15本ぐらいずつ登録されているんじゃないか、と思うので1週間に100本ぐらいになってしまい、情報過多になってしまったので、思い切ってサクッとやめてみることにしてみた。
理由としては、
「面白そうな論文が多すぎて、全部追いかけるのが大変になった」
というところ。
1日に15本ぐらいずつ登録されているんじゃないか、と思うので1週間に100本ぐらいになってしまい、情報過多になってしまったので、思い切ってサクッとやめてみることにしてみた。
2016年10月13日木曜日
Google Optimization Tools
RAMP の予稿集を見ていて、あとでチェックしてみようと思ったのが、
Google Optimization Tools
https://developers.google.com/optimization/
どうやら、ざっと見る限り、線形計画問題や整数計画問題のソルバーのインターフェース、およびナップサック問題の解法とネットワーク最適化計算が実装されているようだ。
ずっと以前にネットワーク最適化のソフトウェアを調べたときには、API などがソフトウェアごとにマチマチで、理論的研究成果がソフトウェア実装にどれだけ反映されているのか調べるのが面倒になってしまいギブアップしてしまった。
Google のソフトウェアがデファクトスタンダードになってくれば、理論的研究でも「Google Optimization Tools と比較して何パーセント性能向上」というような数値実験結果が増える方向にいくんじゃないかと思ったりする。
あと、LPやMIPについては既存ソフトウェアへのインターフェースだけ、ってところは気になるところ。既存ソフトウェアで Google が使うには十分なパフォーマンスが得られるのか。あるいは、LP, MIP は Google としては、それほど高性能である必要はないのか。どっちなんだろう。
Google Optimization Tools
https://developers.google.com/optimization/
どうやら、ざっと見る限り、線形計画問題や整数計画問題のソルバーのインターフェース、およびナップサック問題の解法とネットワーク最適化計算が実装されているようだ。
ずっと以前にネットワーク最適化のソフトウェアを調べたときには、API などがソフトウェアごとにマチマチで、理論的研究成果がソフトウェア実装にどれだけ反映されているのか調べるのが面倒になってしまいギブアップしてしまった。
Google のソフトウェアがデファクトスタンダードになってくれば、理論的研究でも「Google Optimization Tools と比較して何パーセント性能向上」というような数値実験結果が増える方向にいくんじゃないかと思ったりする。
あと、LPやMIPについては既存ソフトウェアへのインターフェースだけ、ってところは気になるところ。既存ソフトウェアで Google が使うには十分なパフォーマンスが得られるのか。あるいは、LP, MIP は Google としては、それほど高性能である必要はないのか。どっちなんだろう。
登録:
投稿 (Atom)