2015-05-15

Macの日本語IME(少なくともgoogleIME)は直前に選択していたキーボードの影響を受ける

タイトルの通りなんだけど、気づかないとかなりつらいのでメモだけしておく…(自分がそうだったので)

前提として、使ってるのは USキーボードの MacBook Pro on OS X 10.9.5.

たとえば google日本語IME と U. S. だけを行き来していれば何も問題はない。ここで自分の場合はスウェーデン語を追加した。すると、直前にスウェーデン語を使っていて google IME に切り替えた時に、ローマ字入力がおかしくなる。というかスウェーデン語のキーボードが記憶されているようで、いつものローマ字入力ができない、というのが正しそう。とにかく、一度 US にしてから再度 google IME にすれば直る。

2015-01-21

linux で連番ファイルの処理 → seq と xargs を使ってみた

Q. 00001.dat, 00002.dat, ... とめっちゃたくさんある連番ファイルのうち、 00100.dat から 00200.dat までだけを rm (など、何でもいいが)したい

A. $ seq -f "%05g.dat" 100 200 | xargs -n1 -I{} rm {}


参考:
xargs → 一つ前のエントリ
seq → http://dharry.hatenablog.com/entry/20110426/1303825422


 僕のシェル力ではまだ mod(100) みたいなのはわからん…まぁ必要もない…あるな。たとえば「1, 3, 5, ... だけを残してそれらを 1, 2, .. にリネーム」とかはしたいことあるわ。まぁそっちはおいおい調べよう。

2015-01-20

コマンドライン (linux, cygwin) での個別ファイルのバッチ圧縮解凍 → xargs使う

Windows なら explzh でもできるけど、linux 計算機上で圧縮してサイズ縮めてからローカルに転送したいので。

ファイル一個なら
http://qiita.com/wnoguchi/items/cb0fa7c11b119e96f1e5
http://tukaikta.blog135.fc2.com/blog-entry-223.html
にある通り。

でも今は、複数のファイルを個別に、だがバッチで一括して圧縮したい。
⇒ http://extrea.hatenablog.com/entry/2012/10/14/234932 コレダ!

噂に聞いていた xargs を使うのか。
Man page of xargs によると -i は非推奨らしいので、 -I{} とした方がいいようだが、基本的にはこれでよいようだ。あとちょっとググると ls でなく find 利用が多いようだが、自分の場合はまぁ ls と *.拡張子で間に合ってるのでまぁいいや。

一応自分用にメモしておく。いずれも、「元のファイルは消す」設定なので要注意。(xargs の中でリダイレクト > を使うのがうまくできなかったのもある…あとで調べるか)

UPDATE 2015-01-21

すでに同名のファイルがある場合、 tar なら黙って上書きする(したくない場合は -k オプション)が gzip, bzip2 はお行儀よく(?)上書きしない。これは困るので、 -f オプションを追加した。

UPDATE 2015-01-24

バックグラウンドに行ってくれないとうざいので末尾に & を追加した。

圧縮

対象とするファイル: 0001.xyz, 0002.xyz, ...のような拡張子のもの全て

$ ls *.xyz | xargs -n1 -I{} tar cfvz {}.tar.gz {} &

意味としては、パイプの左で 0001.xyz が出力され、それが xargs に渡される、というか要は tar での {} の部分にこれが代入される。 -n1 の部分が「ファイルを個別に」になっている。

…というか、ファイルを個別に、なので tar いらなくね?→やってみた

$ ls *.xyz | xargs -n1 -I{} gzip -f {} &

でも同じことだった。出てくるファイルが .tar.gz か .gz かの違いだけ。あ、リネームしたい場合は tar の方がいいのか。

あるいは圧縮率高いけど遅い bzip2 で

$ ls *.xyz | xargs -n1 -I{} tar cfvj {}.tar.bz2 {} &
$ ls *.xyz | xargs -n1 -I{} bzip2 -f {} &

こっちのほうがいいかも。今使ってるデータだと倍くらい違うことがある。


UPDATE 2015-01-24

bzip2 遅いわ。遅さが気になる用途なら gzip の方がいいし、気にならない場合ならむしろ xz の方がいいな。圧縮は遅くなるけど解凍は bzip2 より速いらしいし。
使い方は http://tukaikta.blog135.fc2.com/blog-entry-223.html

解凍

.tar.gz, .tar.bz2 なら

$ ls *.xyz.tar.gz | xargs -n1 -I{} tar xfvz &
$ ls *.xyz.tar.bz2 | xargs -n1 -I{} tar xfvj &

.gz, .bz2 のみなら

$ ls *.xyz.gz | xargs -n1 -I{} gzip -d {} &
$ ls *.xyz.bz2 | xargs -n1 -I{} bzip2 -d {} &

でOK.

UPDATE 2015-02-19

結局全部 xz にすることにした。ので解凍は

$ ls *.xz | xargs -n1 -I{} xz -dk {} &

