作成者別アーカイブ: somof

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 にリネームしたところ、
無事動くようになった。

ループイフダン USDJPY B15の整理と、売りに方向転換する目安 まとめ

USDJPYは、130円付近までループイフダンの買いで攻める!
その後は、売りに転換。

毎年のお盆の円安には間に合わなそうだけど。。。

売りに転換する時期は、また別記事で検討するとして、
「重複あり」設定、50ポジ限定にしてしまっているB15の調整が必要。

B15の証拠金計算は。。

|——–+————–+———-+————+————–+————+———-+————+—-|
| 値動き | ポジション数 | 損失合計 | 取引証拠金 | 最低必要資金 | 500万円X数 | 復帰月数 | x5必要資金 | |
|——–+————–+———-+————+————–+————+———-+————+—-|
| 5 | 33 | 79200 | 181500 | 260700 | 19 | 0.8 | 1303500 | |
| 10 | 67 | 331650 | 368500 | 700150 | 7 | 1.6 | 3500750 | |
| 11 | 73 | 394200 | 401500 | 795700 | 6 | 1.8 | 3978500 | |
| 13 | 87 | 561150 | 478500 | 1039650 | 5 | 2.1 | 5198250 | ☆ |
| 15 | 100 | 742500 | 550000 | 1292500 | 4 | 2.5 | 6462500 | |
| 17 | 113 | 949200 | 621500 | 1570700 | 3 | 2.8 | 7853500 | |
| 20 | 133 | 1316700 | 731500 | 2048200 | 2 | 3.3 | 10241000 | |
| 25 | 167 | 2079150 | 918500 | 2997650 | 2 | 4.2 | 14988250 | |
|——–+————–+———-+————+————–+————+———-+————+—-|

140円まで円安が進むとは思えないので、
127円〜130円の辺りで、売りに転換する前提なら、
この半年くらいの間は15円の値幅で充分と思う。

USDJPYでは月200回程度のループが見込めるので、
500万円原資に対する利益は以下の様になる。

|—–+——+——+——–+—-|
| X数 | 月収 | 年収 | 利回り | |
|—–+——+——+——–+—-|
| 1 | 3 | 36 | 7.2 | |
| 3 | 9 | 108 | 21.6 | |
| 4 | 12 | 144 | 28.8 | |
| 5 | 15 | 180 | 36.0 | ☆ |
| 7 | 21 | 252 | 50.4 | |
| 10 | 30 | 360 | 72.0 | |
|—–+——+——+——–+—-|

利回り25%以上なら大満足。

x5ポジの場合。
であれば、年間180万円。
今年500万円の原資では、13円の値動きまで対応できる。
ざっくり 117円〜130円と考えれば、まずは充分。

1年後には原資が700万になるとすれば、
17円の値幅、多分 113円〜130円に対応可能になる。

翌年には 110円〜130円に対応可能になる。
ここまで来れば、まずは安泰だろう。

ただし、20円の値幅になると、167ポジにもなり、
マイナススワップもバカにできなくなる。
USDJPYの金利がどこまで上るかによるかな。

まとめ。
– B15の含み損が消えたところで、5倍重複無し、ポジ制限無し設定に変更する
– 資金 500万円、月間利益15万円、年間利益180万円、利回り36% が目安
– 127円〜130円の辺りでスワップを見極めて、売りのS15に乗り換える

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

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 が元記事を壊しちゃうし。。。

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

2015年の7月末までの取引成果

2015年の7月の成果

今月の利益は55万円。
好調だった6月よりは下がったものの、目標は十分に達成できた。

6月より下った要因は、主に二つ。
– リピートイフダンの仕掛けの失敗
– 裁量取引を殆ど行なわなかったこと

特に中旬以降、値動きが少なかった割に利益が上ったのは、
市場が下落した時の仕掛け用の資金を半分投入したため。

危険水域までには余裕があるけれど、
予想以上にリスク管理がし辛くなってしまったのを反省している。

市況

米国の利上げを、今か今かと待っている間に、色んな事件が起った月

肝心の米国の経済指標は十分良いのに、
主にEUと中国の経済的危機やテロに抑えられて、
ドル高と円安が何度も押し下げられる展開だった。

でも結果的にはドル高が進んでいて、既にかなりのドル高水準。

ドル高はかなり折り込み済み状態なんじゃないか。
実際に利上げしたら、ドル円は寧ろ直ぐに反落するんじゃないか。

利上げが何回、どの位の期間で行なわれるかが問題で、
利上げフィーバー後のドル安に要警戒。

EUの経済破綻問題

ギリシャの経済破綻問題は、ユーロ脱退を回避して軟着陸したものの
債務返済の目処が立ったようには思えず、数年先送りしただけに見える。

調子が良いのはドイツだけ。
ギリシャの次にスペインとイタリアも控えていると考えれば、
ユーロ圏の問題は、長期化しそうな印象。

トルコは、選挙で市場予想外の結果になり、政治不在状態。
中央銀行の権限を抑え込んでいた大統領の権力は落ちたのは良い。
今は経済状況に問題はないけど、左翼の台頭が進んだら将来は危険。
おまけに、テロリストなどへの空爆を始めるなど、雲行きが怪しい。

