MG4スクリプトとアドバイザーをサポートするテスター - ページ 10 1...34567891011 新しいコメント 削除済み 2014.11.17 15:47 #91 Renat:そんなこと言ってませんよ。この話題には全く触れていませんし、関わるつもりもありません。どうやら、私にはそう思えた。レナートそして、統合されたストップロットやテイクプロフィットは、実はバーチャルな もので、いざという時に市場で執行するために投げ出されるのです。このソリューションには、CS（担保、証拠金）の節約という良い面も あります。 上記の質問を追加しました。 Vasiliy Sokolov 2014.11.17 15:54 #92 Renat:新しいデータアクセス機能は何を提供するのか、なぜそうなるのかを考えてみてください。MetaTrader 4は、履歴の深さが限られており、タイムフレームが分かれており、Open/High/Low/Close/Time[xxx]を介してそのシンボルのバーに直接アクセスできます。このようなダイレクトアクセスは、リソースやCPUコストの面で実装が非常に高価になります。他のExpert Advisorや端末との競合を避けるため、各Expert Advisorはこのデータの独自のローカルコピーを持っていることを考慮してください。シンボル数が増え（例えばMT5では5,000～10,000シンボル）、深い1分足の履歴をすべてのタイムフレームの基本として使用する場合、MT4の方法を使用することは原理的に不可能になりました。RAMが足りず、大きなチャンクをコピーするとパフォーマンスが落ちる。そのため、MT5では、各エクパートに対して、隠れた高価なチャートのコピーを自動的に維持しなくなりました。その代わりに、非常に経済的な CopyXXX 関数に移行しました。この関数では、開発者は利用可能なチャート全体ではなく、必要なだけのデータをローカル配列に正確に要求します。そして、ローカルデータの最速の処理（昔のかなり高価な Open/High/Low/Close/Time[xxx] の代わりに）、さらに作者はそのデータをキャッシュして次の呼び出しで控えめに使用することができるのです。メモリとCPUの節約は莫大なものです。さらに、プラットフォーム自体が膨大なデータベースを管理するために特にハンズフリーになっています。データベースへのアクセスは（監視されていない直接アクセスではなく）常にオンデマンドであり、これによりキャッシュを柔軟に管理することができます。また、MQL4におけるOpen/High/Low/Close/Time[xxx]コールの簡略化は、現在のシンボルとタイムフレームに限られ、他のシンボルとタイムフレームのデータはすべてiClose/iLow(...)関数で取得していたため、深刻な遅延が発生していたことも特筆されるでしょう。MQL5では、単一のCopyXXX関数モデルへの移行により、開発者は必要なデータチャンクを1回のリクエストで取得でき、複数のブロックされた呼び出し（iCloseの各単一呼び出しでのすべてのブロックを考えてください）を行う必要がなくなり、状況が根本的に改善されました。...CopyXXXの性能はいかがでしょうか？メモリの節約という点では、文句なしです。しかし、一旦バッファに気配値の配列をコピーして、Rates[X]型の直接インデックスでアクセスするよりも、各ティック 毎にCopyXXXを呼び出す方がコストがかかります。ここで、「メモリを節約するか、CPUの時間を節約するか」という古典的なプログラミングのジレンマが発生します。 削除済み 2014.11.17 17:50 #93 lob32371:MT5に勝るとも劣らない。今度は、BをAに置き換えるだけで、同じ質問を自分に投げかけてみてください。MARKETとは何かを学んできてくださいトレーダーは、その...。つまり、MT4は、例えば、スプレッド履歴を保存したり、実際のボリュームについて「知る」ことができるということですか（松葉杖など全く不十分な解決策なしに）。実際の市場では、スプレッドは明らかに固定されていないことに同意しますか？MT4のテスターで、スプレッドが変化するクォートでEAをテストしてみてください、話はそれからです。 削除済み 2014.11.17 17:58 #94 RickD:複雑な論理を持つ専門家の育成の利益と同じくらい、他の国のことはどうでもいいんです。;)妥協案としては、MT5レベルで仮想注文を整理することでしょう。そうすると、誰かが必要とするネットと、オーダーで動く古いロジックの両方が存在することになります。そんな "見える化 "のリスクを背負うのか？MT5では、相関性の高い異なる商品の取引でヘッジすることで、希望する全員が長い間その解決策を利用してきました。たしかに、これではMT4よりも多くの証拠金が必要かもしれませんが、常識的に考えて正しいことです。もちろん、今回の「仮想」スキームをキャンセルした人はいない。 削除済み 2014.11.17 18:21 #95 Interesting:つまり、MT4は、例えば、スプレッド履歴を保存したり、実数量を「知る」ことができる（松葉杖などの不十分な解決策なしに）ということですね？実際の市場では、スプレッドは明らかに固定されていないことに同意しますか？MT4のテスターで、スプレッドが変化するクォートでEAをテストしてみてください、話はそれからです。 私とあなたの間には、埋められない溝があるのです。時間の無駄なだけです！頑張ってください。 削除済み 2014.11.17 21:49 #96 Interesting:そんな "見える化 "のリスクを背負うことになるのか。MT5では、希望者は皆、相関性の高い異なる商品の取引を利用したヘッジソリューションを使っています。よかった、とりあえずMT4がある。:)ご希望であれば、1つの楽器に使用することも可能です。別の楽器を使ってもよい。リスクはどのように考えていますか？ Renat Fatkhullin 2014.11.18 08:26 #97 C-4:CopyXXXの性能はどうでしょうか？省メモリという点では、文句なしです。しかし、気配値の配列を一度バッファにコピーして、Rates[X]型の直接インデックスでアクセスするよりも、ティックごとにCopyXXXを呼び出す方がコストがかかります。ここで、「メモリを節約するか、CPUの時間を節約するか」という古典的なプログラミングのジレンマが発生します。CopyXXXはiClose/iOpen/iXXXX関数と同じ速度 です。iXXXだけが一度に1つの項目を返し、CopyXXXは複数の項目を返すので、より効率的で生産 性が高いのです。おそらく、MT4がティックハンドラーを起動する前に、ローカルチャートのすべての履歴を ローカル（キャッシュ）EAのマーケット環境に強制的にコピー することを考慮していないのでしょう。そして、この情報を経済的に更新する方法があるのですが、これには非常にコストがかかります。MQL4の特殊関数RefreshRatesは、ローカルチャートのキャッシュとヒストリーを強制的にリフレッシュさせます。CopyXXXを呼び出す方がはるかに効率的であり、開発者は以前に要求されたデータをキャッシュする非常に精密で正確なメカニズムを持っています。例えば、ディープヒストリーを刻々と再リクエストする必要はなく、ローカルに保存／書き出し、できるだけ早くアクセスできるようにします。昔の「ダイレクト」（実際にはダイレクトアクセスではない）アクセスOpen/High/Low/Closeとローカル配列double local[xxxx]を扱う方法を比較すると、後者の方が何倍も速い。したがって、ローカルに自分自身にコピーし、繰り返しクエリされるデータにローカルで高速にアクセスできるようにするのがよいでしょう。 削除済み 2014.11.18 09:56 #98 RickD:とりあえずMT4があるのはありがたい。:)それを使えば、1つの楽器を同時に使うことができます。別の楽器を使ってもよい。リスクはどのように考えていますか？取引プラットフォーム」を開発・利用する場合、最終的に誰かが負担するコストやリスクはあります。他のデベロッパーのソフトウェアにおける「仮想化」についてはこれは、すべてが自分のために使われ、そのソリューションを導入する人々が自分たちのしていることを理解している限り、良いことだと思います。主なコストは、システム開発にかかる費用、システム維持にかかる費用、プロジェクト 実施にかかる時間である。主なリスクは、実行可能なプロジェクトを実施するために多くの時間や費用がかかる（プロジェクトが報われない）、他のソリューションと比較してプロジェクトが有効でない、プロジェクト実施中にコードやアルゴリズムに隠れたエラーが発生する、などです。確かに、銀行や他の市場関係者は、必要な機能を備えたソフトウェアを独自に開発することに頼るが、それには膨大な時間とリソースを費やすことになる。その一方で、リスクはすべて自分たちで背負う。MT5での作業について（MT5を使ったさまざまなバリエーション）もちろん、ここでMQはほとんどの仕事をこなしましたが、機能面で一定の制限も導入しました。主なコストは、システムの性能を維持するために使うお金と、プロジェクトに費やす時間です。主なリスクとしては、プロジェクトが他のソリューションと比較して効率的でない、プロジェクト実施時にコードやアルゴリズムに隠れたエラーがある、システム全体のパフォーマンスを常に監視しなければならない（ソフトウェアやハードウェアの問題から守る、通信品質、電源、データセキュリティなどを監視する）、などが挙げられます。 もちろん、一定の制限や注意点を設けた上で、商用アプリケーション（他の人に使ってもらうこと）を考えることも可能です。 削除済み 2014.11.18 13:09 #99 Vinin: を見てみたいと思います。 ここでは、簡単なプログラムを書くときに、特にOOPのシンプルさと使いやすさを実感していただける例を ご紹介します。 Victor Nikolaev 2014.11.18 14:13 #100 lob32371: ここでは、簡単なプログラムを書くときに、OOPのシンプルさと使いやすさが特に際立つ例を 紹介します。 これは指標ではありません 1...34567891011 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そんなこと言ってませんよ。
この話題には全く触れていませんし、関わるつもりもありません。
どうやら、私にはそう思えた。
そして、統合されたストップロットやテイクプロフィットは、実はバーチャルな もので、いざという時に市場で執行するために投げ出されるのです。このソリューションには、CS（担保、証拠金）の節約という良い面も あります。
新しいデータアクセス機能は何を提供するのか、なぜそうなるのかを考えてみてください。
MetaTrader 4は、履歴の深さが限られており、タイムフレームが分かれており、Open/High/Low/Close/Time[xxx]を介してそのシンボルのバーに直接アクセスできます。このようなダイレクトアクセスは、リソースやCPUコストの面で実装が非常に高価になります。他のExpert Advisorや端末との競合を避けるため、各Expert Advisorはこのデータの独自のローカルコピーを持っていることを考慮してください。
シンボル数が増え（例えばMT5では5,000～10,000シンボル）、深い1分足の履歴をすべてのタイムフレームの基本として使用する場合、MT4の方法を使用することは原理的に不可能になりました。RAMが足りず、大きなチャンクをコピーするとパフォーマンスが落ちる。そのため、MT5では、各エクパートに対して、隠れた高価なチャートのコピーを自動的に維持しなくなりました。
その代わりに、非常に経済的な CopyXXX 関数に移行しました。この関数では、開発者は利用可能なチャート全体ではなく、必要なだけのデータをローカル配列に正確に要求します。そして、ローカルデータの最速の処理（昔のかなり高価な Open/High/Low/Close/Time[xxx] の代わりに）、さらに作者はそのデータをキャッシュして次の呼び出しで控えめに使用することができるのです。メモリとCPUの節約は莫大なものです。さらに、プラットフォーム自体が膨大なデータベースを管理するために特にハンズフリーになっています。データベースへのアクセスは（監視されていない直接アクセスではなく）常にオンデマンドであり、これによりキャッシュを柔軟に管理することができます。
また、MQL4におけるOpen/High/Low/Close/Time[xxx]コールの簡略化は、現在のシンボルとタイムフレームに限られ、他のシンボルとタイムフレームのデータはすべてiClose/iLow(...)関数で取得していたため、深刻な遅延が発生していたことも特筆されるでしょう。MQL5では、単一のCopyXXX関数モデルへの移行により、開発者は必要なデータチャンクを1回のリクエストで取得でき、複数のブロックされた呼び出し（iCloseの各単一呼び出しでのすべてのブロックを考えてください）を行う必要がなくなり、状況が根本的に改善されました。
...
CopyXXXの性能はいかがでしょうか？
メモリの節約という点では、文句なしです。しかし、一旦バッファに気配値の配列をコピーして、Rates[X]型の直接インデックスでアクセスするよりも、各ティック 毎にCopyXXXを呼び出す方がコストがかかります。ここで、「メモリを節約するか、CPUの時間を節約するか」という古典的なプログラミングのジレンマが発生します。
MT5に勝るとも劣らない。今度は、BをAに置き換えるだけで、同じ質問を自分に投げかけてみてください。
MARKETとは何かを学んできてくださいトレーダーは、その...。
つまり、MT4は、例えば、スプレッド履歴を保存したり、実際のボリュームについて「知る」ことができるということですか（松葉杖など全く不十分な解決策なしに）。
実際の市場では、スプレッドは明らかに固定されていないことに同意しますか？MT4のテスターで、スプレッドが変化するクォートでEAをテストしてみてください、話はそれからです。
複雑な論理を持つ専門家の育成の利益と同じくらい、他の国のことはどうでもいいんです。;)
妥協案としては、MT5レベルで仮想注文を整理することでしょう。そうすると、誰かが必要とするネットと、オーダーで動く古いロジックの両方が存在することになります。
そんな "見える化 "のリスクを背負うのか？
MT5では、相関性の高い異なる商品の取引でヘッジすることで、希望する全員が長い間その解決策を利用してきました。
たしかに、これではMT4よりも多くの証拠金が必要かもしれませんが、常識的に考えて正しいことです。
もちろん、今回の「仮想」スキームをキャンセルした人はいない。
つまり、MT4は、例えば、スプレッド履歴を保存したり、実数量を「知る」ことができる（松葉杖などの不十分な解決策なしに）ということですね？
実際の市場では、スプレッドは明らかに固定されていないことに同意しますか？MT4のテスターで、スプレッドが変化するクォートでEAをテストしてみてください、話はそれからです。
そんな "見える化 "のリスクを背負うことになるのか。
MT5では、希望者は皆、相関性の高い異なる商品の取引を利用したヘッジソリューションを使っています。
よかった、とりあえずMT4がある。:)ご希望であれば、1つの楽器に使用することも可能です。別の楽器を使ってもよい。
リスクはどのように考えていますか？
CopyXXXの性能はどうでしょうか？
省メモリという点では、文句なしです。しかし、気配値の配列を一度バッファにコピーして、Rates[X]型の直接インデックスでアクセスするよりも、ティックごとにCopyXXXを呼び出す方がコストがかかります。ここで、「メモリを節約するか、CPUの時間を節約するか」という古典的なプログラミングのジレンマが発生します。
CopyXXXはiClose/iOpen/iXXXX関数と同じ速度 です。iXXXだけが一度に1つの項目を返し、CopyXXXは複数の項目を返すので、より効率的で生産 性が高いのです。
おそらく、MT4がティックハンドラーを起動する前に、ローカルチャートのすべての履歴を ローカル（キャッシュ）EAのマーケット環境に強制的にコピー することを考慮していないのでしょう。そして、この情報を経済的に更新する方法があるのですが、これには非常にコストがかかります。MQL4の特殊関数RefreshRatesは、ローカルチャートのキャッシュとヒストリーを強制的にリフレッシュさせます。
CopyXXXを呼び出す方がはるかに効率的であり、開発者は以前に要求されたデータをキャッシュする非常に精密で正確なメカニズムを持っています。例えば、ディープヒストリーを刻々と再リクエストする必要はなく、ローカルに保存／書き出し、できるだけ早くアクセスできるようにします。
昔の「ダイレクト」（実際にはダイレクトアクセスではない）アクセスOpen/High/Low/Closeとローカル配列double local[xxxx]を扱う方法を比較すると、後者の方が何倍も速い。したがって、ローカルに自分自身にコピーし、繰り返しクエリされるデータにローカルで高速にアクセスできるようにするのがよいでしょう。
とりあえずMT4があるのはありがたい。:)それを使えば、1つの楽器を同時に使うことができます。別の楽器を使ってもよい。
リスクはどのように考えていますか？
取引プラットフォーム」を開発・利用する場合、最終的に誰かが負担するコストやリスクはあります。
他のデベロッパーのソフトウェアにおける「仮想化」については
これは、すべてが自分のために使われ、そのソリューションを導入する人々が自分たちのしていることを理解している限り、良いことだと思います。
主なコストは、システム開発にかかる費用、システム維持にかかる費用、プロジェクト 実施にかかる時間である。
主なリスクは、実行可能なプロジェクトを実施するために多くの時間や費用がかかる（プロジェクトが報われない）、他のソリューションと比較してプロジェクトが有効でない、プロジェクト実施中にコードやアルゴリズムに隠れたエラーが発生する、などです。
確かに、銀行や他の市場関係者は、必要な機能を備えたソフトウェアを独自に開発することに頼るが、それには膨大な時間とリソースを費やすことになる。その一方で、リスクはすべて自分たちで背負う。
MT5での作業について（MT5を使ったさまざまなバリエーション）
もちろん、ここでMQはほとんどの仕事をこなしましたが、機能面で一定の制限も導入しました。
主なコストは、システムの性能を維持するために使うお金と、プロジェクトに費やす時間です。
主なリスクとしては、プロジェクトが他のソリューションと比較して効率的でない、プロジェクト実施時にコードやアルゴリズムに隠れたエラーがある、システム全体のパフォーマンスを常に監視しなければならない（ソフトウェアやハードウェアの問題から守る、通信品質、電源、データセキュリティなどを監視する）、などが挙げられます。
もちろん、一定の制限や注意点を設けた上で、商用アプリケーション（他の人に使ってもらうこと）を考えることも可能です。を見てみたいと思います。
ここでは、簡単なプログラムを書くときに、OOPのシンプルさと使いやすさが特に際立つ例を 紹介します。