てことになった。-k は「元ファイルも残す」(keep) の意味。その他オプションについては http://tukaikta.blog135.fc2.com/blog-entry-223.html#xz 参照。Windows でも cygwin からこれやった方が explzh よりも余計なダイアログとかでないので楽だわ。

そのほか

試しに Poderosa から cygwin でやってみたら問題なく動作した。まぁディレクトリの移動が面倒だけど、たぶん explzh 使うより動作が軽い(気がする)。

xargs には -P (parallel?) オプションがあって並列実行もできるようなのだけれど、「一つのファイルを寄ってたかって圧縮」したいのではなくて、「適当に4つずつなど圧縮していきたい」ので、やりたはまだわからない。

2015-01-18

Fortran でのバイナリ (unformatted, binary) の扱いについてのメモ

前提

FIELDVIEW で Plot3D の binary 読み込む というのを昨日書いた。だけど、Plot3D だけじゃなくて、ファイルサイズ削減のため Fortran でバイナリ形式で読み書きしたい。ただそもそも unformatted まわりがよくわからん…。たとえば form="unformatted" と form="binary" はどう違うのか?あまり変わらないという話もある(参考1, 参考2)けど、じゃあ多少は違うのだろうか?とか。

そこで、ググって調べつつテストコード書いてバイナリエディタで中身開いて確認してみた。結果、ちょっとずつわかってきた。今のところの理解をメモしておく。

なお character についてはとりあえず考えていない。 integer, real(4), real(8) のみ。バイトオーダーも気にしてない。

比較

まずバイナリ形式を扱うための open にはいくつかの形式がある。恐らく次の4種類?
  • open( ..., form="unformatted", access="sequential")
  • open( ..., form="unformatted", access="direct", recl=数字) ← position 指定不可。 ifort での場合コンパイル時は "-assume byterecl" を付けるべし
  • open( ..., form="unformatted", access="stream") ← Fortran 2003 以降(gfortran, g95, ifort 全部大丈夫そう。よほど古くなければ)
  • open( ..., form="binary") ← ifort 独自仕様で stream と同義
一番基本的なのが sequential のようだが、これだと一行というか ( a(i), i=1,10 ) みたいな塊の前後にヘッダとフッタが自動的に挿入される。したがって縦に長いというか do i=1,1000000 みたいに改行しまくるとヘッダとフッタ分でサイズが増える。

direct はそういうことはないが、読み書き位置を read(m_num, rec=i) みたいに一々指定しないといけないようで、小さいデータならいいが複雑になるとミスりそうでちょっと怖い。あと
positon="append" を付けるとコンパイルの時点で怒られる。どうやら、 position="append" は direct や stream だとできなそう。それから、integer, single precision, double precision が混在するときは、一番大きな double precision に合わせて record という固定長の領域(?よくわかってないがそんなイメージ)を確保しないといけないっぽい。そうすると integer, single precision の部分はデータは半分だけで残りは0でフィルされてだいぶ無駄になってるみたいだ。

stream は新しいやり方…というか C/C++ に合わせたい( の stream?)とかのモチベーションで新しく出てきたやつらしい。固定長の record base じゃないので変数の型に合わせて必要なサイズずつ入っていく。型が混在する場合はファイルサイズの節約になる。また、読むときは read(m_num, posipos=i) みたいに指定するようで、direct ほどでなくとも頭は使いそうだが、書き出しの際は rec= なんてのはないので、direct よりも楽。なお http://www.star.le.ac.uk/~cgp/streamIO.html によると formatted でも使えるとのこと。

結論

というわけで、なるべく横長にして sequential を使うか、stream かのいずれかにしようと思う。

参考リンク

一部は本文中と重複してる。

テストに使ったコード

https://docs.google.com/document/d/1m9iOSI26PJcyJEZuVSuMiwTc0miMOMwMwp5prEAqFjc/edit?usp=sharing
(google docs が開くのでコピペして保存したら使えると思う)


UPDATE 2015-01-19

実際に actionaccess="sequential" にして、横に長く write(iunit) ( a(i), i=1,4800000 ) みたいにしたやつと do i=1,4800000; write(iunit) a(i); enddo にしたやつを比較すると、前者は後者の 1/3 くらいのサイズになった。

また、テキスト (form="formatted") 形式についても今まであまり気にしていなかったがこの違いはあり、やはり横に長くした方が 1/3 くらいになる。

一例として、4800000 個の単精度データを吐き出してみた。テキストの場合、フォーマットは 1x,es13.6 にしてみた。単にバイナリとあるのは form="unformatted", actionaccess="sequential" のこと。

  • テキスト(縦長): 68,688 KB
  • テキスト(横長): 24,403 KB
  • バイナリ(縦長): 56,250 KB
  • バイナリ(横長): 18,751 KB
  • バイナリ (actionaccess="stream"): 18750 KB
まずわかるのは actionaccess="stream" (ifort でいう form="binary")は横長の action="sequential" とほとんど変わらない、ということ。

