MQL4、MQL5に関する初心者からの質問、アルゴリズムやコードに関するヘルプ、ディスカッションなど。 - ページ 1383

新しいコメント
 

これはどうでしょう？

bool CheckSpr(int _sp)
{
   static int ts=0, res=0;
   static long tc=0;
   if(tc>50 && res*3<_sp) return(false);
   tc++;
   ts += _sp;
   res =ts/tc;
   if(tc>LONG_MAX-1) {
      tc=0;
      ts=0;
   }
   // Comment( res,"=",tc );
   if(tc<50) return(false);
   return(res>_sp?true:false);
}

ここでもまた、ロールオーバーの前ではなく、ロールオーバー中にコードを実行すると、50ティックの巨大なスプレッドが書き込まれ、この行は意味をなさないのです。

コードを修正するには？

 
Vitaly Muzichenko:

これはどうでしょう？

ここでもまた、ロールオーバーの前ではなく、ロールオーバー中にコードを実行すると、50ティックの巨大なスプレッドが書き込まれ、この行は意味をなさないのです。

コードを修正するには？

理屈はいい加減にしてほしい。なぜ正確に50ティックからカウンターで平均化し、ロングマックスを長く続けることができます。

シンボルプロパティに宣言されたスプレッドがあります。最初はインプットで入力する必要があります。また、入力されていない場合は、受信されます。そして、スプレッドが拡大した場合、それを平均的なものと勘違いしてしまうのです。変化を検知するためには、かなり短い範囲での平均値が必要です。

日中スプレッドがある場合は、1ティックごとに比較し、平均値を必要な値にします。問題は、中間値を覚えていないと平均を計算できないことです。私はそうして、すべての値を記憶し、最後の値プラス1が出たら、それを合計に加え、最初の値を引く、シフト番号付け（配列ではA（n）＝A（n＋1））をして使っています。カウンターを巨大な値にダイヤルアップするよりも安上がりです。そして、10〜20の値までは変数を使います。

SymbolInfoIntegerと BidとAskの差)のどちらが高いかわからない。

 
Valeriy Yastremskiy:

理屈はいい加減にしてほしい。なぜ正確に50ティックからカウンターで平均化し、ロングマックスを長く続けることができます。

シンボルプロパティに宣言されたスプレッドが あります。最初はインプットで入力する必要があります。また、入力されていない場合は、受信されます。そして、スプレッドが拡大した場合、それを平均的なものと勘違いしてしまうのです。変化を検知するためには、かなり短い範囲での平均値が必要です。

日中スプレッドがある場合は、1ティックごとに比較し、平均値を必要な値にします。問題は、中間値を覚えていないと平均を計算できないことです。私はそうして、すべての値を記憶し、最後の値プラス1が出たら、それを合計に加え、最初の値を引く、シフト番号付け（配列ではA（n）＝A（n＋1））をして使っています。カウンターを巨大な値にダイヤルアップするよりも安上がりです。そして、10〜20の値までは変数を使います。

SymbolInfoIntegerと BidとAskの差のどちらが高いかわからない。）

フローティング」という言葉だけが、問題なんです。


 
Vitaly Muzichenko:

Floating」という言葉だけで、挑戦しているのです。


は少し興奮しました）。そうすると、最初の値が正しいと信じる論理になる。あるいは、10分間待って、その間のスプレッド変化の滑らかさの統計を取り、50または100ティックの平均最小プロットを求め、それを平均値とする。開始時刻は、取引所が稼動していない時間に当たらないように制御する。馬鹿も完全防備を望むなら)

 
Valeriy Yastremskiy:

(ちょっと興奮しちゃった）。そうすると、最初の値が正しいと信じる論理になる。あるいは10分間待って、この間のスプレッド変化の滑らかさの統計を取り、50ティックあるいは100ティックの平均最小プロットを求め、それを平均値とする。開始時刻は、取引所が稼動していない時間に当たらないように制御 する。愚者も完全防備の場合)。

これはなんとか避けたいものです。

ロールオーバー時にExpert Advisorを実行しないだけで、アルゴリズムは機能し、週末以降も機能します。

 
Vitaly Muzichenko:

これはなんとか避けたいものです。

このアルゴリズムは、週末以降によく起こるロールオーバーでExpert Advisorを実行しない限り、機能します。

とにかく避けるべき一つの制御は、何かに置き換えるべきです。ティック間の時間です。あまり高くない。そして、ティック間の時間が10秒以上であれば、何かが間違っている。

 
Vitaly Muzichenko:

これはなんとか避けたいものです。

このアルゴリズムは、週末以降によく起こるロールオーバーでExpert Advisorを実行しない限り、機能します。

ロールオーバーのための時間パラメータを別々に作る必要がある：開始/終了。
そして、この間は何もしない（「ロールオーバー、待機」のコメントを除く）。

 
Taras Slobodyanik:

ロールオーバーのための時間パラメータを別々に作る必要があります：開始/終了。
そして、その時間には何もしないでください（「ロールオーバー、待機」というコメントを除く）。

work by time」というパラメータがあったので、ディーリングを変更してフクロウを開始したところ、ロールオーバー時にディールがオープンされました。

ディーリングタイムが通常+2gmtの ところ、-1gmtになっていたのだ。

だからこそ、時効から逃れたいという思いが強かったのです。

 
Vitaly Muzichenko:

Work by time」パラメータがあったので、ディーリングを変更し、フクロウを開始したところ、ロールオーバー時にトレードが開始されました。

ディーリングタイムが通常+2gmtの ところ、-1gmtになっていたのだ。

だからこそ、時効から逃れたいという思いが強いのです。

時間値」を、入力される（新しい）時間と最後に計算された時間との差に置き換えることは有効でしょうか？

つまり、新しい時代の到来を知ることができるのです。

-新日から

-新しい週から

-または指定された以上の差を有する。

 
Vitaly Muzichenko:

Work by time」パラメータがあったので、ディーリングを変更し、フクロウを開始したところ、ロールオーバー時にトレードが開始されました。

ディーリングタイムが通常+2gmtの ところ、-1gmtになっていたのだ。

だからこそ、時効から逃れたいという思いが強かったのです。

週明けの「ロールオーバー、待ち時間」、サーバーの時間に 関係なく作ろう
1...137613771378137913801381138213831384138513861387138813891390...1953
新しいコメント