ラブシェール資産運用法の統計的検証

Alexander Dubovik | 15 10月, 2015

三つの嘘　－　嘘、図々しい嘘、そして統計

概論

休日にふらふらとネットサーフィンをしていると、今まで聞いたことがない資産運用法を見つけた。ラブシェール法、または削除メソッドという。(ラブシェール法を利用したForex Vacuum Cleaner System). 実際、このシステムはマーチンゲールの変わり種で、つまり負けの後にはかけ金をあげ、勝ちの後には最小限のかけ金にする。しかし、これはオリジナルのマーチンゲールよりも攻撃的な変わり種ではない、というのもかけ金は2倍にアップするのではなく、一定の額だからだ。

では、ここから非常に僕の興味を引いたこのシステムの性能の記述に、コメントを加えていくことにする。

実際、僕が見つけたソースでも、もし負けに対して勝ちが同等で、50％の勝ちが見込める（もしくは「33％以上」でさえも）システムを採用するなら、ラブシェール法は簡単にそこから利益を生み出すと断言している。もし僕たちに代わってプラス領域に引き寄せてくれる方法が考えられているなら、何の為にプラスの期待値を持つシステムを探すのか？だって、例えば47％の勝率のシステムを作るなんて簡単だし・・・

ではラブシェール法がどのようにかけ金を変えることを提案しているのか見てみよう。

最少のかけ金、ということで1にする。勝ちの場合には、特に面白いことは起こらない。かけ金はそのまま残って、取引残高が少し成長するだけだ。

しかし、負けの場合、かけ金は2まで1つ大きくなる。そして、リストに負けたかけ金をメモしていく。

-1

上げたかけ金の勝ちの場合、リストにメモする。

-1 2

それから、2つの数字を消す、というのは僕たちは自分の負けを戻したからだ。（つまり、2つのかけ金からのパターンの結果においては、残高は1増えたのだ）

もっと長い期間の負けパターンを見てみよう。

-1

かけ金を2にする。また負け。

-1 -2

かけ金を3にする。また負け。

-1 -2 -3

かけ金を4にする。また負け。

-1 -2 -3 -4

かけ金を5にする。また負け。

-1 -2 -3 -4 -5

かけ金を6にする。また負け。

-1 -2 -3 -4 -5 -6

かけ金を7にする、するとやっと勝つ。

-1 -2 -3 -4 -5 -6 +7

この後で「-1」、「-6」そして「+7」を消す。なぜなら、この勝ちで二つの負けを相殺するからだ。次のかけ金は表に残った初めと最後の額と同じにする、つまり前回と同じ7だ。勝ちの場合

-2 -3 -4 -5 +7
「-2」、「-5」そして「+7」を消す。もう一度掛け金を表に残った最初と最後の額と同等にする、つまり前回の7だ。（他のソースでは、勝ちの場合にただの『ゼロ』にならないように、さらにこれに1を加えると書かれていることもあるが、とはいっても最小限の利益だろう）勝ちの場合
-3 -4 +7

表から全ての数字をけす、なぜなら僕たちは負けを取り返したからだ。

中間段階で負けを被る場合、またこの負けの割合を同様に表に書き込んで、表の端の２つの数字と同等の金額をかける必要がある。

さて、では僕たちに何が起こったか見てみよう。

  1. 本当に、6つの負けの回を、全部で３つの勝ちので相殺することができた。（本当に回で相殺したわけだが、このことについては後ほど）一見、システムは簡単に乾いたところから水を出せるもののように思える。

  2. 掛け金の増大は、このような回で初掛金の64倍になったであろうオリジナルのマーチンゲールよりもかなりゆっくりだ。

  3. デポジットの失敗の合計は（かけ金の額）引用した例では全部で21で、同じ時期にオリジナルのマーチンゲールでは63だった。

  4. 簡単な計算だと、初掛金の額がデポジットの1％の場合にデポジットを失うのは、続けて13回負けた場合で、また初掛金の額がデポジットの0.1％の場合は、続けて44回負けた場合だ。（ここでは手をこすって、「どこでこんなのお目にかかれる－50：50のチャンスのなかで44の損失とか？！これは数兆分の1だ!僕の頭の上に隕石が落ちてくることの方が確立が高いだろう！こんな負けの確率なら絶対に使わなければ！」などなどと言いたくなる）

  5. 公開資料にはオリジナルのマーチンゲール法の『奇跡の効果』は無いというたくさんの根拠があって、確かにこれを確認するのは、紙のリストとペンがあればさほど難しくはない。でもラブシェール法については、僕は一つの検証も見つけることはできなかった。

  6. かけ金のシステムは、『紙の上の』最終期待値の計算がとても難しくて、すごくこんがらがって見える。