それに、横長テキストもかなり小さいので、こっちでも別にいいかなと思える。…が、横長テキストってフォーマット指定時に繰り返し回数のところに変数が使えないもんだから、横に並ぶデータの個数をハードコーディングしないとダメなんだよね(…たぶん。違ってたら教えて…)。どういうことかというと…たとえばデータの個数が imax = 4800000 だったとして、

  write(iunit, "(imax(1x,es13.6))") ( a(i), i=1,imax)

とはできないので、

  write(iunit, "(4800000(1x,es13.6))") ( a(i), i=1,imax)

とするしかない(ようだ)、ということ。

再度結論

したがって、再度結論をまとめると、
  • 中身を確認したいような場合: 縦長テキスト形式(横長だと重すぎて開けなくて意味ない)
  • 後で流れ場の処理とかしたいから出しとく、みたいなの: 横長のバイナリ (actionaccess="sequential")
  • FV用の Plot3D: バイナリ (actionaccess="stream")
としようと思う。


(最終更新 16:51)
(2015-10-10 typoを修正: action→access)

2015-01-17

FIELDVIEW で Plot3D の binary 読み込む

いちおうメモしとく

FV12.3 の reference manual pdf には "Binary files can only be written and read using C." とあって、 Fortran の場合は form="unformatted" にしろという感じ。だが、実際にやってみたらなぜかそっちだとうまくいかず、 form="binary" にして、読み込み時に Binary を選択するとうまくいった。なお精度は real( foo, 4 ) で単精度に落としている。可視化だから倍精度の意味ないし。ファイルサイズ半分くらいになった。今まで倍精度で書き出してたのアホすぎ…。

FV13 の Auto-Detect format も、もちろん問題なし。

計算環境は CentOS 6 (64 bit) + ifort 12 or 13 (x86_64). FV は Win.

2015-01-08

mintty を Win 8.1 にインストール (自分用メモ)

いろいろなサイト・ブログに書いてるんだけど自分の環境だとつまづいたりすることがあったのでメモ。
以下、作業用ディレクトリを C:\wksp にするという前提。ふつうは D とか E にすると思うのでそこは適宜読み替えてほしい。


[インストール]
http://sourceforge.jp/projects/mingw/
からダウンロードし、インストールする。

mingw-get-setup.exe を右クリックし、管理者として実行(一般ユーザでもよいかも)。

最初の画面は Install をクリック。

次の画面で、Program shortcuts for launching the ...
というところが、「... for all users *...」になっていることを確認する。

Basic Setup から,

mingw32-base
mingw32-gcc-fortran
mingw-gcc-g++
msys-base (← インストール忘れた場合は後でこれだけ追加インストールできる)
にチェック。

Apply Changes でインストール開始。



[シェル (mintty) のインストール]
ここからは
http://zarari.hatenablog.com/entry/2013/08/22/235819
を参照。
(他にも、
http://idonosoko.blogspot.jp/2011/12/mintty.html
https://sites.google.com/a/machizawa.org/pc/mingw
なども参考にする)

まず
C:\MinGW\msys\1.0
にある msys.bat をダブルクリックして起動する(これが記事中の「MinGW Shell」に相当するようだ)。

記事にある通り、
$ mingw-get update
$ mingw-get upgrade
$ mingw-get install mintty
を行う。

mintty というのがいい感じのシェル。記事で紹介されている openssh は入れなくていい。


[環境変数の設定]
PATH と HOME という環境変数を設定する。

コンピュータを右クリック > プロパティ(もしくはWindowsキー+Pause/Breakキー) > 左の方にある「システムの詳細設定」 > 下の方にある「環境変数」
「システム環境変数」の「新規」をクリックし(あるいはすでにある場合は、半角セミコロンの後に追加する)

変数名を PATH 変数値を C:\MinGW\bin としてOK
また、
変数名を HOME 変数値を C:\wksp としてOK

とする。


[mintty の設定]
C:\MinGW\msys\1.0\bin

に mintty.exe があるので、右クリックして、「タスクバーにピン止めする」をクリック。

今度はタスクバーのアイコンを右クリックし、さらにポップアップ上の「Terminal」という文字を右クリックして、「プロパティ」を開く。
そこで、記事にあるように「リンク先」のところに「 -」(半角スペースとハイフン)を追加する。
作業フォルダは変えなくても多分大丈夫(HOMEが優先されるっぽい)が、念のため「C:\wksp」にしておく。

シェルが見づらいので、シェル上の適当な場所を右クリックして、一番下の Options... を選択。
まず Text の Font で、「Select ...」からフォントを設定する。
デフォルトでもいいが、Inconsolata や Consolas, DejaVu Sans Mono などがあれば変えると良い。
また、フォントサイズも12などにするとよい。
ただし、Ctrlとマウスホイールで自由に変えられるので特に指定しなくてもいい。

また、好みではあるが、Options の上の Looks で、Transparency を Med. にセットするとなかなかよい。


[作動確認]
mintty 上で
$ ls -la
$ g++
あたりが通ることを確認する。