新しいMetaTrader 4 Client Terminal 387とMetaTrader 4 Data Center build 387について - ページ 4 1234567891011...15 新しいコメント Eugeni Neumoin 2011.02.23 16:13 #31 AlexSTAL:通信は削除してしまいましたが、なくても最適化とは何かは十分理解しています...。自分が恐れていること、しかし現実には再現できていないことを、最小限のコードで明確に述べる...。まったくもって意味不明な会話ですが...。どの指標もティックごとにバッファを再初期化するように要求してこないのですが...。だからこそ、何を言っているのか理解しようとするのですが......。to Zhunko: 後で理解するようにします。 なんて、計算だけははっきりしていると書きました。 1)新しいバーが表示されたとき。 2) 価格がすでに計算されたバーの境界線から外れたとき(高値または安値の場合)。 3) 3本または4本の最後のビームを計算する。 これは、私たちの通信の中で議論されたものです。クリアと言いながら...。それとも、無駄なことを書いてしまったのでしょうか。 もし、毎ティック ごとに再初期化、つまりバッファをゼロで埋めるようなことがあれば、毎ティックごとに再計算しなければならないでしょう。これにより、以下のようになります。現在、Putnikaは1つの端末で複数のチャートに最大100件のZUPのインスタンスを表示しています。高速な市場でも、端末はあまり遅くならない。また、1ティックごとに再計算することになれば、同時に起動する指標の数は10倍になってしまいます。また、利用可能な履歴全体に対して計算を行う場合、コンピュータが扱える指標は1インスタンスのみとなる。 物足りないですか? Rashid Umarov 2011.02.23 16:18 #32 nen: もし、毎ティックごとに再初期化、つまりバッファをゼロで埋めるようなことがあれば、毎ティックごとに再計算しなければならないでしょう。これには次のようなことが含まれます。 現在、Putnikaは1つの端末で複数のチャートに最大100件のZUPのインスタンスを表示しています。高速な市場でも、端末はあまり遅くならない。また、1ティックごとに再計算することになれば、同時に起動する指標の数は10倍になってしまいます。また、利用可能な履歴全体に対して計算を行う場合、コンピュータが扱える指標は1インスタンスのみとなります。 どこに書いてあるんですか?まず確認して、初めて怖がることができる。 Aleksandr Chugunov 2011.02.23 16:21 #33 nen: どれだけわかりやすいか、計算だけと書きました。 1)新しいバーが表示されたとき 2) 価格がすでに計算されたバーの部分から外れたとき(高値または安値を超えたとき)。 3)最後の3、4小節を計算する。 これは、私たちの通信の中で議論されたものです。クリアと言いながら...。それとも、無駄なことを書いてしまったのでしょうか。 もし、毎ティックごとに再初期化、つまりバッファをゼロで埋めるようなことがあれば、毎ティックごとに再計算しなければ ならないでしょう。これにより、以下のようになります。 現在、Putnikaは1つの端末で複数のチャートに最大100件のZUPのインスタンスを表示しています。高速な市場でも、端末はあまり遅くならない。また、1ティックごとに再計算することになれば、同時に起動する指標の数は10倍になってしまいます。また、利用可能な履歴全体に対して計算を行う場合、コンピュータが扱える指標は1インスタンスのみとなる。 十分ではないでしょうか? もし、そうだったら......。そのような問題はありません!中興は まったく別の問題を抱えている。パニックを起こす前に、自分でチェックする必要があります。上の数件の書き込みを確認し、コードまで掲載しました。 Aleksandr Chugunov 2011.02.23 16:22 #34 Rosh: どこにそんなことが書いてあるんだ?まず確認して、初めて怖がることができる。 +10000 どんな場合でも、プロフェッショナルなアプローチが必要です...。 Eugeni Neumoin 2011.02.23 16:23 #35 start() { if(glowBar<=iLow(NULL, gtf, 0) && ghighBar>=iHigh(NULL, gtf, 0) && gtimelast==iTime(NULL, gtf, 0)) return (0); glowBar=iLow(NULL, gtf, 0); ghighBar=iHigh(NULL, gtf, 0); // обновляем сразу, а не после длительного расчета ...// здесь код основного расчета. gcurrentBars=iBars(NULL, gtf); // обновляем в конце, чтобы не накапливались непосчитанные бары за время расчета // и не срабатывал полный пересчет на следующем тике в случае длительного расчета } Полный код секции старт //+------------------------------------------------------------------+ //| Custom indicator iteration function | //+------------------------------------------------------------------+ int start() { int i, j; gtf=Period(); gRecalculation=1; while(gRecalculation>0) { if(gcurrentBars<iBars(NULL, gtf)-1) { Print("Время полного пересчета = ",TimeToStr(Time[0],TIME_DATE|TIME_MINUTES)); glowBar=0; ghighBar=0; gtimelast=0; gsave_wr0=0; ArrayInitialize(gsave_tLast,0);ArrayInitialize(gsave_hl,0);ArrayInitialize(gsave_lastlow,0);ArrayInitialize(gsave_lasthigh,0); ArrayInitialize(gt_hi,0);ArrayInitialize(gt_li,0);ArrayInitialize(gt_end,0); gTheExternalBar=false; history=true; // if(_PrimarySelectionOfExtremums==2 || _PrimarySelectionOfExtremums==3) delete_objects(); delete_objects(); g_addnewextremum=true; gbar=iBars(NULL, gtf); ArrayInitialize(gtime_gbar,0); ArrayInitialize(gL2LTime,0); ArrayInitialize(gL2HTime,0); ArrayInitialize(LowestBuffer1,0);ArrayInitialize(HighestBuffer1,0); ArrayInitialize(LowestBuffer2,0);ArrayInitialize(HighestBuffer2,0); ArrayInitialize(LowestBuffer3,0);ArrayInitialize(HighestBuffer3,0); ArrayInitialize(LowestBuffer4,0);ArrayInitialize(HighestBuffer4,0); ArrayInitialize(last_h,0);ArrayInitialize(last_l,0);ArrayInitialize(last_t,0); ArrayInitialize(tL1,0);ArrayInitialize(tL2,0);ArrayInitialize(tL3,0);ArrayInitialize(tL4,0);ArrayInitialize(tL5,0); ArrayInitialize(tL6,0);ArrayInitialize(tL7,0);ArrayInitialize(tL8,0);ArrayInitialize(tL9,0);ArrayInitialize(tL10,0); ArrayInitialize(tL11,0); ArrayInitialize(cL1,0);ArrayInitialize(cL2,0);ArrayInitialize(cL3,0);ArrayInitialize(cL4,0);ArrayInitialize(cL5,0); ArrayInitialize(cL6,0);ArrayInitialize(cL7,0);ArrayInitialize(cL8,0);ArrayInitialize(cL9,0);ArrayInitialize(cL10,0); ArrayInitialize(cL11,0); ArrayInitialize(cH1,0);ArrayInitialize(cH2,0);ArrayInitialize(cH3,0);ArrayInitialize(cH4,0);ArrayInitialize(cH5,0); ArrayInitialize(cH6,0);ArrayInitialize(cH7,0);ArrayInitialize(cH8,0);ArrayInitialize(cH9,0);ArrayInitialize(cH10,0); ArrayInitialize(cH11,0); if(filterZigZag==1) { ArrayResize(cLz1,gbar);ArrayResize(cHz1,gbar);ArrayResize(tLz1,gbar); ArrayInitialize(tLz1,0);ArrayInitialize(tLz2,0);ArrayInitialize(tLz3,0);ArrayInitialize(tLz4,0);ArrayInitialize(tLz5,0); ArrayInitialize(tLz6,0);ArrayInitialize(tLz7,0);ArrayInitialize(tLz8,0);ArrayInitialize(tLz9,0);ArrayInitialize(tLz10,0); ArrayInitialize(tLz11,0); ArrayInitialize(cLz1,0);ArrayInitialize(cLz2,0);ArrayInitialize(cLz3,0);ArrayInitialize(cLz4,0);ArrayInitialize(cLz5,0); ArrayInitialize(cLz6,0);ArrayInitialize(cLz7,0);ArrayInitialize(cLz8,0);ArrayInitialize(cLz9,0);ArrayInitialize(cLz10,0); ArrayInitialize(cLz11,0); ArrayInitialize(cHz1,0);ArrayInitialize(cHz2,0);ArrayInitialize(cHz3,0);ArrayInitialize(cHz4,0);ArrayInitialize(cHz5,0); ArrayInitialize(cHz6,0);ArrayInitialize(cHz7,0);ArrayInitialize(cHz8,0);ArrayInitialize(cHz9,0);ArrayInitialize(cHz10,0); ArrayInitialize(cHz11,0); } Print(""); } else { if(_PrimarySelectionOfExtremums<2) { gbar=iBarShift(NULL, gtf, gtime_gbar[0], true)+2; } } if(_PrimarySelectionOfExtremums==4 && gtimelast==iTime(NULL, gtf, 0)) return(0); if(tL1[0]>0) { if(glowBar<=iLow(NULL, gtf, 0) && ghighBar>=iHigh(NULL, gtf, 0) && gtimelast==iTime(NULL, gtf, 0)) return (0); if(gtimelast<iTime(NULL, gtf, 0) &&(_PrimarySelectionOfExtremums==2 || _PrimarySelectionOfExtremums==3)) { gTheExternalBar=false; delete_objects(); } } glowBar=iLow(NULL, gtf, 0); ghighBar=iHigh(NULL, gtf, 0); // обновляем сразу, а не после длительного расчета // Поиск экстремумов для первого уровня glevel=0; SamplingCreationExtremums(); if(history) { if(ShowPrimaryLevel==0) { VisiblePrimarySelections(cL1, cH1, tL1, cLz1, cHz1, tLz1, LowestBuffer1, HighestBuffer1); // визуализация } // Создание следующих уровней и визуализация SelectionArrayForNextLevels(); gtimelast=iTime(NULL, gtf, 0); // эта переменная используется в промежуточных расчетах, поэтому ее обновляем после расчетов history=false; //* // Обрезка массивов if(QuantityExtremums>0) { for(i=1;i<11;i++) { int k=ScrapOfArrays(i); if(k!=0) Print("размер массива уровня ",i-1," = ",k); if(k==0) break; // if(ScrapOfArrays(i)==0) break; } } //*/ } else { WriteNewExtremums(cL1, cH1, tL1, cLz1, cHz1, tLz1); // Создание следующих уровней и визуализация SelectionArrayForNextLevels(); gtimelast=iTime(NULL, gtf, 0); // эта переменная используется в промежуточных расчетах, поэтому ее обновляем после расчетов } if(gRecalculation>0) gRecalculation--; } gcurrentBars=iBars(NULL, gtf); // обновляем в конце, чтобы не накапливались непосчитанные бары за время расчета // и не срабатывал полный пересчет на следующем тике в случае длительного расчета Err(371); return(0); } //+------------------------------------------------------------------+ 小さなコードの断片。そして、私のすべての指標において、多少の変動はあってもほぼ同じです。 バッファを再初期化する領域がかなり広いので注意してください。すべてのArrayInitialize関数は、このような再初期化に従事しているだけである。しかし、それはあくまで必要に応じて起こるもので、強制されるものではありません。 Eugeni Neumoin 2011.02.23 16:37 #36 すでに最初のページで、開発者向けにポイント6の意味を説明するように書いています ターミナル:カスタムインジケーターで ヒストリカルデータを再読み込みする際に、バッファの初期化が追加されました。 まだ、彼らから説明は受けていない。そして、私たちはここでコップの水の中に嵐を作り出すのです。しかし、それはここだけではありません。私のインジケータを使用している皆さんには、ビルド387をダウンロードする前に待つように警告しています。 Eugeni Neumoin 2011.02.23 16:53 #37 議論は終わりです。 Slava 2011.02.25 09:35 #38 Zhunko: コンプレックスが機能しない理由がわかった。さようなら、最適化 :-( 今は、ティックごとにバッファを再充填しなければなりません。世話になった... 変化なし-初期化なし!せめて、考えてください! バッファで履歴データを読まない。サブウインドウでの垂直方向の掃引にしか使っていません。なぜ、常に満たす必要があるのでしょうか?上書きが必要な場面は3つだけです(初回起動、ズーム、チャートシフト)。このままではMT4はほとんど動きませんし、もう一つブレーキがかかっています。 変化なし、初期化なし。そうなんです。初期化は、ヒストリカルデータを上書き した後に行われます。これは以前から想定されていたことですが、ただ、意図した通りにはいきませんでした。通常の状態では、小節の後(または接続失敗の後に数小節)、バッファの初期化は行われません。 Slava 2011.02.25 09:41 #39 2端末:カスタムインジケーター 計算時の相場カウンターの計算を修正。 過去データの変更回数の推定に誤りがありました。変更回数が多い場合、データの再計算が 行われず、誤った再計算が行われた。特に、データが大きく変化したのにジグザグが再計算されない場合、ジグザグ・インジケータに影響がありました。 Slava 2011.02.25 09:48 #40 VBAG: すごいですねぇ。開発者はB4をあきらめたわけではなく、サポートし、さらに改良を加えているのです。これは、単純にビルドナンバー387が証明していますね 最後に見たのは-229。そして一気に-387(コプロセッサが繋がってるかも?はぁ...)!?カッコイイ! 要は、外科医・プログラマーの主な戒めである「害を及ぼしてはならない!」を尊重することです。 MetaTrader 4プラットフォームは、サーバー、データセンター、相場とニュースのフィーダー、クライアントターミナル、マネージャーと管理者ターミナル、API、APIを使って書かれた標準アドオンなど、多くのコンポーネントの集合体です。これらの部品は、それぞれ異なる方法で進化してきました。 そのため、現行のコンポーネントはすべて380番を付与し、ビルドのナンバリングを統一しています。純粋に美容のための手術です。 1234567891011...15 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
通信は削除してしまいましたが、なくても最適化とは何かは十分理解しています...。
自分が恐れていること、しかし現実には再現できていないことを、最小限のコードで明確に述べる...。
まったくもって意味不明な会話ですが...。どの指標もティックごとにバッファを再初期化するように要求してこないのですが...。
だからこそ、何を言っているのか理解しようとするのですが......。
to Zhunko: 後で理解するようにします。
なんて、計算だけははっきりしていると書きました。
1)新しいバーが表示されたとき。
2) 価格がすでに計算されたバーの境界線から外れたとき(高値または安値の場合)。
3) 3本または4本の最後のビームを計算する。
これは、私たちの通信の中で議論されたものです。クリアと言いながら...。それとも、無駄なことを書いてしまったのでしょうか。
もし、毎ティック ごとに再初期化、つまりバッファをゼロで埋めるようなことがあれば、毎ティックごとに再計算しなければならないでしょう。これにより、以下のようになります。現在、Putnikaは1つの端末で複数のチャートに最大100件のZUPのインスタンスを表示しています。高速な市場でも、端末はあまり遅くならない。また、1ティックごとに再計算することになれば、同時に起動する指標の数は10倍になってしまいます。また、利用可能な履歴全体に対して計算を行う場合、コンピュータが扱える指標は1インスタンスのみとなる。
物足りないですか?
もし、毎ティックごとに再初期化、つまりバッファをゼロで埋めるようなことがあれば、毎ティックごとに再計算しなければならないでしょう。これには次のようなことが含まれます。 現在、Putnikaは1つの端末で複数のチャートに最大100件のZUPのインスタンスを表示しています。高速な市場でも、端末はあまり遅くならない。また、1ティックごとに再計算することになれば、同時に起動する指標の数は10倍になってしまいます。また、利用可能な履歴全体に対して計算を行う場合、コンピュータが扱える指標は1インスタンスのみとなります。
どれだけわかりやすいか、計算だけと書きました。
1)新しいバーが表示されたとき
2) 価格がすでに計算されたバーの部分から外れたとき(高値または安値を超えたとき)。
3)最後の3、4小節を計算する。
これは、私たちの通信の中で議論されたものです。クリアと言いながら...。それとも、無駄なことを書いてしまったのでしょうか。
もし、毎ティックごとに再初期化、つまりバッファをゼロで埋めるようなことがあれば、毎ティックごとに再計算しなければ ならないでしょう。これにより、以下のようになります。 現在、Putnikaは1つの端末で複数のチャートに最大100件のZUPのインスタンスを表示しています。高速な市場でも、端末はあまり遅くならない。また、1ティックごとに再計算することになれば、同時に起動する指標の数は10倍になってしまいます。また、利用可能な履歴全体に対して計算を行う場合、コンピュータが扱える指標は1インスタンスのみとなる。
十分ではないでしょうか?
どこにそんなことが書いてあるんだ?まず確認して、初めて怖がることができる。
+10000
どんな場合でも、プロフェッショナルなアプローチが必要です...。
小さなコードの断片。そして、私のすべての指標において、多少の変動はあってもほぼ同じです。
バッファを再初期化する領域がかなり広いので注意してください。すべてのArrayInitialize関数は、このような再初期化に従事しているだけである。しかし、それはあくまで必要に応じて起こるもので、強制されるものではありません。
すでに最初のページで、開発者向けにポイント6の意味を説明するように書いています
ターミナル:カスタムインジケーターで ヒストリカルデータを再読み込みする際に、バッファの初期化が追加されました。
まだ、彼らから説明は受けていない。そして、私たちはここでコップの水の中に嵐を作り出すのです。しかし、それはここだけではありません。私のインジケータを使用している皆さんには、ビルド387をダウンロードする前に待つように警告しています。
コンプレックスが機能しない理由がわかった。さようなら、最適化 :-(
今は、ティックごとにバッファを再充填しなければなりません。世話になった...
変化なし-初期化なし!せめて、考えてください!バッファで履歴データを読まない。サブウインドウでの垂直方向の掃引にしか使っていません。なぜ、常に満たす必要があるのでしょうか?上書きが必要な場面は3つだけです(初回起動、ズーム、チャートシフト)。このままではMT4はほとんど動きませんし、もう一つブレーキがかかっています。
変化なし、初期化なし。そうなんです。初期化は、ヒストリカルデータを上書き した後に行われます。これは以前から想定されていたことですが、ただ、意図した通りにはいきませんでした。通常の状態では、小節の後(または接続失敗の後に数小節)、バッファの初期化は行われません。
2端末:カスタムインジケーター 計算時の相場カウンターの計算を修正。
過去データの変更回数の推定に誤りがありました。変更回数が多い場合、データの再計算が 行われず、誤った再計算が行われた。特に、データが大きく変化したのにジグザグが再計算されない場合、ジグザグ・インジケータに影響がありました。
すごいですねぇ。開発者はB4をあきらめたわけではなく、サポートし、さらに改良を加えているのです。これは、単純にビルドナンバー387が証明していますね
最後に見たのは-229。そして一気に-387(コプロセッサが繋がってるかも?はぁ...)!?カッコイイ!
要は、外科医・プログラマーの主な戒めである「害を及ぼしてはならない!」を尊重することです。
MetaTrader 4プラットフォームは、サーバー、データセンター、相場とニュースのフィーダー、クライアントターミナル、マネージャーと管理者ターミナル、API、APIを使って書かれた標準アドオンなど、多くのコンポーネントの集合体です。これらの部品は、それぞれ異なる方法で進化してきました。
そのため、現行のコンポーネントはすべて380番を付与し、ビルドのナンバリングを統一しています。純粋に美容のための手術です。