Предлагаю компромисс: ловишь тики шпионами и сразу отправляешь в головной эксперт, снабдив милисекундной меткой(GetTickCount()). Эксперт их упорядочивает в соответствии с метками и нарезает секундные блоки.
私のように、2009年以外の日付で終わる偽の履歴がある場合、2つのFibo Time Zoneの一方がその転換期を通過し、もう一方がすでに完全に履歴の右側にあり、すべてのバーが実在するように配置を変更します。この場合、スクリプトのstartTime1、endTime1、必要ならstartTime2、endTime2の値を変更することを忘れないでください。これでテストができる...その結果、両タイムゾーンのチェックアルゴリズムが変更されないまま、ターニングポイントの日付の一足前と一足後のゾーンに対してのみ正しく動作すると、アルゴリズムが誤ってそれをフィルタリングしてしまい、構築できない、という悲しい結果になる。両方のタイムゾーンは互いにかなり近く、同じような幅を持っていることに注意してください。この2つの幅はずっと先まで伸びていて、長い間関連性があり、実際にはどちらもフィルターにかけるべきではありません(条件をコメントアウトして両方のタイムゾーンが構築されていることを確認してください)。
voidOnStart()
{
datetime startTime1=D'2009.07.08 18:00:00';
datetime endTime1=D'2009.11.03 12:17:00';
datetime startTime2=D'2009.06.30 08:00:00';
datetime endTime2=D'2009.10.21 20:16:00';
double startPrice1=0.61930;
double endPrice1=0.70948;
double startPrice2=0.65470;
double endPrice2=0.76300;
int FTZ1pos1,FTZ2pos1,bandwidth;
datetime Arr[],time1;
CopyTime(_Symbol,PERIOD_M1,0,1,Arr);
time1=Arr[0];
FTZ1pos1=CopyTime(_Symbol,PERIOD_M1,time1,startTime1,Arr);
bandwidth=CopyTime(_Symbol,PERIOD_M1,endTime1,startTime1,Arr)*(34+2); // +2 - небольшой запас общей ширины// зоны на всякий случайif(FTZ1pos1<=bandwidth)
ObjectCreate(0,"FTZ1",OBJ_FIBOTIMES,0,
startTime1,startPrice1,
endTime1,endPrice1
);
// ---
FTZ2pos1=CopyTime(_Symbol,PERIOD_M1,time1,startTime2,Arr);
bandwidth=CopyTime(_Symbol,PERIOD_M1,endTime2,startTime2,Arr)*(34+2); // +2 - небольшой запас общей ширины// зоны на всякий случайif(FTZ2pos1<=bandwidth)
ObjectCreate(0,"FTZ2",OBJ_FIBOTIMES,0,
startTime2,startPrice2,
endTime2,endPrice2
);
}
失礼にあたりますが...。:))
おそらく。
問題の本質を読みましたが、なぜ各インジケータにタイマーが必要なのか、また、なぜこんなに多くのインジケータがあるのかが理解できません。
EAタイマーで必要な楽器のBidを直接取得して、総集編に入れることができれば。
インジケータを使う場合は、解像度が細かいので、インジケータがたくさん必要になります。
スパイは時計を持っていないので、すべての機器のイベントが長い間起こらないかもしれないし、次々と起こり始めるかもしれません。
例えば、Last priceがあるディーリングでは、Bidデータがあるとは限らないので、BidかLastのどちらかをチェックして書き込む。
MetaDriver:
私は妥協案を提案します。スパイでティックをキャッチし、ミリ秒のラベル(GetTickCount())を付けてすぐにヘッドExpert Advisorに送ります。Expert Advisorは、ラベルに従って配列し、2番目のブロックにスライスします。
あまり単純ではありませんが、正確な情報を得ることができるでしょう。
悪いバリエーションではありません。私見ですが、これだけは根拠として取り上げる価値があると思います。
ウラン です。
ちなみに、Last priceがあるディーリングでは、Bidデータがあるとは限らないので、BidかLastのどちらかをチェックして書き込んでください。
MetaDriver:
Предлагаю компромисс: ловишь тики шпионами и сразу отправляешь в головной эксперт, снабдив милисекундной меткой(GetTickCount()). Эксперт их упорядочивает в соответствии с метками и нарезает секундные блоки.
Не очень просто, зато с точностью будет порядок.
悪い選択肢ではない。私見ですが、唯一根拠として取り上げる価値のあるものだと思います。
良い明確化、これに遭遇したことがない。考慮しなければならないでしょう。悪いバリエーションではないかもしれませんが、ティックを送信する仕組みがターミナルにありません。16組で5〜10tick/secを目安に考えてみてください。もう一度言いますが、もうありません))。
しかも、そんな精度は必要なく、1秒あれば十分です。
皆さんのおかげで、このテーマは終了しました。
この問題は、分単位の履歴がまだなかった遠い過去に、分単位のバーがより高い時間枠のバーと置換されたために非常に不愉快なものです。解決策として思いつくのは、偽物の棒を本物に複雑に変換することであり、その精度を保証することはできない。複雑というより、その変換の正確さに疑問があるのです。
最初の作業は、構築されるフィボナッチタイムゾーンの 関連性を確認することです。ゾーンが遠すぎて、そのすべてのサブゾーンの作業幅(デフォルトでは最大34ベース幅)が狭く、右端が現在に届かない場合は、構築せず、それ以外はチャート上にオブジェクトを作成します。2つの似たような方法でこれを解決しようとし、そのうちの1つを引用する。ただ、1つ違うのは、最初の方法では、物語の冒頭から使って踊っていたことです。
しかし、2つ目は......逆に(私はこの方法を引用しています)、本質と結果がまったく同じなのです。NZD/USDで テストしてみました。私のように、2009年以外の日付で終わる偽の履歴がある場合、2つのFibo Time Zoneの一方がその転換期を通過し、もう一方がすでに完全に履歴の右側にあり、すべてのバーが実在するように配置を変更します。この場合、スクリプトのstartTime1、endTime1、必要ならstartTime2、endTime2の値を変更することを忘れないでください。これでテストができる...その結果、両タイムゾーンのチェックアルゴリズムが変更されないまま、ターニングポイントの日付の一足前と一足後のゾーンに対してのみ正しく動作すると、アルゴリズムが誤ってそれをフィルタリングしてしまい、構築できない、という悲しい結果になる。両方のタイムゾーンは互いにかなり近く、同じような幅を持っていることに注意してください。この2つの幅はずっと先まで伸びていて、長い間関連性があり、実際にはどちらもフィルターにかけるべきではありません(条件をコメントアウトして両方のタイムゾーンが構築されていることを確認してください)。
望む結果
1本目と2本目の0ベースラインの間に、偽物の分足と本物の分足を分ける転換点があります。
バー数での計算を否定し、すべて日付で計算すると、週末(市場終了/開始の±1時間)や休日などを差し引かなければならず、ましてや1分以上のティックがない場合のバーの欠落やタイムラインからの乖離など、確かに期待する精度にはならないでしょう。
信頼性の高いソリューションとして、どのようなアドバイスがありますか?
Expert Advisorでファイルの読み込みにエラーが発生する。 10個の相違点を見つける。最初のコードはスクリプトを指し、2番目のコードはExpert Advisorを指し、これらは同じです。スクリプトでは動作しますが、Expert Advisor では動作しません。
Expert Advisorでファイルの読み込みにエラーが発生する。 10個の相違点を見つける。最初のコードはスクリプトを指し、2番目のコードはExpert Advisorを指し、これらは同じです。スクリプトでは動作しますが、Expert Advisor では動作しません。
P.S. 共通フォルダに 入れるには、FILE_COMMONという修飾子をつけたファイルを書く か、次のようなものを探す必要があります(XP用の変形):
C:Documents and SettingsAll Users Application Data ○MetaQuotes ○Terminal ○CommonFiles
信頼性の高いソリューションとして、どのようなアドバイスがありますか?
MT4に戻る。
この問題の今後について開発者に問い合わせたが、沈黙を守っているので、個人的には今後についてはよく分からない。
文字変数を使った切り替えがうまくいかないようです...。
の代わりに。
'type' - 不正なスイッチング式タイプ
買う」-定数式は積分ではない
こんな風に描かないといけないんだ。
あまりはっきりしないし、曲がっている。
他の言語でも問題なく使えます。
別の書き方をしたほうがいいのでしょうか?
Switchは文字変数では動作しないようです...。
ドキュメントには(強調)-Switch operatorと 書かれています。
式の値をすべての 大文字小文字の定数と比較 し、 式の値と一致する演算子に制御を渡します 。各ケースバリアントは、 整数定数、文字定数、定数式で マークすることができる。 定数式には、変数や関数呼び出しを含めることはできません。 switch 演算子式は 整数 型でなければならない。
他の言語でも使える...