ライトマーチンゲールエキスパート - 良い結果をもたらす (エキスパートコード添付) - ページ 11

 

実は、マーチンゲールは、もう少しよく考えてみると悪いものではありません。自分でも似たようなシステムをやりましたが、少し違う方法です。

反転しているので、十分な長さ、例えば日足平均の80-100%の急激な動きを探す必要があります(最初の取引を開始するため)。そして、この動きは1日以内に行わなければならない。その場合、最初の動きの少なくとも23%(最小限のフィボレベル...トレンドに沿って38%を試すこともできる)のプルバックはほぼ避けられないだろう。もし、このまま不利な動きが続くようであれば、ゆっくりと出来高を増やし(できればかなりの水準で)、常に上昇波に対して23%の水準で利食いするようにしましょう。すなわち、後続の各テイクの長さが徐々に長くなっていく。したがって、新しい取引を行うたびに、スイングの長さに比例して利益目標が増加するように、出来高を正しく計算する必要があります。

ただ基本的な考え方は、初動はほとんど失敗しないこと(それのどの時点でもプルバックは前の動きの20%を超えてはならない)、これを確認することである。

もちろん、トレンドの有無や強弱も考慮する必要がある。このようなシステムのテストにおいて、損益率に関する私の最高の結果は、トレンドに対して23%、トレンドに対して15%で計算されています。

 
fedor:


最初のケースは良かったが、今はもうダメだ。
いずれも下降トレンドの中で買い付けを重ねた。どちらのケースも、最後の注文は、石墨が買い命令を出したので、前の注文を決済しなかったのでしょう。しかし、最初のケースでトレンドは上昇し、2番目のケースで反転した。
私はプログラミングが苦手なので、まだ答えが見つかっていません。サルトへの 質問:間違いはどこに あるのか?

8番目の注文(Order_7)がトリガーされたときに、10番目の指値注文(Order_9)が開かないからです。これはテスターログのエラー130(間違ったストップ)で示され、その結果、以前に開いた注文の修正(新しいTPとSLの設定)が行われません。したがって、価格がTPで反転したときに8番目の注文(Order_7)だけが決済され、残りの注文は運良く、つまり7番目の指値注文(Order_6)の開設時に設定したTPまたはSLで、価格の動きによって決済されることになるのです。

つまり、この場合、10番目の指値注文(Order_9)を開くには、Order_10_Level変数が必要ですが、これは単に存在しないだけです。

_OrderStopLoss [i] = _OrderOpenPrice[i] - TradeCycleDirectin * OrderLevel[i+1] * Point.OrderStopLoss[i](オーダーストップ・ロス)。

私見ですが、配列を11個以上に増やし、Order_10_LevelやOrder_10_Lotsなどの変数を追加すれば、状況は改善されるのでは...と思います。ただし、この方法では原理的に「不具合」が解消されるわけではありません。より良い時代」まで先送りされるだけ...。:)小幅な逆行現象が長期化するかどうかは、まだ未解決です。

P.S. 私はトレーディングの分野では初心者で、プログラミングはむしろ趣味のようなものです。したがって、何か間違っていたら訂正してください。

敬具ユージン

 
jinn2000:

P.S. 私はトレーディングは初めてで、プログラミングはどちらかというと趣味に近いです。したがって、間違っていることがあれば訂正してください。

まずは、引用文から冗長なテキストを削除する方法を学びましょう...
 

1つだけ不正確な点がありました。運が悪い」場合、Order_7がクローズした後、次の注文が続けて出され、既に出ている注文は修正されます。つまり、Order_6のオープニングで設定したSLではなく、もっと大きな損失で注文の積み重ね全体がクローズされることになる。しかし、それで問題が解決するわけではありません。

リーズナブル。ユージン

 
komposter:
jinn2000 です。

P.S. 私はトレーディングは初めてで、プログラミングはどちらかというと趣味に近いです。したがって、何か間違っていたら訂正してください。

手始めに、引用文から冗長なテキストを削除する方法について学びましょう...

ご指摘ありがとうございます。今後のために覚えておこうと思います。
 
問題は、なぜわざわざ Order_..._Level や Order_..._Lots という変数を使うのか、ということです。
これらの値は、単に取得するだけでなく、一定のアルゴリズムに従ってプログラム内で計算される必要があります。
 
Meat:
問題は、なぜわざわざ Order_..._Level や Order_..._Lots という変数を使うのか、ということです。
これらの値は、単に取得するだけでなく、一定のアルゴリズムに従ってプログラム内で計算される必要があります。
もちろんですが、どのようなアルゴリズムなのでしょうか?このアルゴリズムがわかっていれば、そうしたい。もしかしたら、アイデアと同時に、ローリターン傾向への対処法も教えてくれるかもしれません。
 
Sart:
もちろんですが、どのようなアルゴリズムに基づいているのでしょうか?このアルゴリズムがわかっていれば、そうしたい。

Order_..._Level 変数の合計値は、特定のシンボルの履歴上の小さなバックフォールの振幅に見合ったものであることが望ましい。正直なところ、保険をかければかけるほど、Expert Advisorは儲からなくなります。

 
Sart:
アイデア、...、ローリターントレンドに対処するアイデアを浮かべることができるかもしれません。
それはマーケットメーカーのためです - 彼らは定期的にすべての平均化MTSを殺すためにトレンドを描画します:)
 
jinn2000:

Order_..._Level 変数の合計値は、特定のシンボルの履歴上の小さなバックフォールの振幅に見合った ものであることが望ましい。ただし、保険に加入すればするほど、Expert Advisorの収益性は低下します。


ただし、この「低バウンス期間」の振幅と周期の両方が非常に変化しやすいことを除けば :)また、優れた保険(100%に近い)技術により、平均して年間約10%の利益を得ることができます。ほとんど銀行と同じですが、リスクはまだ高いです :)