しかしながら、僕たちの失敗パターンからの脱出プロセスに戻ってみよう。6回連続の負けの後で、僕たちは全部で、3ではなく、2の勝ちを得たとしよう。では、紙の上には次のことが書かれる。

-3 -4

かけ金7、そしてここで待ち望む勝ちの代わりに、負けを得たとする。

-3 -4 -7
かけ金10（負けから負けへとかけ金はすでに1増えて、3に増えるよりも十分賢明で安全なように見えることに気づいてもらいたい）そしてまた負け。
-3 -4 -7 -10

もうかけ金は13だ。

ということは、完全な相殺までに繰り返し負けを被る場合、システムはかけ金を１よりも多いかけ金に増やすよう指示してくるのだ。そして、ほら、ここで僕たちのデポジットには本当の危険が待ち伏せているかもしれなく、つまり失敗からの脱出の為には、僕たちには正に勝ちのパターンが必要なのだ。前と同じように紙の上で期待値を計算するアイディアはとても難しく、少なくともとても退屈に見えるけど・・・。

みんなはこのシステムで何ができるか興味があるかな？僕はとても興味があるよ。


課題の提起、それは何をどんな方法で確かめるかだ

一番の主要な問題、そして僕たちが探す答えは、それはラブシェール資産運用法が期待値を、特にプラスの方向に動かす能力（もしくは無能力）だ。勿論、勝ちの際の勝率33％は十分だと言える＝負けにはファンタジーに聞こえる、しかし、せめて49％もしくは50％の勝率なら十分か？もしそうでないなら、何かしらの強みがラブシェール法にはあるのだろうか？

検証は統計でもって行う、つまりMQLのプログラムに書く必要がある。（ここではMQL4を使う。MQL5はまだマスターしていないので）そしてプログラムに数百万の取引をさせて、数千のデポジットを出させる。僕たちはお財布に害なく結果を見て、分析するのだ。万が一プログラムが稼いでいることがわかったら、実際の取引にこれを全部導入したっていい。

ラブシェール法は勝ちを想定して開発されていて、つまり負けに対してやその他の相互関係にも適応させることはできるが、こういった複雑化は妥当ではないように思える。だってこの方法はゲームの勝ちの期待値に影響を与えることが可能なら＝負けやその他の相互関係に影響を与えることはとても簡単であろうから。もしそうでないとしたら、これは変種の正当性の検証に無駄な時間を浪費することになる。

その他に、勝ちを伴うシステム＝負けや50％の勝率と同等の数値を持つ取引は、もっと簡単に人々に受け入れられる。というのも、僕たちはみんな資金の増加することを知っているから。なのでプログラムをこう名付けよう―CoinTestと。

さて、プラグラムに要望を書き込もう。

  1. 勝ちの確率が変わることは必須だ。50：50のゲームになるのは、平衡的に特殊なケースでしかない。

  2. リスクレベルのセッティングの可能性を持つことは必須だ。ラブシェール法では1のかけ金が固定額になっている。もし僕たちがデポジットの額に応じて初掛金を大きくすると、この方法の要が失われてしまう。というのは、表から全ての数字を消した後、デポジットは初期の額には戻らないからだ。マイナスからの脱却後に掛け金の額を計算しなおすことはできるが、その場合理解（比較、検査）が難しい細かい数字がでてくることになる。というわけで、リスクレベルは2つの可変のもの－初期デポジットの額と、初掛金の額でセッティングする。

  3. 1つのデポジットに最大数の取引を指示する必要がある。最も低い初期リスクの時にも僕たちはデポジットを失うかどうか知ることができるほど十分に多くだ。もしデポジットが伸びたら、これは終わりなく続いて、僕たちは結果を知ることができないかもしれない。

  4. １セット分のデポジットの検査結果は、プログラムの調整やビジネスロジックの変更の為にも持っておきたいものだ。ファイルへの出力はこの目的の為には十分適している。

  5. 1つのデポジットのコードランの記入に成功したら、それぞれのデポジットと回ごとに統計を取る必要がある。この時できれば変更を伴ったパラメータがあるといい。だって1つの実験では、全く統計とは言えないから。統計の出力は同じようにファイルに行う。この時デポジットごとの履歴詳細は興味を引かなくなる。

