カテゴリー別アーカイブ: program

Mac ImageMagick あれ？ displayで画像を表示できない

コメントをどうぞ

pythonやblenderで作った画像を表示しようと。。。

XQuartz はインストール済みだしなぁ。

ググってみたところ、ImageMagickのビルドオプションが必要らしい。
Merberickまで、そんな事したっけな？

まぁ、いいや再ビルドも簡単だし。(本当HomeBrewは素晴しい)

ありゃ？

なんか、同じバージョンがもう公開されてないんだな。
brew update して、もう一度。

なんか根本的風なところで怒られてるけど、
気にしない。

いろいろ画像周りのライブラリがアップデートした後、
無事に画像が表示されるようになったよ。

emacs-w64 が最高！ cygwinと組合せて更に最高になる話

コメントをどうぞ

emacs-w64 が最高な話。

もう1年くらい、emacs-w64 にお世話になっている。

emacs-w64 | 64-Bit GNU Emacs for MS Windows with optimization

これだと、macのHomebrewのemacsとバージョンが合わせられるので、
とても具合が良い。

最近のスナップショットバイナリは、十分安定してるし、
一番新しいリリース版よりも起動がかなり早いのが気分良い。

一般的なソフトと比べると遅いかも知れないけど。。。

emacsとしては、十分な速度だよ。本当だよ。

7/25時点のバージョンは

通常site-lispに入れるlispの類は ~/.emacs.d 以下に集めてあるので、
配布先からダウンロードして解答すれば、インストール完了。

mewやmigemoなどが呼び出すバイナリは、
cygwinの /usr/local にでも置いておけば問題なく使える。

日本語入力がSKKな人には、これで十分だろう。

gnupackにも一時期、
というかかなり長い期間お世話になっていたけど、
すっかり emacs-w64 + cygwin に復帰してしまった。

ただ。
gnupack や cygwin-emacsでも同じなのだけれど、
compile-mode からの make の起動がやたらと遅いことがある。

mewのhtmlレンダリングが異常に遅い事も良くある。
mew が w3m を呼び出すときの shell-command で躓いているらしい。

emacs の exec-path を最小限にしたり。
(C:/Windows/system32 とか、Program Files なんかも必要ないし)

たまに、bash_history を消したり。

WindowsのDNSのキャシュを削除してみたり。
コマンドプロンプトで、

と入力する。

自分自身をDNSで探さないように、LMHOSTS も設定だ。
(C:\Windows\System32\drivers\etc\hosts に書いとく)

emacsもcygwinも、
起動時やshellコマンド使用時にネットワークを見に行っている痕跡がある。
やけにキャッシュが膨れてる。

主犯は DNS だと考えてるのだけど、
再現性がイマイチだから、確証がない。

これさえ無くなれば、Windowsの開発環境には不満なくなるのだけどなぁ…

Visual Studioには、色々文句はあるけど。

cygwinが動かなくなった！プロシージャ エントリ ポイント～が見つかりません

コメントをどうぞ

emacsから一番頻繁に呼び出すマンド diff が、
この数日返事しなくなった。

emacsのshell-modeや、cygwinのbashから呼び出すと、
メッセージは何もなしで終了する。

まぁ良いか(「Windowsを再起動したらきっと直るさ…」)、
と思っていたけど、どうもそうじゃないみたい。

試しに、cmd.exeから呼び出すと、

「プロシージャ エントリ ポイント ～ ライブラリ cygwin1.dll から見つかりませんでした」

とか言ってるし。

心当たりはある。
この間 cygwin をアップデートした時に、何か怒られてた。

インストール先の c:\cygwin\bin を覗くと、
cygwin1.dll と cygwin1.dll.new のdllが二つある。

これが問題らしい。
cygwin1.dllのアップデートに失敗していたらしい。

やれやれ。

cygwin1.dll を削除して、
cygwin1.dll.new を cygwin1.dll にリネームしたところ、
無事動くようになった。

wordpressのプラグインを作ってみる org-modeのテーブルをそのまま使いたい！

2件の返信

org-modeで書いたテーブル

みたいなのを、
blogに書くときにプラグインでHTMLのtableに加工したい。

雰囲気、こんなので良いみたい。

これを /wp-content/plugins/ に置く。

ん？
こんなエラーが出たぞ。

あ〜
WordPressの画面からは、ちゃんとZIPに固めてからでないと
アップロードできないみたいだ。

しょうがないので、サーバーに直接アップロードしよう。

おー。 動いた動いた。

↓こんな感じになった。

|——+——+————|
| 名前 | 価格 | 日付 |
|——+——+————|
| あれ | 100 | 2015/01/01 |
| これ | 1000 | 2015/02/01 |
| それ | 99 | 2015/03/01 |
|——+——+————|

