MT4からMT5への乗り換えの問題。正確には、MT5で一部のアルゴリズムをerrなしで実行できないことです。 - ページ 7 123456789101112 新しいコメント Eugeni Neumoin 2019.07.30 16:42 #61 Andrey Khatimlianskii:ナンセンスなのは、すでに端末にあるデータのコピーを 自分で整理することです。 そんなくだらないことがたくさんあります。2005年8月にMT4がリリースされたとき、ZigZagインジケータが登場しました。そこには多くの誤りがある。ある例では、その時の高速市場に端末をぶら下げることができる。そして、小節の最小値／最大値とは関係なく、空中で極値を表示することがよくありました。 ある投稿で、このジグザグの開発者が、これは--（これ以上感情を込めないでください）ファジーロジックの現れだ......と言っていました。 しかし、MT4の発売から14年が経過した現在まで、ジグザグのインジケータには、Deviationというパラメータがあり、これは何のアクションも起こしません。つまり、このパラメータをどのような値に設定しても、チャート上のジグザグの描画は変わりません。 多くの番組がこの指標に基づいています。ほとんどの開発者は、このパラメータをプログラムに含めています。無駄なパラメータです。開発者は、それに対して素晴らしい無関心さを示しています。ちなみにこのパラメータは、コンピュータのリソースを食う。 このほかにも、さまざまな場面でそのような瞬間がありました。 Eugeni Neumoin 2019.07.30 16:52 #62 続けます。 宙に浮いたジグザグの極限は、時系列にアクセスしたときのものとまったく同じ性質を持っているのです。 ただ、MT4ではタイムスリールへのアクセスは否定されませんでした。そこでは一部の機能が正しく動作しませんでした（今もそうなのかもしれませんが）。自分の社内用に解説してもらいました。また、自分で強制的にやったこともあります。そして、エラーもなく、CPUの負荷もなく、すべてが動き始めたのです。チャート上に数十本のジグザグを出力しても端末がハングアップしない...。 Artyom Trishkin 2019.07.30 17:15 #63 Andrey Khatimlianskii: すべてがうまくいくのであれば、この問題で100万ものトピックが割かれることはないでしょう。 ただ、そのロジックは、端末ユーザーが扱うには複雑なものであることが判明しました。 そして、エラーはあるはずなのですが、開発者はそれを探す時間がなく、ユーザーも誰もそれを再現して証明しようとはしません。 アンドレイ まずは、今あるものから始めてみてはどうだろう。そして、あなたの言っていることがあるのだから、それを話した方がいいのか、それとも避けた方がいいのか？ 私は十分な問題があると思いますが、ブランチからブランチへと話をするよりも（それも有効です-時には修正されることもあります）、しかしワークアラウンドを行うことです。 そして、必要な時系列を完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。そして、いつでも利用できるタイムスリップから必要なデータを受け取ること。そして、新しいデータで補完するのみ。必要な時に、必要な分だけ、ゆっくりと。 そうすることで、少なくとも物事は前に進むのです。そして、その会話は、何もすることがないときに、後回しにすることができるのです。 Artyom Trishkin 2019.07.30 17:18 #64 Eugeni Neumoin: 続けます。 宙に浮いたジグザグの極限は、時系列にアクセスしたときのものとまったく同じ性質を持っているのです。 ただ、MT4ではタイムスリールへのアクセスは否定されませんでした。そこでは一部の機能が正しく動作しませんでした（今もそうなのかもしれませんが）。自分の社内用に解説してもらいました。また、自分で強制的にやったこともあります。そして、エラーもなく、CPUの負荷もなく、すべてが動き始めたのです。チャートに数十本のジグザグを出力してもターミナルがハングアップしない...。 タイムシリーズへのアクセスが拒否された場合は、同期の段階であることを意味します。次のティックまで待つ必要があります。 このような場合、タイムスケールをキャッシュしておくと、いつでも待たずに、最初のリクエストで利用できるようになります。 インジケータ起動時、つまり「同期待ち」の時間があるときや、次の時系列のデータ要求の待ち時間にキャッシュします。 Andrey Khatimlianskii 2019.07.30 17:43 #65 Artyom Trishkin: アンドレイ 私は、今あるものを使っていこうと提案しているんです。そして、話している内容があるので、それを話すのがいいのか、回りくどいのがいいのか。 私は十分な問題があると思いますが、ブランチからブランチへと話をするよりも（それも有効です-時には修正されることもあります）、しかしワークアラウンドを行うことです。 そこで私は、必要な時系列を完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。さらに、必要なデータをいつでも入手可能なタイムスリップから受信することです。そして、新しいデータで補完するのみ。同時に、利用可能なときに - 急がず、必要な瞬間にとは限らない。 そうすることで、少なくとも物事は前に進むのです。そして会話は、何もすることがないときに、後回しにすることができるのです。 それならもう、開発者が修正できるような再現性の高い例を作った方が効果的です。 Eugeni Neumoin 2019.07.30 18:09 #66 Artyom Trishkin: アンドレイ 私は、今あるものを使っていこうと提案しているんです。そして、話している内容があるので、それを話すのがいいのか、回りくどいのがいいのか。 問題は十分にあると思いますが、ブランチからブランチへと話をするよりも（それも有効です-時には修正されることもあります）、ワークアラウンドをやってください。 そして、必要な時系列を完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。そして、必要なデータをいつでも入手可能なタイムスリップから受け取ること。そして、新しいデータで補完するのみ。同時に、利用可能なときに - 急がず、必要な瞬間にとは限らない。 そうすることで、少なくとも物事は前に進むのです。そして、その会話は、何もすることがないときに、後回しにすることができるのです。 そして、なぜ端末の開発者はそれができないのでしょうか？とにかく更新の瞬間に時系列にアクセスすることができない。この、仮にキャッシュされた履歴に誰でもアクセスできるようにするのです。どんな違いがあるのでしょうか？つまり、アクセスが途絶えることがないようにするためです。まあ、ゼロバーで多少の遅れは出るかもしれませんが。残りの履歴はいつでも見ることができるのです。 Igor Makanu 2019.07.30 18:12 #67 Artyom Trishkin: 私は、必要な時系列が完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。そして、いつでも利用できるタイムスリップから必要なデータを取得するのです。そして、新しいデータで補完するのみ。 新しいティックが来ても、同期が終わっていない...そして、接続に失敗する。 ZS: そうなんです、なぜそうするのか？- 私は生活の中でどのように多くを知らない、私は1つの携帯電話、1台の車、さらには1つだけの財布を持っていますが、生活の中で多くの場合？- テープレコーダー3台、外国製フィルムカメラ3台、国産タバコケース3個、ジャケット...スエード...3個」。ジャケット」 ))) アルチョム・トリシキン タイムスリップへのアクセスが拒否された場合、同期していることを意味します。次のティックまで待つ必要があります。 おっしゃるとおりです！しかし、MQLプログラムを任意の場所で停止し、次のティックまでターミナルを終了する必要があります...私は定期的にDelphiの "Abort() or Halt()" のようなものを提案します - 1回時系列のアクセスエラーを取得 - それは重要なエラーで、何度も処理する意味がありません - とにかく、ターミナルはMQLプログラムとの相互作用を調整できなくなるまで "無駄" ))) です。 SZZ: このエラー（時系列アクセスエラー）は私が作ったわけではなく、ターミナルが作ったものです。- 可能ですが、どのようにソースコードを書いていくのか、明確な計画（アルゴリズム）が必要です......。また、既成の機能（クラス）を追加してソースコードを洗練させた場合は？- つまり、毎回、中身を考えて...。大規模なプロジェクトでは、すべてを提供するのは一般に時間のかかる作業です。 Eugeni Neumoin 2019.07.30 19:07 #68 Igor Makanu:...大規模なプロジェクトでは、時間のかかる作業だと思います。 14年かけて作られたプログラムを、新しい設計手法で翻訳することは、足元をすくわれるより簡単です。また、複数のリンクのデバッグも大変です。タイムフレームへのアクセスを確認すると、アクセスがない場合は深刻な遅延が発生します。グラフィックの 自動コンストラクションが 有効になっていれば問題ないのですが。オートマチックモードでのリビルドは、あまりない現象です。ここでは、遅れに気づかないかもしれません。しかし、この場合も時系列へのアクセスが途絶えると、グラフの構成が切り捨てられた形で出力されることがある。作る時間がある要素もあれば、ない要素もある...。あるいは、フラクタル濾過は、あるtfを切り捨てる。 *** Igor Makanu 2019.07.30 19:21 #69 Eugeni Neumoin: 14年かけて作られたプログラムを、新しい設計手法で翻訳することは、足元をすくわれるより簡単です。また、複数のリンクのデバッグも大変です。タイムフレームへのアクセスを確認すると、アクセスがない場合は深刻な遅延が発生します。グラフィックの 自動コンストラクションが 有効になっていれば問題ないのですが。オートマチックモードでのリビルドは、あまりない現象です。ここでは、遅れに気づかないかもしれません。 しかし、問題はグラフィカルなインターフェースで調整を行う場合です。ユーザーがボタンを押すと...は次のティックを待たねばならない。あるいは、ユーザーが希望する反応が起きるまで何度もボタンを押す。ユーザーの反応は...？-*** また、MT4ではそのような問題はありません。 よく理解できたので、議論をサポートすることにしました。 iClose()...iXXX()関数で時系列にアクセス - すごい! また、U.V.開発者は、端末が履歴データ（OHLC）にアクセスする準備ができている場合にのみMQLプログラムにティックを与え、そうでない場合はティックを与えないようにするプリコンパイラ指令を追加する必要があります。 .... この問題は、MT5の登場以来、MQLプログラム内のチェックのレベルでしか解決されていませんが、これは時間のかかるプロセスであり、私の意見では、ユーザーはターミナルが問題なく、いつでも、どのコードセクションでも保証された時系列データを受け取ることを期待しています Artyom Trishkin 2019.07.30 19:30 #70 Igor Makanu: 新しいティックが来て、同期が終わらない...そして接続に失敗する。 ZS: そうなんです、なぜそうするのか？- 私は生活の中でどのように多くを知らない、私は1つの携帯電話、1台の車、さらには1つだけの財布を持っていますが、生活の中で多くの場合？- テープレコーダー3台、外国製フィルムカメラ3台、国産タバコケース3個、ジャケット...スエード...3個」。ジャケット」 ))) しかし、MQLプログラムは任意の場所で計算を停止し、次のティックまでターミナルを終了しなければなりません...私は時々Delphiの「Abort()またはHalt()」のようなものを提案します - あなたはタイムシリーズにアクセスして1つのエラーを得る - それは何度も処理の意味がない重要なエラー です - とにかく、ターミナルはMQLプログラムとの相互作用を確立するまで「役に立たない」 ))) 。 SZZ: このエラー（時系列アクセスエラー）は私が作ったわけではなく、ターミナルが作ったものです。- 可能ですが、どのようにソースコードを書いていくのか、明確な計画（アルゴリズム）が必要です ...また、既成の機能（クラス）を追加してソースコードを洗練させた場合は？- つまり、毎回、中身を考えて...。...大きなプロジェクトでは、時間のかかる作業です。 マウスクリックでプログラムが実行される場合、アクセスがあろうがなかろうが関係なく、反応しなければならないのです。何でもかんでも悪いと書くのもどうかと思いますが、この場合、自分専用のキャッシュを持ち、そこからいつでもオンデマンドでアクセスできるようにした方が良いのです。 マウスクリックで長い時間かけて計算されたヒストリカルデータに何かを与える代わりに、「ちょっと一服していってくれ、今必要ない現在のデータを取得して、タイムラインを再構築するから」と言うようなプログラムを想像してみてください...。 何はともあれ、今あるものでやりくりするのであれば、キャッシュの中身を出し、時系列アクセスを解除してから作り直した方がよいでしょう。 123456789101112 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ナンセンスなのは、すでに端末にあるデータのコピーを 自分で整理することです。
そんなくだらないことがたくさんあります。2005年8月にMT4がリリースされたとき、ZigZagインジケータが登場しました。そこには多くの誤りがある。ある例では、その時の高速市場に端末をぶら下げることができる。そして、小節の最小値／最大値とは関係なく、空中で極値を表示することがよくありました。
ある投稿で、このジグザグの開発者が、これは--（これ以上感情を込めないでください）ファジーロジックの現れだ......と言っていました。
しかし、MT4の発売から14年が経過した現在まで、ジグザグのインジケータには、Deviationというパラメータがあり、これは何のアクションも起こしません。つまり、このパラメータをどのような値に設定しても、チャート上のジグザグの描画は変わりません。
多くの番組がこの指標に基づいています。ほとんどの開発者は、このパラメータをプログラムに含めています。無駄なパラメータです。開発者は、それに対して素晴らしい無関心さを示しています。ちなみにこのパラメータは、コンピュータのリソースを食う。
このほかにも、さまざまな場面でそのような瞬間がありました。
続けます。
宙に浮いたジグザグの極限は、時系列にアクセスしたときのものとまったく同じ性質を持っているのです。
ただ、MT4ではタイムスリールへのアクセスは否定されませんでした。そこでは一部の機能が正しく動作しませんでした（今もそうなのかもしれませんが）。自分の社内用に解説してもらいました。また、自分で強制的にやったこともあります。そして、エラーもなく、CPUの負荷もなく、すべてが動き始めたのです。チャート上に数十本のジグザグを出力しても端末がハングアップしない...。
すべてがうまくいくのであれば、この問題で100万ものトピックが割かれることはないでしょう。
ただ、そのロジックは、端末ユーザーが扱うには複雑なものであることが判明しました。
そして、エラーはあるはずなのですが、開発者はそれを探す時間がなく、ユーザーも誰もそれを再現して証明しようとはしません。
アンドレイ まずは、今あるものから始めてみてはどうだろう。そして、あなたの言っていることがあるのだから、それを話した方がいいのか、それとも避けた方がいいのか？
私は十分な問題があると思いますが、ブランチからブランチへと話をするよりも（それも有効です-時には修正されることもあります）、しかしワークアラウンドを行うことです。
そして、必要な時系列を完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。そして、いつでも利用できるタイムスリップから必要なデータを受け取ること。そして、新しいデータで補完するのみ。必要な時に、必要な分だけ、ゆっくりと。
そうすることで、少なくとも物事は前に進むのです。そして、その会話は、何もすることがないときに、後回しにすることができるのです。
続けます。
宙に浮いたジグザグの極限は、時系列にアクセスしたときのものとまったく同じ性質を持っているのです。
ただ、MT4ではタイムスリールへのアクセスは否定されませんでした。そこでは一部の機能が正しく動作しませんでした（今もそうなのかもしれませんが）。自分の社内用に解説してもらいました。また、自分で強制的にやったこともあります。そして、エラーもなく、CPUの負荷もなく、すべてが動き始めたのです。チャートに数十本のジグザグを出力してもターミナルがハングアップしない...。
タイムシリーズへのアクセスが拒否された場合は、同期の段階であることを意味します。次のティックまで待つ必要があります。
このような場合、タイムスケールをキャッシュしておくと、いつでも待たずに、最初のリクエストで利用できるようになります。
インジケータ起動時、つまり「同期待ち」の時間があるときや、次の時系列のデータ要求の待ち時間にキャッシュします。
アンドレイ 私は、今あるものを使っていこうと提案しているんです。そして、話している内容があるので、それを話すのがいいのか、回りくどいのがいいのか。
私は十分な問題があると思いますが、ブランチからブランチへと話をするよりも（それも有効です-時には修正されることもあります）、しかしワークアラウンドを行うことです。
そこで私は、必要な時系列を完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。さらに、必要なデータをいつでも入手可能なタイムスリップから受信することです。そして、新しいデータで補完するのみ。同時に、利用可能なときに - 急がず、必要な瞬間にとは限らない。
そうすることで、少なくとも物事は前に進むのです。そして会話は、何もすることがないときに、後回しにすることができるのです。
それならもう、開発者が修正できるような再現性の高い例を作った方が効果的です。
アンドレイ 私は、今あるものを使っていこうと提案しているんです。そして、話している内容があるので、それを話すのがいいのか、回りくどいのがいいのか。
問題は十分にあると思いますが、ブランチからブランチへと話をするよりも（それも有効です-時には修正されることもあります）、ワークアラウンドをやってください。
そして、必要な時系列を完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。そして、必要なデータをいつでも入手可能なタイムスリップから受け取ること。そして、新しいデータで補完するのみ。同時に、利用可能なときに - 急がず、必要な瞬間にとは限らない。
そうすることで、少なくとも物事は前に進むのです。そして、その会話は、何もすることがないときに、後回しにすることができるのです。
そして、なぜ端末の開発者はそれができないのでしょうか？とにかく更新の瞬間に時系列にアクセスすることができない。この、仮にキャッシュされた履歴に誰でもアクセスできるようにするのです。どんな違いがあるのでしょうか？つまり、アクセスが途絶えることがないようにするためです。まあ、ゼロバーで多少の遅れは出るかもしれませんが。残りの履歴はいつでも見ることができるのです。
私は、必要な時系列が完全に利用可能になった時点でキャッシュする、という良い選択肢を提案しました。そして、いつでも利用できるタイムスリップから必要なデータを取得するのです。そして、新しいデータで補完するのみ。
新しいティックが来ても、同期が終わっていない...そして、接続に失敗する。
ZS: そうなんです、なぜそうするのか？- 私は生活の中でどのように多くを知らない、私は1つの携帯電話、1台の車、さらには1つだけの財布を持っていますが、生活の中で多くの場合？- テープレコーダー3台、外国製フィルムカメラ3台、国産タバコケース3個、ジャケット...スエード...3個」。ジャケット」 )))
タイムスリップへのアクセスが拒否された場合、同期していることを意味します。次のティックまで待つ必要があります。
おっしゃるとおりです！しかし、MQLプログラムを任意の場所で停止し、次のティックまでターミナルを終了する必要があります...私は定期的にDelphiの "Abort() or Halt()" のようなものを提案します - 1回時系列のアクセスエラーを取得 - それは重要なエラーで、何度も処理する意味がありません - とにかく、ターミナルはMQLプログラムとの相互作用を調整できなくなるまで "無駄" ))) です。
SZZ: このエラー（時系列アクセスエラー）は私が作ったわけではなく、ターミナルが作ったものです。- 可能ですが、どのようにソースコードを書いていくのか、明確な計画（アルゴリズム）が必要です......。また、既成の機能（クラス）を追加してソースコードを洗練させた場合は？- つまり、毎回、中身を考えて...。大規模なプロジェクトでは、すべてを提供するのは一般に時間のかかる作業です。
14年かけて作られたプログラムを、新しい設計手法で翻訳することは、足元をすくわれるより簡単です。また、複数のリンクのデバッグも大変です。タイムフレームへのアクセスを確認すると、アクセスがない場合は深刻な遅延が発生します。グラフィックの 自動コンストラクションが 有効になっていれば問題ないのですが。オートマチックモードでのリビルドは、あまりない現象です。ここでは、遅れに気づかないかもしれません。しかし、この場合も時系列へのアクセスが途絶えると、グラフの構成が切り捨てられた形で出力されることがある。作る時間がある要素もあれば、ない要素もある...。あるいは、フラクタル濾過は、あるtfを切り捨てる。
***
14年かけて作られたプログラムを、新しい設計手法で翻訳することは、足元をすくわれるより簡単です。また、複数のリンクのデバッグも大変です。タイムフレームへのアクセスを確認すると、アクセスがない場合は深刻な遅延が発生します。グラフィックの 自動コンストラクションが 有効になっていれば問題ないのですが。オートマチックモードでのリビルドは、あまりない現象です。ここでは、遅れに気づかないかもしれません。
しかし、問題はグラフィカルなインターフェースで調整を行う場合です。ユーザーがボタンを押すと...は次のティックを待たねばならない。あるいは、ユーザーが希望する反応が起きるまで何度もボタンを押す。ユーザーの反応は...？-***
また、MT4ではそのような問題はありません。
よく理解できたので、議論をサポートすることにしました。
iClose()...iXXX()関数で時系列にアクセス - すごい!
また、U.V.開発者は、端末が履歴データ（OHLC）にアクセスする準備ができている場合にのみMQLプログラムにティックを与え、そうでない場合はティックを与えないようにするプリコンパイラ指令を追加する必要があります。
....
この問題は、MT5の登場以来、MQLプログラム内のチェックのレベルでしか解決されていませんが、これは時間のかかるプロセスであり、私の意見では、ユーザーはターミナルが問題なく、いつでも、どのコードセクションでも保証された時系列データを受け取ることを期待しています
新しいティックが来て、同期が終わらない...そして接続に失敗する。
ZS: そうなんです、なぜそうするのか？- 私は生活の中でどのように多くを知らない、私は1つの携帯電話、1台の車、さらには1つだけの財布を持っていますが、生活の中で多くの場合？- テープレコーダー3台、外国製フィルムカメラ3台、国産タバコケース3個、ジャケット...スエード...3個」。ジャケット」 )))
しかし、MQLプログラムは任意の場所で計算を停止し、次のティックまでターミナルを終了しなければなりません...私は時々Delphiの「Abort()またはHalt()」のようなものを提案します - あなたはタイムシリーズにアクセスして1つのエラーを得る - それは何度も処理の意味がない重要なエラー です - とにかく、ターミナルはMQLプログラムとの相互作用を確立するまで「役に立たない」 ))) 。
SZZ: このエラー（時系列アクセスエラー）は私が作ったわけではなく、ターミナルが作ったものです。- 可能ですが、どのようにソースコードを書いていくのか、明確な計画（アルゴリズム）が必要です ...また、既成の機能（クラス）を追加してソースコードを洗練させた場合は？- つまり、毎回、中身を考えて...。...大きなプロジェクトでは、時間のかかる作業です。
マウスクリックでプログラムが実行される場合、アクセスがあろうがなかろうが関係なく、反応しなければならないのです。何でもかんでも悪いと書くのもどうかと思いますが、この場合、自分専用のキャッシュを持ち、そこからいつでもオンデマンドでアクセスできるようにした方が良いのです。
マウスクリックで長い時間かけて計算されたヒストリカルデータに何かを与える代わりに、「ちょっと一服していってくれ、今必要ない現在のデータを取得して、タイムラインを再構築するから」と言うようなプログラムを想像してみてください...。
何はともあれ、今あるものでやりくりするのであれば、キャッシュの中身を出し、時系列アクセスを解除してから作り直した方がよいでしょう。