かけ額の選択のシステムコードは、実際の取引にも使ってもいいので、作成するときはクラスの形態で。

MetaTraderでの実際の取引の開始は、この場合、演算リソースの観点で見ると、とても消費的で無益だ。予め決めた勝率のロット額でのランダムな取引の結果を確定できればそれで十分だ。ここから書くのはアドバイザーでもなく、インディケーターでもなく、スクリプトだけだ。というのは、MQLプログラムの多様性は1回の起動にもよく適しているからだ。


標準擬似乱数生成器の性質の統計的検証

僕たちのもくろみにとって、擬似乱数生成器は大きな意味を持つ、というのは、それこそが僕たちに勝ちと負け、どちらをもたらしてくれるか教えてくれるからだ。　その際、勝ち、または負けの長いパターンの分類の『正直さ』がとても重要だ。長いパターンの分類の正確性を難しい数学的統計論無しに、『目分量』で評価してみよう。

この記事は、擬似乱数生成器の性質を真面目な検査で追及するものではない。（15の様々なテストを行う必要がある）確かめるのはラブシェール法の検証結果に影響を与える擬似乱数生成器の性能だけで、その際に検証のプロセスはあまり難しくないものにする。

MetaTraderでは、僕たちはMathRand()で擬似乱数生成器のスタンダードな機能を利用することができる。. 擬似乱数生成器の一貫性MathSrand()の機能によって初期化される。

スタンダードな擬似乱数生成器の性質を確かめる為に、2つのパラメータを持つ小さいRandFileのスクリプトを書いてみよう。

長いビットパターンの分類計算プロセスはとてもリソースを消費するものだ。（スクリプトの実行時間が10倍になる）その為、このプロセスは別箇のオプションへ移した。

スクリプトは次の結果を出す。

長さの違う３つのテストセットを生成しよう。

それから、テストしてみよう。

  1. 最大圧縮設定でアーカイバWinRarによるランダムデータのファイルの圧縮率定性ランダムデータは圧縮されない。勿論、ファイルが圧縮されないということは、その中にあるランダムデータの高い質を意味しているわけではないが、もし圧縮されるなら、それは確かにデータには統計的規則性があることを意味する。

    1000万ワードの擬似乱数生成器の圧縮率слов

    １億ワードの擬似乱数生成器の圧縮率

    10億ワードの擬似乱数生成器の圧縮率слов

  2. 「1」ビットの数
     均衡数実数絶対偏差
    		 偏差　％
    1000万
    		160 000 000
    		160 004 431
    		4 431
    		0,0027694
    1億
    		1 600 000 000
    		1 599 978 338
    		21 662
    		0,0013539
    10億
    		16 000 000 000
    		15 999 996 180
    		3 820
    		0,0000239
  3. ランダムファイルの中の特定のバイトの値の頻度:

    擬似乱数生成器の特定のバイトの頻度、1000万ワード

    擬似乱数生成器の特定のバイトの頻度、1億ワード

    擬似乱数生成器の特定のバイトの頻度、10億ワード

  4. 同じビットパターンの長さそれぞれのサンプルサイズを2つのグラフで見てみよう。

    • 事実上規定された特定の長さの同じビットパターン数のグラフ、また同様にこのような長さの平均ビット数のグラフ（対数目盛）
    • 平均ビット数からの事実上規定された同ビットパターン数の偏差率グラフ（同様に対数目盛）

    グラフの縮尺は数値に極端に高いばらつきがあるという理由で適さない。（一方、また他方のグラフでは1から40億まで、または0.00001から6000までの数値が必要）その他に対数目盛での長いパターンの平均数値は、そのものが直線を描く、というのはパターンの長さの1つの増長は、その降下の確率が２倍下がるからだ。