中国の株バブル崩壊の始まり

中国のバブル崩壊が始まった実感が出てきた。
けれど社会国家だけに、不動産も株式市場も官製相場になっているし、
それ自体は日欧米と直接的は関係ない。
「中国はまだ大丈夫」的な報道が増えてきたので、寧ろもう逃げ時。

オセアニアの不調

対ドルで大幅下落。でも、そろそろ底値付近か。

中国に経済の関連が深いオーストラリアの方が低迷中。
資源国だけに、中長期的には持ち直すだろうけれど、
今のところ、具体的な施策や気配は見えず。

ニュージーランドが、主に乳製品価格の低下で低迷中。
経済自体が堅調なはずだけど、
このところ中央銀行が利下げを示唆していて、それを折り込んだ格好。

日本

アベノミクスはどこへやら、の7月。
5月の黒田総裁の(結果的に)円安牽制発言を、まだ引っ張っている。
株も不動産も、短期的には天井付近だろうし、買ってるのが中国人なので、
むしろオリンピック前に一度暴落しそうな雰囲気。
日銀的には良好なデフレ効果が出ているらしいが、
一般的な景気として実感できる程になはってない。

裁量取引の成果と課題

今後も裁量取引は自動売買のリスクヘッジとして行なう方針。

今月の利益は、およそ 8万円。

dyerware.com


トラリピ/ループイフダン成果

今月の利益は、およそ 47万円。

dyerware.com


ループイフダンの運用も4ヶ月目。

結果論としてトラリピよりも効率が良いことは確認したけれど、
リスク管理が細かくできないので、あまり原資を割けない。
結果、利益率はトラリピの方が良い、のが現状。

この事については、別記事で継続して検討する予定。

今後のトラリピ/ループイフダンの課題

これまで
NZD、AUD、TRY、USDの仕掛けが交互に働いてくれたので
安定した利益を上げ続けられたのだけれど、
徐々に、そういう恵まれた環境では無くなった来た様子。

dyerware.com



dyerware.com



dyerware.com



dyerware.com


dyerware.com



dyerware.com



dyerware.com



dyerware.com


特に、主力のNZDJPYとAUDJPYが不調なので、
その分自然と仕掛けが増えてしまった。

結果、
スワップ収益の比率が多くなり
リピートの利益が減っている。

これならトラリピを使う意味はなく、
スワップの良い業者に乗り換えた方が良い。

何にせよ、
トラリピのNRZJPYポジションを減らしておいた方が良さそう。

それと、
USDJPYは本格的にループイフダンへ、
TRYJPYはスワップの良い口座へ、
トラリピのポジションを他所へ移動していく。

今後の計画

今年は、
当面は円安進行を見込んで、全てクロス円で取引していたけど、
来年はドル高の天井に備えてドルストレートを加えていきたいので、
その余裕資金を作っておきたい。

ループイフダン

USDJPYに集中。
124.5円くらいになったら、仕掛けの見直し。
B15の「重複有り」を止めて、S15で両建てで攻めてみる。

トラリピ

特にNRZJPYのポジションを減らして、
資金を今の8割くらいに減らしていく。
USDJPYとZARJPYは、含み損は消えたあたりで廃止する。

くりっく口座

トラリピのTRYJPYポジション量を減らして、
代りにこちらにTRYJPYをロングする。

裁量取引

今後も、
テクニカル的に十分自信がある時だけ取引を行なう。
リスクヘッジが主な用途。

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を使っていると、不便なんだよなぁ。

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

くるくるワイドの検証 1:概念の理解

FX界で著名な「魚屋」さん開発の両建てFX手法
くるくるワイド」について検証してみた。

トラリピと組み合わせた、安全な両建ての方法を考えてみる。

くるくるワイドの特徴は、
本体の仕掛けと反対売買の細かなトラップを組み合わせること。

更に、固定ショートや複利運用を組み合わせて、
リスクを抑えつつ利益を確保する、結構ややこしい方法。

まず、本体を買いで入ることとして、どういう動作をするのか整理してみた。

レンジ相場の場合

本体の決済はなく、反対売買のトラップとスワップが損益になる。

ずっとレンジ相場なら、本体の存在意味はない。
いつか相場が上抜けか下抜けするまで、
トラップの利益を重ねつつ待つ。

多分、
これが主な利益になるんだと思う。

相場が上抜けした場合

通常なら、本体の決済で利益が出る。

でも、
その時には反対売買のトラップは含み損状態のはずなので、
まとめて決済した結果、本体の利益は相殺されてしまう。

本体とトラップのポジション量が同じなら。
決済時の利益は、本体だけの時の半分程度になってしまう。

逆を言えば、
期待に反してレンジ相場がすぐに終わってしまい、
反対売買のトラップが失敗に終ったとしても、
損害にはならない。

とも言える。

したがって、
決済を全部まとめた合計が、なるべく赤字にならないよう
出来れば利益を残すような仕掛けのバランスが望ましい。

せっかく相場が上抜けしたのに赤字で終わったのでは、
バカらしい。