|——–+——|
| 場所 | 距離 |
|——–+——|
| あっち | 100 |
| そっち | 1000 |
| こっち | 99 |
| ？？ | 99 |
|——–+——|

変換する関数自体は通勤時間の間に完成したのだけど、
なんか、いろいろ他のプラグインとかち合っていて、
サーバー上で動くまで半日かかってしまった。

スタイルは、他のプラグインに取られたままだし。

記事を編集し直そうとすると、 WP-MarkDown が元記事を壊しちゃうし。。。

案外簡単にプラグインをつくれることは分かったけど、
人に公開しようと思ったら、
そうとう検証に時間をかける必要がありそうだなぁ。これは

OpenCV 3.0 でハマった事

コメントをどうぞ

割りと軽いノリでOpenCV 3.0 に移行した結果、
あれこれハマった事や面倒だった事のメモ。

ビルドの問題に関しては、
cudaを使ってるのが主な原因の様な気がする。

contribでビルドできないmoduleが、いくつもある

gitでも3.00のアーカイブでも同様。
opencv-text や opencv-tracking は、試したかった機能なので残念。

cudaを使わなければビルドできてた様に覚えているし、
ビルドエラーは見れば直ぐに修正できそうな感じなので、
早晩対応されると思う。

pyton-bindingがビルドできない！

gitでも3.00のアーカイブでも同様。
OpenCV3のウリの一つだっただけに、これは本当に残念。

CV_～の定数を、cv::〜に置き換える

CV_～の定数は、まだ使えるみたいだけど
そろそろcv::～ のenumに書き換えた方が良い
CV_BGR2GRAY → cv::COLOR_BGR2GRAY とか

でも、どれが移行出来るのかとか、一覧できないので
順次、気がついたソースから修正中。

OpenCV 1.x 風マクロの置き換え

OpenCV1 APIからC++風APIに書き換えるのは、地味に面倒。
やっぱり、動いたり動かなかったりするので
ビルドしてみてエラーになった物から修正中。

とりあえず、VideoCapture や VideoWriter かな。
あと、画像処理のAPIのドキュメントが無かったりするので、
何となくエラーが出ないように修正して動かしている状況。
動いてはいるみたいだけど。

IplImage * と cv::Mat を暗黙で変換してくれなくなった

コンストラクタで暗黙変換しなくなったのが一番影響大きいかな。
そもそも、もう IplImage は使わない方が良いんだろうけど、
プロジェクト単位で見ると、地味に修正箇所が多い。

意を決っして全部修正しているところ。

どうしても IplImage を使いたいところは

とかしてる。

CV_RGB から cv::Scalar に置き換え

RGBの順番が変わるので要注意。

色指定はCV_RGB が便利なんだけど、
中途半端はイヤなので、cv::Scalar に修正中。
揃えるのも大事。

Macはどうしよう…

こんな状態なので、Macの方は暫く様子見の予定。
現状では Homebrew でサクっと移行できるワケじゃなさそうだし。

C/C++は、プロジェクト毎にライブラリを管理すれば良いけど、
pythonの場合は、WindowsとMacでバージョンが違うと不便なので。

WordPress WP-Markdown plugin を入れてみた

コメントをどうぞ

プラグインの新規追加で「WP-Markdown」を検索してインストールし、 ダッシュボード＞設定＞投稿設定で有効にするだけ。

うちで使いそうな Markdown は、こんな感じ。 Markdownリファレンス

強調

斜字にしたいテキスト 強調したいテキスト

リンク