1000万ワードの為の同じビットパターンの長さ

1000万ワードの為の平均からのパターンの長さの偏差

１億ワードの為の同じビットパターンの長さ

1億ワードの為の平均からのパターンの長さの偏差

10億ワードの為の同じビットパターンの長さ

10億ワードの為の平均からのパターンの長さの偏差

これらの検証からどんな結論を出せるか？

このようにして、僕たちの検証結果を歪める重大な統計的バグは、30億の数列の生成時にさえ標準擬似乱数生成器ではでてこなかった。（一つの32ビットのワードに対して3つの生成が利用される）


ポジションサイズのコントロールを実行するラブシェール法のクラスの表記

ラブシェール法のクラスは極めてコンパクトだ。そのインターフェイスは全部で初期ロットのサイズの設定と取得の為の２つのラップ機能と、２つの実際に働く機能から成っている。現行ポジションサイズの取得と取引結果の設定、同様に初期状態へのリセット機能だ。

// ラブシェール・マネーマネジメントの実行
// テイク/ストップの提案 = 1/1.
class CLabouchere
{
        private:
        protected:
                // スタートロット初期設定―0.1
                double p_dStartLot;

                // ラブシェール法に従って保存される列
                double p_dLotsString[];
        public:
                void CLabouchere();
                void ~CLabouchere();

                double GetStartLot() {return p_dStartLot;};
                void SetStartLot(double a_dStartLot) {p_dStartLot = a_dStartLot;};

                // 今入る必要があるロットを戻す
                double GetCurrentLot();

                // 現行トレードの結果を記録する―テイク（true）またはストップ（false）
                void SetResult(bool a_bResult);

                // 初期ロット以外を初期状態へリセットする
                void Init() {ArrayResize(p_dLotsString, 0);};
};


動作スクリプトコードの表記結果の事前評価

難しくないスクリプトを次の入力パラメータを持つ百数列に書く。

//--- input parameters
input int RepeatsCount=100000;
input int StartBalance = 10000;
input int Take = 50;
input double SuccessPercent = 50.0;
// もしここでtureならば、SuccessPercentは無視される
input bool FiftyFifty = true;

スクリプトはかけ金のパターンを、デポジットがなくなるまで、またはRepeatsCountに到達するまで作成する。

50：50の勝率が必要な例は、個別の設定へ。この場合、浪費結果の性質には、擬似乱数の1のビットが現れる。他の場合には勝ちと負けの境目を意味する数が算出され、ランダムナンバーはこの境界線と比較される。擬似乱数生成器の個別のビット系列は設定されたが、それ以上の他の境界線数値降下の系列は査定されなかった為、50：50の勝率の場合の為に、個別の設定が実行された。

初期設定：

およそ10回目のスクリプトの起動で印象的な結果が得られる―2335点目でデポジットは46300になる。しかしながら、2372点目から降下していく。

その後の損失を伴うデポジットの成長例

チャート内ではこのデポジットはこう見える。

デポジットチャート

デポジットを失うまで残高は２回危機的数値まで低下したのがわかる。

いくつかの場面において、デポジットは初めの数十回の取引で無くなっていき、最大の10万回の取引を終えることはなかった。

パラメーターと多数の負けの観測の検証の結果、僕の頭には次のことが浮かんだ。

一つの実行の為のスクリプトコードは、記事に全部を移すことができるほどに短くできた。（デポジット存続期間内の詳細事項を含むCCoinTestのクラスに載ったファイル記録を含む）

#include <CCoinTest.mqh>

//--- input parameters
input int RepeatsCount=100000;
input int StartBalance = 10000;
input int Take = 50;
input int PocketPercent = 10;
input double SuccessPercent = 50.0;
input string S2 = 「もしここでtrueなら、SuccessPercentは無視される」;
input bool FiftyFifty = true;
input string S3 = 「もしtrueだったら、ラブシェールの代わりに固定ロットに行ってみよう。」
input bool FixedLot = false;

