アドバイザープロジェクト - ページ 7 1234567 新しいコメント Andrey Kisselyov 2017.08.10 19:48 #61 George Merts:ATRは指標としてカウントされない」ってどういうこと？ また、どうして「エントリーシグナルとしてふさわしくない」のでしょうか？このインジケーターだけで「ボラティリティ・ブレイクスルー」を使っている私は馬鹿なのか・・・？ 指標について、自分なりの理解をしているのだと思います。私にとってのインジケーターとは、時間によって何らかの可変値を生み出すことができるオブジェクトです。実は、普通のローソク足チャートの価格も指標になるのです。でも、あなたにとっては別のものなんですね...。その結果、私たちの理解も違ってきます。本質的に indicator = 何かの変化を示す道具（ツール）。 その意味で、ATPは指標となる。 チャートを見ると、このインジケータは最も正確であり（つまり、このインジケータは 単体のインジケータではなく、ポジションのインジケータである）、マーケットでそれを維持する必要があることに気がつくでしょう。 my respect Vasiliy Sokolov 2017.08.11 10:48 #62 Я не вижу особой разницы - как я понимаю, WS (WareStore, вероятно ?) - это все тот же мой дата-провайдер.WorkSymbolの 略称です。この短い略称は、この対象が頻繁に言及されるため、あえて選んだものです。WSオブジェクトの初期化には、何らかの前段階が必要なのではと推測しています。WS は CSymbol オブジェクトのインスタンスで、コンストラクタはデフォルトで現在の Symbol() シンボルを使用します。そのため、WSは外部からの初期化を必要としない。ストラテジークラスと一緒に作成されるだけです。EAには、異なるシンボルや異なる時間枠の多くの異なるコンテナが存在する可能性があります。データ提供者の思想により、重複しないように配慮しています。現実には、すべての時系列がそこに格納され、コンテナは必要なものを指すだけだからです。その結果、1つのメガクラスカーネルができ、エキスパートクラスがそれにアクセスする。MetaTraderカーネルとその数百の関数があり、それにアクセスする場合、基本的なMQLとどのように違うのでしょうか？MT4-5自体をデータプロバイダーと考え、我々のクラスはアクセスを提供するためだけに使用されるとすると、オープン価格への言及によると、1つの値に対してCopyOpen()関数を呼び出さなければならないことがわかりますが、私には無理があるように思われます。その通りです。このようなアピールによってのみ、データ表現の統一と状態の完全な同期が保証されるのである。見積書の更新作業も必要なく（忘れることもある）、データ保存の仲介をする際にどうしても発生する、追加のトグルスイッチを何個も使う必要もないのです。要求されたデータと一致するデータベースを検索する必要がない。私のEAがそうなら。Trade.SellLimit(WS.High[1]);そうすれば、取引環境がどのように更新されても、WS.High[1]が以前の極値を返すことが保証されます。確かに、毎回CopyHighを呼び出して doubleの1つの値をコピーするのはコストがかかりすぎますが、信頼性は100％です。カバークラスはデータを保存せず、システム関数の呼び出しを渡すだけなので、保存されたデータが現在の環境に対応しない、という事態は起こりえないのです。また、プログラムのどの場所でも、すべての変数に完全なグローバルアクセスを与えるのは非常に無理があると思います。逆に、プログラムのそれぞれの場所で、あるアクションに必要な構造体やデータだけにアクセスできるようにすることを心がけています。それ以外のものは、アクセスできないようにしなければなりません。データ提供者の思想は、このアクセスを制御することを可能にするだけである。ゲオルグ 実は、このグローバルアクセスはすでに実現しているんですね。誰もがアクセスする大きなスーパークラス・プロバイダーが1つあるのです。これは、オブジェクト（指標、時系列など）の一つの大きなグローバルなプールで、OOPのラッパーで収集されています。つまり、データプロバイダーの例では、OOPはフィクションになってしまったのです。形式的には存在するが、現実には存在しない。 Georgiy Merts 2017.08.11 12:22 #63 Vasiliy Sokolov:ゲオルグ 実は、このグローバルアクセスはすでに作ってあるんですね。超一流のプロバイダーが1社あり、そこに誰もがアクセスできるのです。これは、OOPのラッパーで組み立てられたオブジェクト（指標、時系列など）の1つの大きなグローバルなプールです。つまり、データプロバイダーの例では、OOPはフィクションになってしまったのです。形式的にはあるのですが、現実にはないのです。いや、データプロバイダにバッファを置いたときと、CopyXXXで毎回データを取得したときの実行速度を比較したのですが、バッファへのアクセスが何倍も速くなったのです。そのため、バッファに落ち着きました。データプロバイダーは、このバッファを一元管理するストレージに過ぎません。 確かに、「レイヤー」と呼ばれるデータ提供者の存在は、データの非同期化を招く危険性があります。しかし、今のところ、そのような問題に遭遇したことはありませんが、データプロバイダーはかなり明確に速度を保存しています。実は、このテストはすでに多くの人が行っていたようで、ティックを処理するときに、毎回ターミナルにデータを取りに行くよりも、一度データをコピーして使った方が得だということがすべて判明したのです。 今は違うの？そして、各ダブル値に対してCopyXXXを介して何度も呼び出す速度は、全範囲に対して一度に呼び出す速度と同じであり、その後 - 値のバッファに呼び出す？ Vasiliy Sokolov 2017.08.11 13:13 #64 George Merts:そうではなく、Data Providerにバッファを置いたとき、あるいはCopyXXXで毎回データを受信したときの速度を比較したのです。そのため、バッファに落ち着きました。データプロバイダーは、このバッファを一元管理するストレージに過ぎません。 確かに、「レイヤー」と呼ばれるデータ提供者の存在は、データの非同期化を招く危険性があります。しかし、今のところ、そのような問題に遭遇したことはありませんが、データプロバイダーはかなり明確に速度を保存しています。実は、このテストはすでに多くの人が行っていると思うのですが、ティック処理の際、いちいち端末にデータを取りに行くよりも、一度データをコピーして使った方がお得だということを、皆さんから教えていただきました。 今は違うの？そして、各ダブル値に対するCopyXXX経由の呼び出し回数の速度は、全範囲に対して一度に呼び出した後、-値のバッファへの呼び出しの速度と同じなのでしょうか？間違いなく、CopyBufferを常に呼び出すよりも、EA内部のメモリ（日付プロバイダ）にすべての相場情報を一度にコピーして、そこから値を呼び出す方がはるかに高速です。しかし、それは国家単位のシステムの代償でもあるのです。基本的に、EAや スクリプトを書くという私たちの領域全体は、状態をベースとしたシステムのプログラミングです：注文があり、その処理ルールを処理します。注文はない。その開封の条件を確認するのだ。CopyBufferに関しては、引用符の大きなチャンクをコピーして性能向上を測定することは、合成テストでのみ可能です。実際には、90％のケースで、Expert Advisorは、すべてのティックの最後のバー、または新しいバーを開く瞬間に動作します。したがって、最後のバーのデータが常に要求され、最後のバーをキャッシュにコピーするCopyBuffer関数が常時呼び出されています。生産性の唯一の真の向上は、Expert Advisorが最後のN本のバーを必要とする場合であり、Nの数は1よりはるかに大きい。しかし、最後のN小節は何を要求しているのでしょうか？スライディングウィンドウでの作業です（Expert Advisorの全作業の99％）。そして、スライドウィンドウ、その本質は円形バッファです。したがって、最後のN本のバーを要求する場合、実際には、最後の1本のバーだけを更新または追加する必要があります。つまり、データブロックのコピーというのはとてもいい話なのですが、そのために作られた分野ではうまく機能せず、リングバッファは非常にうまく機能するのです。これで、私のCSymbolは正しいインデックスを渡すだけで動作するようになりました。しかし、最後のバーN本をキャッシュするようにアップグレードすることは可能で、N本は最大要求インデックスに応じてCsymbol自身が選択します。そして、外部からの変更なしに、CSymbolはいくつかのタスクで、CopyBufferの永久的な呼び出しよりも何倍も速く動作するようになります。これがOOPの力です。追加のラッパーを使用することによる一定のオーバーヘッドが発生した後、適応的なアルゴリズムによってメモリやCPU時間の使用を劇的に削減することができるようになり、質的な飛躍がもたらされます。 Реter Konow 2017.08.11 17:23 #65 Gregory Kovalenko: こんにちは。コードの量が増えてくると、時に難しくなり、混乱することもあります。膨大な行数のEAコードを見たことがありますが、複雑なEAはどのように設計されているのでしょうか、このような複雑なアルゴリズムを扱うためのツールやテクニックはあるのでしょうか？私は何百行にも及ぶ巨大なコードブロックを書いています。ほぼノーコメント。OOPなし。コードはロシア語です。すべてが非常に効率的に機能しています。100個くらいのファイルがつながっていますが、プログラム内の向きは特に問題ありません。おそらく、慣れてしまって、ずっと前に全部覚えてしまったからだと思います。メインはプログラムを知り、理解することであり、それ以外は二の次である。イミフ。 Vasiliy Sokolov 2017.08.11 17:44 #66 Реter Konow: 数百行に及ぶ巨大なコードブロックを書くこと。ほぼノーコメント。OOPなし。ロシア語のコード。すべてが非常に効率的に機能しています。100個くらいのファイルがつながっているのですが、プログラム内の方向性に悩むことはありません。おそらく、慣れてしまって、ずっと前に全部覚えてしまったからだと思います。メインはプログラムを知り、理解することであり、それ以外は二の次である。私の感覚では、自分のプログラムを知ることが一番大事で、あとは二の次という感じです。 1CからMQLになったのでしょうか？ Реter Konow 2017.08.11 18:01 #67 Vasiliy Sokolov: 1CからMQLになったのでしょうか？私は独学です。初めて学んだプログラミング言語は「MQL4」でした。その後、C#やC++で少し練習しました。1Cは聞いたことがない。何ですか？ Georgiy Merts 2017.08.11 18:35 #68 Vasiliy Sokolov:CopyBufferに関しては、引用符の大きなチャンクをコピーして性能向上を測定することは、合成テストでのみ可能です。実際には、90％のケースで、Expert Advisorは、すべてのティックの最後のバー、または新しいバーを開く瞬間に動作します。したがって、最後のバーのデータが常に要求され、最後のバーをキャッシュにコピーするCopyBufferの呼び出しが常に存在する。そのため、「合成テスト」ではスピードが必要です。ストラテジーテスターで バリアントを検索する際には、スピードが重要になります。私にとってのストラテジーテスターは、スピードが求められる「ボトルネック」なのです。 ただ本当に実作業では、毎回CopyXXXでデータに直接アクセスするスピードで十分です。しかし、テスターのプログにとって、スピードの差は非常に重要です。 Vladimir Karputov 2017.08.11 19:13 #69 このトピックに関係のないコメントは、「OOP vs 手続き型プログラミング」に移動しました。 Vasiliy Sokolov 2017.08.14 13:56 #70 George Merts:しかし、「合成テスト」でこそスピードが求められる。ストラテジーテスターで オプションを試すとき、スピードが重要になるのだ。私にとってのストラテジーテスターは、スピードが要求されるところでは「ボトルネック」になっています。 ただ本当に実作業では、毎回CopyXXXでデータに直接アクセスするスピードで十分です。しかし、テスターのプログラムでは、速度の違いは非常に重要です。簡単に説明すると、データプロバイダのベースにはCopyXXX関数があり、最後の文字をコピーするようになっています。私のCsymbolのベースにはCopyXXXもあり、同じ最後の文字をコピーしています。どちらの機能も遅い。したがって、CopyXXXの呼び出しをバイパスすることができないので、あなたのコードも私のコードも遅いのです。しかし、私のコードはよりシンプルで小さくなっています。では、なぜCopyXXXXXの上にこのような多層ビルを建てるのか、それはCopyXXXXの問題そのものを解決しないのであれば、どうすればいいのでしょうか？ 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ATRは指標としてカウントされない」ってどういうこと？
また、どうして「エントリーシグナルとしてふさわしくない」のでしょうか？このインジケーターだけで「ボラティリティ・ブレイクスルー」を使っている私は馬鹿なのか・・・？
指標について、自分なりの理解をしているのだと思います。私にとってのインジケーターとは、時間によって何らかの可変値を生み出すことができるオブジェクトです。実は、普通のローソク足チャートの価格も指標になるのです。でも、あなたにとっては別のものなんですね...。その結果、私たちの理解も違ってきます。
本質的に
indicator = 何かの変化を示す道具（ツール）。
その意味で、ATPは指標となる。
チャートを見ると、このインジケータは最も正確であり（つまり、このインジケータは 単体のインジケータではなく、ポジションのインジケータである）、マーケットでそれを維持する必要があることに気がつくでしょう。
my respect
Я не вижу особой разницы - как я понимаю, WS (WareStore, вероятно ?) - это все тот же мой дата-провайдер.
WorkSymbolの 略称です。この短い略称は、この対象が頻繁に言及されるため、あえて選んだものです。
WSオブジェクトの初期化には、何らかの前段階が必要なのではと推測しています。
WS は CSymbol オブジェクトのインスタンスで、コンストラクタはデフォルトで現在の Symbol() シンボルを使用します。そのため、WSは外部からの初期化を必要としない。ストラテジークラスと一緒に作成されるだけです。
EAには、異なるシンボルや異なる時間枠の多くの異なるコンテナが存在する可能性があります。データ提供者の思想により、重複しないように配慮しています。現実には、すべての時系列がそこに格納され、コンテナは必要なものを指すだけだからです。
その結果、1つのメガクラスカーネルができ、エキスパートクラスがそれにアクセスする。MetaTraderカーネルとその数百の関数があり、それにアクセスする場合、基本的なMQLとどのように違うのでしょうか？
MT4-5自体をデータプロバイダーと考え、我々のクラスはアクセスを提供するためだけに使用されるとすると、オープン価格への言及によると、1つの値に対してCopyOpen()関数を呼び出さなければならないことがわかりますが、私には無理があるように思われます。
その通りです。このようなアピールによってのみ、データ表現の統一と状態の完全な同期が保証されるのである。見積書の更新作業も必要なく（忘れることもある）、データ保存の仲介をする際にどうしても発生する、追加のトグルスイッチを何個も使う必要もないのです。要求されたデータと一致するデータベースを検索する必要がない。私のEAがそうなら。
そうすれば、取引環境がどのように更新されても、WS.High[1]が以前の極値を返すことが保証されます。確かに、毎回CopyHighを呼び出して doubleの1つの値をコピーするのはコストがかかりすぎますが、信頼性は100％です。カバークラスはデータを保存せず、システム関数の呼び出しを渡すだけなので、保存されたデータが現在の環境に対応しない、という事態は起こりえないのです。
また、プログラムのどの場所でも、すべての変数に完全なグローバルアクセスを与えるのは非常に無理があると思います。逆に、プログラムのそれぞれの場所で、あるアクションに必要な構造体やデータだけにアクセスできるようにすることを心がけています。それ以外のものは、アクセスできないようにしなければなりません。データ提供者の思想は、このアクセスを制御することを可能にするだけである。
ゲオルグ 実は、このグローバルアクセスはすでに実現しているんですね。誰もがアクセスする大きなスーパークラス・プロバイダーが1つあるのです。これは、オブジェクト（指標、時系列など）の一つの大きなグローバルなプールで、OOPのラッパーで収集されています。つまり、データプロバイダーの例では、OOPはフィクションになってしまったのです。形式的には存在するが、現実には存在しない。
ゲオルグ 実は、このグローバルアクセスはすでに作ってあるんですね。超一流のプロバイダーが1社あり、そこに誰もがアクセスできるのです。これは、OOPのラッパーで組み立てられたオブジェクト（指標、時系列など）の1つの大きなグローバルなプールです。つまり、データプロバイダーの例では、OOPはフィクションになってしまったのです。形式的にはあるのですが、現実にはないのです。
いや、データプロバイダにバッファを置いたときと、CopyXXXで毎回データを取得したときの実行速度を比較したのですが、バッファへのアクセスが何倍も速くなったのです。そのため、バッファに落ち着きました。データプロバイダーは、このバッファを一元管理するストレージに過ぎません。
確かに、「レイヤー」と呼ばれるデータ提供者の存在は、データの非同期化を招く危険性があります。しかし、今のところ、そのような問題に遭遇したことはありませんが、データプロバイダーはかなり明確に速度を保存しています。実は、このテストはすでに多くの人が行っていたようで、ティックを処理するときに、毎回ターミナルにデータを取りに行くよりも、一度データをコピーして使った方が得だということがすべて判明したのです。
今は違うの？そして、各ダブル値に対してCopyXXXを介して何度も呼び出す速度は、全範囲に対して一度に呼び出す速度と同じであり、その後 - 値のバッファに呼び出す？
そうではなく、Data Providerにバッファを置いたとき、あるいはCopyXXXで毎回データを受信したときの速度を比較したのです。そのため、バッファに落ち着きました。データプロバイダーは、このバッファを一元管理するストレージに過ぎません。
確かに、「レイヤー」と呼ばれるデータ提供者の存在は、データの非同期化を招く危険性があります。しかし、今のところ、そのような問題に遭遇したことはありませんが、データプロバイダーはかなり明確に速度を保存しています。実は、このテストはすでに多くの人が行っていると思うのですが、ティック処理の際、いちいち端末にデータを取りに行くよりも、一度データをコピーして使った方がお得だということを、皆さんから教えていただきました。
今は違うの？そして、各ダブル値に対するCopyXXX経由の呼び出し回数の速度は、全範囲に対して一度に呼び出した後、-値のバッファへの呼び出しの速度と同じなのでしょうか？
間違いなく、CopyBufferを常に呼び出すよりも、EA内部のメモリ（日付プロバイダ）にすべての相場情報を一度にコピーして、そこから値を呼び出す方がはるかに高速です。しかし、それは国家単位のシステムの代償でもあるのです。基本的に、EAや スクリプトを書くという私たちの領域全体は、状態をベースとしたシステムのプログラミングです：注文があり、その処理ルールを処理します。注文はない。その開封の条件を確認するのだ。
CopyBufferに関しては、引用符の大きなチャンクをコピーして性能向上を測定することは、合成テストでのみ可能です。実際には、90％のケースで、Expert Advisorは、すべてのティックの最後のバー、または新しいバーを開く瞬間に動作します。したがって、最後のバーのデータが常に要求され、最後のバーをキャッシュにコピーするCopyBuffer関数が常時呼び出されています。
生産性の唯一の真の向上は、Expert Advisorが最後のN本のバーを必要とする場合であり、Nの数は1よりはるかに大きい。しかし、最後のN小節は何を要求しているのでしょうか？スライディングウィンドウでの作業です（Expert Advisorの全作業の99％）。そして、スライドウィンドウ、その本質は円形バッファです。したがって、最後のN本のバーを要求する場合、実際には、最後の1本のバーだけを更新または追加する必要があります。つまり、データブロックのコピーというのはとてもいい話なのですが、そのために作られた分野ではうまく機能せず、リングバッファは非常にうまく機能するのです。
これで、私のCSymbolは正しいインデックスを渡すだけで動作するようになりました。しかし、最後のバーN本をキャッシュするようにアップグレードすることは可能で、N本は最大要求インデックスに応じてCsymbol自身が選択します。そして、外部からの変更なしに、CSymbolはいくつかのタスクで、CopyBufferの永久的な呼び出しよりも何倍も速く動作するようになります。これがOOPの力です。追加のラッパーを使用することによる一定のオーバーヘッドが発生した後、適応的なアルゴリズムによってメモリやCPU時間の使用を劇的に削減することができるようになり、質的な飛躍がもたらされます。
こんにちは。
私は何百行にも及ぶ巨大なコードブロックを書いています。ほぼノーコメント。OOPなし。コードはロシア語です。すべてが非常に効率的に機能しています。100個くらいのファイルがつながっていますが、プログラム内の向きは特に問題ありません。おそらく、慣れてしまって、ずっと前に全部覚えてしまったからだと思います。メインはプログラムを知り、理解することであり、それ以外は二の次である。イミフ。
数百行に及ぶ巨大なコードブロックを書くこと。ほぼノーコメント。OOPなし。ロシア語のコード。すべてが非常に効率的に機能しています。100個くらいのファイルがつながっているのですが、プログラム内の方向性に悩むことはありません。おそらく、慣れてしまって、ずっと前に全部覚えてしまったからだと思います。メインはプログラムを知り、理解することであり、それ以外は二の次である。私の感覚では、自分のプログラムを知ることが一番大事で、あとは二の次という感じです。
1CからMQLになったのでしょうか？
私は独学です。初めて学んだプログラミング言語は「MQL4」でした。その後、C#やC++で少し練習しました。
1Cは聞いたことがない。何ですか？
CopyBufferに関しては、引用符の大きなチャンクをコピーして性能向上を測定することは、合成テストでのみ可能です。実際には、90％のケースで、Expert Advisorは、すべてのティックの最後のバー、または新しいバーを開く瞬間に動作します。したがって、最後のバーのデータが常に要求され、最後のバーをキャッシュにコピーするCopyBufferの呼び出しが常に存在する。
そのため、「合成テスト」ではスピードが必要です。ストラテジーテスターで バリアントを検索する際には、スピードが重要になります。私にとってのストラテジーテスターは、スピードが求められる「ボトルネック」なのです。
ただ本当に実作業では、毎回CopyXXXでデータに直接アクセスするスピードで十分です。しかし、テスターのプログにとって、スピードの差は非常に重要です。
しかし、「合成テスト」でこそスピードが求められる。ストラテジーテスターで オプションを試すとき、スピードが重要になるのだ。私にとってのストラテジーテスターは、スピードが要求されるところでは「ボトルネック」になっています。
ただ本当に実作業では、毎回CopyXXXでデータに直接アクセスするスピードで十分です。しかし、テスターのプログラムでは、速度の違いは非常に重要です。
簡単に説明すると、データプロバイダのベースにはCopyXXX関数があり、最後の文字をコピーするようになっています。私のCsymbolのベースにはCopyXXXもあり、同じ最後の文字をコピーしています。どちらの機能も遅い。したがって、CopyXXXの呼び出しをバイパスすることができないので、あなたのコードも私のコードも遅いのです。しかし、私のコードはよりシンプルで小さくなっています。では、なぜCopyXXXXXの上にこのような多層ビルを建てるのか、それはCopyXXXXの問題そのものを解決しないのであれば、どうすればいいのでしょうか？