［リンクをはるテキスト］(http://url.xxx/)

見出し

H1見出し ## H2見出し ### H3見出し #### H4見出し ##### H5見出し ###### H6見出し

コード表記

先頭に半角スペースを4つを入れる、チルダ3つで囲む、 短かい分ならシングルコーテーションで挟むと コードとして扱われます。 これは便利かも。

リスト

項目を＊、−、＋、数字で始めると、リストになります。

  • python
  • OpenCV
  • C/C++
  1. Mac
  2. Windows

使ってみた感触

それにしても。

JP Markdownもそうだったけど。 何故、見出し記号が＃なのか。＊に変えられないのか。。。

よりによってコメント記号の＃にしなくても良いじゃないか。 普段org-modeやrstを使っていると、不便なんだよなぁ。

これだけ設定で変えられると嬉しいんだけど。

Windows版 OpenCV 3.0 のコンパイル

コメントをどうぞ

必要にかられてOpenCVの機械学習を使い始めたのだけど、
ひどく遅くて仕事にならない。

配布されたライブラリだと
シングルタスクでしか動かないらしい。

12コアのCPUを積んでるのに、1コアしか使わないなんて…

そこで。
TBBやらCUDAやらを有効にして再ビルドすることにしたのだけど、
機械学習関係は最新版が色々良いらしい。。。

との風の噂を信じて。
バージョンを 2.4.11から3.0へバージョンアップ！

リリースしたての 3.0.0。
マイナーバージョンが0ってのが、身の危険を感じさせてくれます。

とは言え
どうせビルドするなら、
トラブル解決ついでに新しいAPIの流儀を覚えるのも悪くない。
いいかげん、手持ちのプロジェクトに残ってる OpenCV1の名残を消したいし。

ビルドの基本的な作業は
アーカイブ展開 → cmake → VisualStudio でビルド
という手順。

なのだけど、
リリースホヤホヤの新作だけに、
オプション全部入りにしておいて終夜稼動でビルド。
翌朝 にっこり。

と言う訳には行かない。

今回必要なオプションは
CUDA 5.5、TBB、EIGEN、contribのmoduleのいくつか。

opencv3.0とcontribのアーカイブはgitからクローンし、
TBBとEIGENは最新のアーカイブを取ってくる。

CUDAは既にインストール済み。

CUDAを含めたOpenCVのビルドにはべらぼうな時間がかかるので、
まず最初にTBBとEIGENだけ有効にしたCPUだけの環境をインストールした。

このOpenCV3環境を使って、
手元のプロジェクトをOpenCV3対応に修正する作業の裏で、
CUDAを有効にした環境のビルド作業を続ける。

でもでも。
CUDAを組込む前から、
既に恐しく高速化された関数群の恩恵に感動！
TBBの影響かな？爆速です。

中の方々に感謝です。

が、
このgit版のソースでは、エラーが多くてCUDAを組み込んだビルド諦めた。

中の方々に感謝しつつ、
CUDA版は3.0リリース日に固められていたアーカイブを
ダウンロードして使うことに。

contribのmoduleでソースの修正が必要そうなものは、
CMake でチェックを外してスキップすることにし、
再びビルド。

待つこと半日。
ビルドが遅いのは、VisualStudio版のcudaのコンパイラnvccのせい。
Linux版のnvccは速いのだけどね。本当、遅い。

3度ほど、この作業を繰り返して
必要なライブラリ群は、ビルドとインストールが完了した。

仕事しながら裏で作業していたとは言え、
全部合わせるとcuda版のビルドに２日かかったことになる。

大昔のntemacs並ですわ。

悲しいのは
python用のbindingがビルドできなかった事。
まぁ、pythonはメインの仕事には使わないんだけど。

あと大事なTipsを一つ。

cmakeでPATHを新たに指定するとき、
PATHにバックスラッシュを含んでいると、
エスケープ記号と間違われて、後でコンパイルエラーになる。

結構後で分かるので、時間のロスが悲しいよ。

スラッシュで置き換えれば、問題なくコンパイルできる。
2.4.11の時は、困った記憶がないんだけどな。

それと、ソースファイルの文字コードでワーニングがしこたま出るけど、
まさか日本語を直書きしている訳ではないと思うので、今回はスルー。

リビジョンが10回くらい上がったら、もう一回ビルドだ！

続・アイネット証券のループイフダンの落とし穴＆重複有り設定に注意！

コメントをどうぞ

稼ぎ頭の USDJPY B15_B15 が止まっていた！

その原因解明編。

USDJPY B15_B15 を仕掛けたのは、1ドル 125.582円のとき。

慎重に考えていれば、 S15_15 を選んだかも知れないけど、
この時はトラリピとの比較が目的だったので BUY にしたんだと思う。

で、どうやら、ポジション数を50で制限する設定を加えていたらしい。(覚えてないけど)

それなら、0.15*50 = 7.5 円の変動までは対応できたはずだから、
118.0 までの下落までは追従したはず。

ところが。
実際のB15のポジションは 122.751円、
たったの 2.8 円の値幅で、ポジション数50の制限にかかってしまっていた。

当初見込の1/3の値幅で制限にひっかかった訳。

つまり、「重複有り設定」のために想定の3倍のポジションをとっていたと言うこと。
やたらと利益が多かった訳も、これで合点がいった。

これは想像よりも、かなり大きな誤差。
その上、取引履歴を見てみても、成行発注だけに、全く実態がつかめない。

USDJPY B25_25 の仕掛けの方はと言うと、
現在13ポジション(=想定値幅3円)で、その値幅は2.95円 (122.772 〜 125.722)。
ほぼピッタリ、当初の想定通り。
B15より少ないとは言え、このままの調子で行けば、年間30%の利益率を達成できる勢い。

B15_15(重複有り設定) の利益率が異常だったということ。
利益が多いのは良いことだけど、
想定と3倍も違ってしまうのでは、リスク管理もできないので危険すぎる。

で。
これまでのまとめ。

重複有り設定なら、ループイフダンの利益額は、トラリピ強欲設定の倍以上を見込める。
その代りに、リスクは3倍程度に上がる可能性がある上に、事実上リスク管理が出来ない。

「重複有り」の爆発力は魅力的だけど、
ループイフダンは「重複無し設定」が正しい選択の様だ。

巷で言われる様に、手数料の差が結構あるので、
同じ条件なら、トラリピよりループイフダンの方が利益率は高いのは正しいと思う。

ただ、同じ発注条件で比較しても、実態に則した比較の方法とは良いにくい。
それぞれに適した使い方があるのだから、それぞれのメリットを活かした上で比較した。

今後、
重複無し設定で、トラリピとループイフダンの現実的な比較を行ないたいと思う。

でも。
USDJPY B15_15の含み損が無くなるまで、おあずけ。

python pandas データフレームに空のシリースを追加すると、またしても警告が…

コメントをどうぞ

またしても SettingWithCopyWarning の警告が出た。

既にあるデータフレーム(シリーズ)に、空の新しいシリーズを作ってすぐ追加したい場合に。

こんな警告が出てくる。

便利APIやアクセサ経由でデータフレームを操作した時に出た警告と同じだけど、

今度は、自分のコード自体がエラーの発生箇所になってるけど、
指定されたURLを覗いてみると、原因は以前の時と同じみたいだ。

pythonの中で二度呼びされるから、予期しない結果になるかも知れないよ、とのこと。

Since the chained indexing is 2 calls, it is possible that either call may return a copy of the data because of the way it is sliced. Thus when setting, you are actually setting a copy, and not the original frame data. It is impossible for pandas to figure this out because their are 2 separate python operations that are not connected.

The SettingWithCopy warning is a ‘heuristic’ to detect this (meaning it tends to catch most cases but is simply a lightweight check). Figuring this out for real is way complicated.

The .loc operation is a single python operation, and thus can select a slice (which still may be a copy), but allows pandas to assign that slice back into the frame after it is modified, thus setting the values as you would think.

The reason for having the SettingWithCopy warning is this. Sometimes when you slice an array you will simply get a view back, which means you can set it no problem. However, even a single dtyped array can generate a copy if it is sliced in a particular way. A multi-dtyped DataFrame (meaning it has say float and object data), will almost always yield a copy. Whether a view is created is dependent on the memory layout of the array.

0のリストを二つ作ったつもりが、一つしか作られてないって事なんでしょね。

ちなみに初期値をあたえないで、こう書くと、警告は出ない。

けど、NaNで都合が悪い場合は、改めて初期値を入れてやんなきゃならない。

MacBook Pro Retina 2015の環境設定

コメントをどうぞ

結局、2015年に新調したのは「新しいMacBook」じゃなくて、
MacBook Pro Retina 15 2015 でした。

普段持ち歩いている MacBook Air 2014 の出来が良過ぎて、
新しいMacBookに買い替えるまでには至りませんでした。

12インチRetinaディスプレイが手に入る代わりに、
Airのバッテリー持ちと計算速度と20万円が無くなるのはチョット。。。

そして。
愛用していた2012のMacBook Pro Retina 15にはBootCampを使って、
嫁さんのWindowsPCに化かしました。

さて。
会社から帰宅したら、新しい MacBook Pro Retina 15が届いていたので
早速環境整備です。

最初の電源投入時にあった10個弱のアップデートを更新しつつ、
並行してChromeとGoogle日本語入力、Dropboxをインストール。

次に、 Homebrew をインストールして、
最新のEmacsをビルドします。

ビルドが終わる頃には、Dropbox にある.emacs.d と同期完了するので、
いつもの emacs が使えるようになります。

ショートカットキーを設定するため、
下記の通り Emacs.appをApplicationに登録しておきます。

Chrome/ターミナル/Emacsを、以前と同じキーボードショートカットキーに登録して、
使い勝手は、ほぼ2012 MBPRと同等になりました。

キーボードショートカットアプリに、今回は BetterTouchTool を使ってみます。
キーボード以外にトラックパッドなどにも色々な機能が追加できる様です。
使い勝手が良くなれば、シンプルな Spark.app に戻すかも知れません。

(結局、あとで Spark.app に戻しました)

最後に、最近多用しているpythonとライブラリ類を追加します。

pythonは、Macの標準ではなく、Homebrewのpython2.7を使います。
それと直ぐに必要になるライブラリをインストールしておきます。

Dropboxに開発中のソースとホームディレクトリの設定ファイルが全て入れてあるので、
これで一先ず、以前と同様の開発環境のできあがりです。

この後、MAMP/Jenkinsを整備して、テスト環境を作り直します。

今迄は諸般の事情でJenkinsをユーザー権限の範囲で使う必要があり、
ゴニョゴニョ設定していたけど、今回からはスッキリ標準的な構成にしようと思います。