void OnStart()
{
        MathSrand(GetTickCount());

        CCoinTest Coin;

        Coin.SetRepeatsCount(RepeatsCount);
        Coin.SetStartBalance(StartBalance);
        Coin.SetTake(Take);
        Coin.SetPocketPercent(PocketPercent);
        Coin.SetSuccessPercent(SuccessPercent);
        Coin.SetFiftyFifty(FiftyFifty);
        Coin.SetFileName("Coin.csv");
        Coin.SetFixedLot(FixedLot);

        Coin.Go();
}

ポケットが追加された後でシステム動作のチャートは、少し違った風に見えてくる。（この例ではポケットへ40％の利益が示されている）

例1『ポケット』追加後の残高

紫色の線（ポケット残高）は取引アカウントのあらゆるトレーダーが夢みる理想的なチャートにとても似ている。しかしながら、実際には僕たちは黄色の線に興味を持つ必要がある。『取引アカウントとポケットの合計残高』、これはもうすでにそんなに良くはないが。その他に、遥かに頻繁にこういうパラメータに出会う。

例2　『ポケット』追加後の残高

チャートから分かることは、


様々な確率にとっての最終的な評価結果ラブシェール法と固定かけ法の結果の比較

さて、一番面白いことへ進んでいこう。多数の実験結果の収集で、うまくいったデポジットの勝ちで、うまく行かなかった方の損失をカバーできるかようやくはっきりしてくる。もしかしたら、アルゴリズムは自身にとても低い初掛金の額を現すかもしれない。（なぜなら、そうした方がデポジットを失うことがより難しくなるからだ）もしくは、反対の場合もある。つまりとても高い額のかけ金？勝ちの何％を取引アカウントから引き出す必要があるか？ラブシェール法は固定かけの方法とは違う結果を表せるのか？主要なシステムの期待値がプラスの時何が起こるのか？（もし『コイン』が頻繁に勝ちを与えたら？）疑問は山のようにある、そしてそれらを一つずつ解消していく必要がある。

パラメータの変更を伴うサイクルごとのデポジットの実行の為のスクリプトは、およそ100の列を使用するので、その一部を引用する。

入力パラメータ

//--- input parameters
input int RepeatsCount=100000;
input int StartBalance = 10000;
input string S1 = "Столько депозитов будем сливать";
input int Deposits = 100;
input double SuccessPercent = 50.0;
input string S2 = 「もしここでtrueなら、SuccessPercentは無視される」;
input bool FiftyFifty = true;
input string S3 = 「もしtrueだったら、ラブシェールの代わりに固定ロットに行ってみよう。」
input bool FixedLot = false;

初掛金の額とポケットに入る勝率の値を持つ配列

// PocketPercentのバージョンの配列
int iPocketPercents[24] = {1, 2, 3, 5, 7, 10, 15, 20, 25, 30, 35, 40, 45, 50, 60, 70, 75, 80, 85, 90, 95, 97, 98, 99};

// 初掛金の額の配列
int iTakes[15] = {5, 10, 15, 20, 50, 75, 100, 150, 200, 300, 400, 500, 1000, 2000, 3000};

初掛金の額は5から（初めのデポジットの0.05％）3000まで（初めのデポジットの30％）までに変わったことがわかる。取引アカウントからポケットへ移るパーセンテージは、1％から99％までだ。予め予備とともに選択されたパラメータは、双方の理に適った範囲をカバーする為だ。

このようにして、検索域は2次元のものであり、360の離散点（24×15）が現れ、パターンの結果の一つずつに（パターン内のデポジット量はDepositsパラメータで設定されている）個別のデポジットの平均合計残高が計算される（ポケット内と取引アカウント内の額として）またデポジットの損失までの平均取引数（デポジットの存続期間）

2次元空間における計算結果は3次元であり、つまりそれらを平面媒体で具象化するのは困難だ。その為、横座標によって検索域から点の原子番号を差し引いた2次元のグラフを描くことにする。（0から359まで）必要に応じて、別箇に具体的なTakesとPocketPercentの数値を表示する。

100デポジットの実行結果はこのような平均残高になる。

100反復以降の残高、ラブシェール、50：50

そしてこのようなデポジット存続期間のグラフだ（対数目盛で）

デポジットの存続期間、100反復、ラブシェール、50：50