かと言って、
本体の仕掛けの利益に期待するのであれば、
そもそも反対売買のトラップは邪魔なだけなので、
最初から不要だったと言うこと。

なら。
市場の上抜けで利益を得ようとはしないで、
主な利益になるべきトラップのポジション量を増やし、
本体の倍くらいとる考え方もある。

損益が相殺されるおかげで、
倍くらいまでは赤字にならない。

まぁ、利益があるに越したことは無いけど。。。

相場が下抜けした場合

これが問題。

反対売買のトラップが利益を積み重ねるが、
本体の仕掛けが含み損をかかえてしまう。

だからと言って、
本体を損切りしてしまっては、やはり意味がない。

それならば、
最初から予算の範囲内で、
反対売買のトラップだけ仕掛けていれば良い。
その方が効率的だ。

と言うことは、
下抜けした時の本体の損切りは有り得ない。

本体の仕掛けは、
何があってもロスカットされない量だけにする、
という事。

決済するのは、上抜けした時だけ!

資金を焦げつかせない範囲で、
下抜けした間の反対売買トラップを効果的に働かせるよう、
工夫するべき。

やり過ぎてトラップの数を増やし過ぎると、
いつか相場が反転した場合に、
ロスカットの危険が出てくる。

また、
相場が大きく下離れした場合に、
本体の仕掛けが大きな含み損をかかえたまま放置し、
反対売買のトラップの数を一定に保ったまま、
トラップを下値の方へとズラしていく考え方もある。

あまりに本体と離れてしまうと、
上抜けした時に、御互いを相殺して
損益0以上で全部決済することが出来なくなる。

この場合も、
いつか相場が反転して上抜けするまで、
じっと放置するしかない。

やはり資金に余裕をもっている必要がある。

下抜けした場合には、
資金に余裕を持つ以外に、
上抜けした場合の様なリスク対策はない
ということ。

ここは徹底した
自分自信のリスク管理が必要。

トラップが追従する範囲を損益分岐点から離れないとこまでに抑えるか、
トラップのポジション量を十分少なく抑える。

反対売買のトラップのポジション量は、
ここでも制限されることになる。

トラップのポジション量が少ないと、利益が出せない。
ここが矛盾。

最後は、資金力の問題だ!

あるいは、積極的に固定ショートをとって、
リスクを減らすか。。。

リスク管理のまとめ

ここまでの検証の通り、

相場が上抜けした場合には、リスク無しで全部決済し、やり直す事が出来る。

相場が下抜けした場合に、どこまで市場を追い掛けるべきか、追い掛けられるのか。
下抜けのリスクだけ考えれば良い。

その時のリスクと利益がどうなるのかが、最大の課題。

  • 資金 >> 最大費用 = 本体費用 + トラップ費用
  • 本体費用 = ((仕掛け開始価格) – (想定最安値) + 0.04 * (現在価格)) * 本体ポジション数
  • トラップ費用 = ((現在価格) – (平均価格) + 0.04 * (現在価格)) * トラップポジション数

もう一点。
重要で注意が必要な両建てのメリットとして、
ポジション数に対する証拠金が少なくて済む
というのがある。

買いと売りを比較して、
ポジション数の大きい方の証拠金で計算する証券会社が多い。

スワップが多い方が良いのか?少ない方が良いのか?

本体の仕掛けは
上抜け以外では決済しないので、長期間保持することになる。

という訳で、スワップがもらえる方向で仕掛けを作った方が得ではある。

ただ、
証券会社によっては、
マイナススワップがかなり大きいので注意は必要。

トラップのポジションを持ち越すことが少ない通貨なら、
スワップの多い方が良いので、
トラップ幅よりも十分値動きが激しくなるようにすると良いんだろう。

どの通貨に向いてそう?

当然ながら、
底値に近い通貨の方がリスクは少ない。
証拠金も少なくてすむ。

ただ、落ちる余地が少ないと、
ショートで利益を詰み上げる効率が悪い。

スワップがそんなに多くなくて下落余地があるのは。。。

ユーロ、ポンド、カナダドルあたりか。

「出口」とは?

今のところ、反対売買のトラップが失敗した時の保険の役割しか見出せていない。

出口に設定するのは、
単純に資金との兼ね合い。

もうちょっと考える事にする。

くるくるワイド、ここまでのまとめ

  • 本体の仕掛けと反対売買の細かなトラップを組み合わせる
  • 本体の仕掛けは、絶対にロスカットされない価格とポジション量の範囲を尊守するけ
  • 相場が上抜けしたら、損益分岐点の手前で全部決済する (やり直す)
  • 相場が下抜けした場合でも損切りせず、資金の範囲でトラップを追従させ続ける
  • 更に、確定利益の運用や、固定ショートなどの、積極的リスク管理を加える

ん?

これって

普通のトラリピに
反対方向の指値ポジションを加えるのと同じ?

含み損状態のまま塩漬けになりがちな、
トラリピの高値ポジションを相殺するのに使えそう。

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版のビルドに2日かかったことになる。

大昔のntemacs並ですわ。

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

あと大事なTipsを一つ。

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

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

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

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

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