0.05％の初期リスクのデポジットの存続期間は1万取引以上で、30％の初期リスクの際は連続的に10取引以下まで下がる。PocketPercentの高い数値は同様にデポジットがなくなるまで平均取引数を下げている。十分予期できる結果だ。

ポケットと取引残高の平均グラフはいくつかの点が分離し、そのうちの4つは近くに分布している。これは最適領域を発見したという希望を起こさせる。ここで、Deposits = 1 000の為の結果を計算し、このグラフに載せよう。

100と1000反復後の残高、ラブシェール、50：50

条件に最も適すると仮定する領域は、十分多い数の統計データの急襲のもとに消え去ってしまった。あらゆるパラメータによる、ランダムな方法でのグラフは初期残高数である1万近辺にとても近いところで変動している。

このようにして、Deposits = 100の数値は十分なものではない。全てのこれからの実験はDeposits = 1 000をもって行う。

1つのグラフにラブシェール法の結果と固定かけ法の結果を反映させる。

1000反復の後の残高、ラブシェールと固定ロット、50：50

また、ラブシェール法と固定かけ法のデポジット存続期間のグラフ

デポジット存続期間、1000反復、ラブシェールと固定ロット、50：50

グラフから何が見えるか。

リスクレベルの高い部分の挙動の十分な統計を集める為に、もう一つスクリプトを設定しよう。

input string S2 = 『それぞれのパラメータのペアに対する取引最小値』;
input int MinDeals = 10000000;

もし1000の負けのデポジットの間に、1000万取引があったとしたら、続ける必要がある。

結果、グラフのばらつきは少なくなる。

1000反復後かつ1000万取引以内の残高、ラブシェールと固定ロット、50：50

デポジットの存続期間、1000反復と1000万取引以内、ラブシェールと固定ロット、50：50

ここで50：50と違う初期システムの確率でのシステムの働きを確かめてみよう。

1000反復後の残高、ラブシェールと固定ロット、勝率49％

デポジットの存続期間

デポジットの存続期間、1000反復、ラブシェールと固定ロット、勝率49％

これらのグラフから何が見えるか？

概論部で引用した賛美記事を覚えているだろうか？そこには33～40％の勝率下でもこのシステムは働くとあった。スポーツ的興味の為に上部の踏切板、40％を検証してみよう。

1000反復後の残高、ラブシェールと固定ロット、勝率40％

デポジットの存続期間、1000反復、ラブシェールと固定ロット、勝率40％

ここで初期システムの期待値のプラス値へ移る、つまり50以上の勝率へ移る。

取引の51％の勝率下の残高グラフも対数目盛で描くことになる。

1000反復後の残高、ラブシェールと固定ロット、勝率51％

デポジットの存続期間、1000反復、ラブシェールと固定ロット、勝率51％

グラフから何が見えるか。

多くの読者がここで、固定かけ法が全てのパラメータにおいてラブシェールに勝ると結論するだろう。ましてやデポジットを失わないし、その上、10倍ものお金をもたらしてくれるのだから！そして統計に騙されるのだ。

固定かけ法は一つのデポジットに対し、10万取引の局限にぶつかった。もしRepeatsCountのパラメータが20万だったら、システムは２倍の利益をもたらしただろう。「ただただ素晴らしいじゃないか！」そう騙された読者は言うだろう。そしてまた間違うのだ。

1つの取引のシステムによってもたらされる平均利益をグラフで見てもらいたい（対数目盛で）。

1つの取引に対する利益、ラブシェールと固定ロット、勝率51％

もっと分かり易くするために、１つの取引に対する利益を初掛金の％で表したグラフを引用する。

1つの取引に対する利益、初掛金からの％、ラブシェールと固定ロット、勝率51％

ほら、これらのグラフでわかるのは、

もしあなた達に無制限の時間量があるとしたら、あなた達はラブシェール法抜きにやっていけるだろう。

注意深い読者は、もし固定ロットのシステムを固定リスクパーセンテージに変えれば、１取引あたりの利益は伸びると反発するかもしれない。（実際、利益は絶え間なく伸びるが、比較の為には同じ期間を採用しなければいけない）しかしながら、このような場合、ラブシェール法に同様のポジションサイズの変更を行う必要がある。

さて、ラブシェール法の長所を確信しましたか？

もしそうなら、またまた統計はあなた達を騙したということだ。

表を見てほしい。

 かけ金の額ポケットへの
送金%		 ラブシェール法の
ポケットと
残高の中身の
平均		ラブシェール法の
平均取引数		固定かけ法の
ポケットと
残高の中身の平均		 固定かけ法の
平均取引数		1取引あたりの利益,
ラブシェール法		1取引あたりの利益，
固定かけ法		1取引あたりの利益,
初掛金からの％
ラブシェール法		1取引あたりの利益,
初掛金からの％
固定かけ法
75
10
51 177.34
3 728.62
160 489.6
99 530.41
11.04
1.51
14.72
2.02
500
45
14 016.36
127.27
349 479
33 771.46
31.56
10.05
6.31
2.01

実際、固定かけ法からこのような取引にたいする平均利益数を得る単純な方法がある。それはラブシェール法が見せてくれる。かけ金を７倍にするだけだ（この例では0.75％から5％まで）勿論、5％というのはとても高いレベルのリスクだが、このようなリスクの下でさえ、固定かけ法は10回以上の『持続力』を持つ。

さて、固定かけ法の長所を確信しましたか？

僕が思うに、統計はまたまたあなた達を騙したようだ。

実際デポジットがいくつの取引を生き延びるかは重要ではない（平均は勿論）、だって稼いだ資金の一部をポケットに移す計算で、僕たちの利益は見積もられているのだから。金額の引出しに成功した場合、取引アカウントの初期額を数倍上回り、デポジットの損失は重要な問題ではない。

そして、これらの計算から出せる最も正しい結論は、大体こんな感じになる。初掛金がデポジットの0.75％でラブシェール法の勝率51％、そして10％の利益を引き出す場合、45％の利益を引き出す初期デポジット5％の固定かけ法と同じ収入額が予想される。ラブシェール法はその過程で一時的にポジションサイズを増やすことでこれくらいの収入額に達する。

同様に、どんな統計的な結論も、多数の実験の下でのみ意義を見出すことができるということを忘れてはいけない。一つの取引アカウントはもしかしたら仮想的にいくつかのデポジットにおいて成長するかもしれない。こうして、一つの仮想デポジットの損失は取引アカウントの一部の損失、またいくらかのリスクレベルに達した時に初掛金に移ることを意味する。しかしながら、記事で見たように、動作のシュミレーションは100のデポジットでさえ、とてもばらつきの多い結果を出したし、もし平凡なトレーダーのデポジットの100分の1だったら、取引なんてまったく実行できないだろう。

どのシステムの方がいいか？難しい問題だ。選択はトレーダーの好みによるし、決定値は初期システムの期待値が持つ。その他に、記事に引用されたコードで、どんな希望者も自分の取引システムにラブシェール法のシュミレーションを実行できる。

比較の為に2つのシステムの勝率55％のグラフを引用する。

1000反復後の残高、ラブシェールと固定ロット、勝率55％

デポジットの存続期間、ラブシェールと固定ロット、勝率55％

1取引あたりの利益、ラブシェールと固定ロット、勝率55％

1取引あたりの利益、初掛金からの％、ラブシェールと固定ロット、勝率55％

見てわかるように、55％の勝率下ではどちらのシステムからも、あなた達に利益をもたらすのを邪魔するのは難しくなる。

1取引あたりの平均利益の違いは、勝率51％の際の6～7倍から、勝率55％の際の大体3.7倍まで下がった。これは初期システムの期待値が高いほど、ラブシェール法は沈下時間は短く、またそれゆえ、高いロットでの取引時間も短い。


おわりに

勿論、奇跡は起きなかった。ラブシェール資産運用法は損失から、また中立のシステムからでさえ利益を生み出せない。

それに加え、概論に引用したラブシェール法についての作り話が出てきた理由がわかってきた。

プラスの期待値がある取引にラブシェール法を用いることは有益だろうか？選択は、トレーダー次第だ。ラブシェール法の運用は十分難しいが、収益性への影響は、優れていると言えなくもない。しかしながら、どんな場合においても、僕は２つのアドバイスを与えることができる。もしデポジットを大切にするのなら、陥り易いリスクレベルを上げないこと、そしてあなたの取引システムの期待値が高まった上で用いることだ。