タイムフレーム(TF)なしのATC - ページ 3 1234567 新しいコメント Georgiy Merts 2018.06.22 07:19 #21 Vladimir:なんというか...。http://www.grandars.ru/student/buhgalterskiy-uchet/auditorskaya-proverka.html からの引用を読むように助言する。 監査は、被監査経済企業の財政状態に関連する監査証拠を収集し、評価し、分析する作業である。では、読み進めてください。 監査結果はどうですか？ 監査に関するすべての情報は、監査報告書にその要約が記載されています。そして、実は、「監査人の正確性に関する意見」という1文に収まっているのです。ALL ! 入力に会計情報の山、出力に一文。 引用も同じです。入力はフルクォート、出力は1小節。 Vladimir 2018.06.22 10:38 #22 Alexey Volchanskiy:MT4/5の注文実行時間は、最も楽観的なケースで少なくとも100msであるため、もっぱらそれで？ レート更新の間隔は、お考えの通り「1秒間に平均2～5ティック」です。したがって、この500～200msのうち、100msは端末のレートとサーバーのレートが異なるため、リクオートやスリップが発生しやすい。残りの400-100msはすべて正常です。 注文の実行時刻 と、入力ストリームのデータの一部が破棄される可能性をどのように関連付けるのか、理解できません。 Alexey Volchanskiy 2018.06.22 12:24 #23 Vladimir:それで？ レート更新の間隔は、おっしゃるとおり「1秒間に平均2～5ティック」です。したがって、この500～200msのうち、100msは端末のレートとサーバーのレートが異なるため、リクオートやスリッページが発生する可能性がある。残りの400-100msはすべて正常です。 注文の実行 時間と、入力ストリームから何らかのデータを放り出す可能性をどう関連づけるのか、私には理解できません。 これらの高速な変更は、実行遅延のため、サーバー上でフィルタリングされます、何が明確ではありません Vladimir 2018.06.22 13:53 #24 Alexey Volchanskiy:これらの迅速な変更は、実行遅延のためにサーバー上でフィルタリングされることになり、不明瞭ですサーバーからクライアント端末に配信される気配値の流れが、約定が遅れる開閉注文の有無によって変化するということでしょうか？ サーバーでフィルタリング」とは何ですか？素早い」変化はどこからやってくるのか？ 受信データの一部を破棄することの妥当性を問うものであった。 Vladimir 2018.06.22 13:54 #25 Georgiy Merts:では、読み進めてください。 監査結果はどうですか？ 監査に関するすべての情報は、監査報告書（最終版）に記載されています。そして、実は、それは、「正確性に関する監査人の意見」というONEセンテンスに収まっているのです。ALL ! 入力に会計情報の山、出力に一文。 引用も同じです。入力はフルクォート、出力は1小節。なぜ、解析結果が1本の棒になるのでしょう。通常は1シグナルと言われています。また、入力はフルレートデータ、つまりティックデータというのは納得です。 Alexey Volchanskiy 2018.06.22 15:14 #26 Vladimir:サーバーからクライアント端末に配信される気配値の流れは、約定が遅れる可能性のある開閉注文の有無によって変化するということでしょうか？ サーバーでフィルタリング」とは何ですか？素早い」変化はどこから生まれるのか？ 受信データの一部を破棄することの妥当性を問うものであった。そんなことは想定していない、勝手に決めつけるな。ノイズのレベルなので捨てています。 Igor Yeremenko 2018.06.22 15:28 #27 フィルタリング、サンプリング、補間など、多くの人が（確かに私も）あまり理解していない、非常に狭いトピックに議論が及んでいます。 よくわからないのであれば、古典的な戦略としてタイムフレームを使うべきか、ティック戦略を掘り下げるべきか、無視するべきか。 他にアイデアがあれば、かなり原始的なもの（時間、天候、風、あるいはランダムなどによるエントリー）以外に、時間軸を持たない方向性を教えてください。 Alexey Volchanskiy 2018.06.22 17:58 #28 Igor Yeremenko:フィルタリング、離散化、補間など、多くの人が（私もそうですが）ほとんど理解していない、非常に狭いトピックに議論が及んでいます。 よくわからないなら、タイムフレームを使うようにしたほうがいい、と思う。 非常に原始的なもの（時間による入力、天候による入力、風による入力、あるいはランダムな入力など）を除いて、他のアイデア、時間軸のない方向はないのでしょうか。 路上でパテを交換する方がマシだ。 Vladimir 2018.06.22 18:34 #29 Alexey Volchanskiy:そんなことは想定していない、勝手に決めつけるな。ノイズレベルなので捨てていますAlexey Volchanskiy 2018.06.22 10:05 2018.06.22 09:05:18 #20 ENウラジミールFXでは取るに足らない 」という評価を正当化する根拠を教えてほしい。 MT4/5の注文の実行時間が最も楽観的なケースで100ミリ秒を下回らないという事実のみによるものです 引用終わり また、ノイズレベルと注文実行時間の関連付けはどのように行ったのでしょうか？ Vladimir 2018.06.22 18:50 #30 Igor Yeremenko:フィルタリング、離散化、補間など、多くの人が（私もそうですが）ほとんど理解していない、非常に狭いトピックに議論が及んでいます。 いいアイデアが浮かんだら、ティックストラテジーを使ってみたり、昔クラシックでやっていたようにタイムフレームを使ったりするんだ。 もしかしたら、非常に原始的なもの（時間による入力、天候による入力、風による入力、一般的にランダムな入力など）を除いて、タイミングATCなしの方向性、他のアイデアもあるかもしれませんね。 ティックかOHLCか、なぜそのような制約があるのですか？何より為替レートの性質を考慮するなど、あらゆるグラフ表現を構築してみてはいかがでしょうか。28レートで7自由度しかない、そこはバルティーニのような6次元立方体の4次元投影を得意とする人が暴れるところです。インクリメントの主成分の7次元ベクトルを解析することができます。 また、「時間枠」のATS自体は、OHLC以外のものを使っても可能です。例えば、ここで言ったように、OHLCの代わりにE1 E2。これは、採算が取れないとわかっているものを犠牲にしてデータを減らすというゲッチ（hrenfx）の考え方に近いですね。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
なんというか...。http://www.grandars.ru/student/buhgalterskiy-uchet/auditorskaya-proverka.html からの引用を読むように助言する。
監査は、被監査経済企業の財政状態に関連する監査証拠を収集し、評価し、分析する作業である。
では、読み進めてください。
監査結果はどうですか？
監査に関するすべての情報は、監査報告書にその要約が記載されています。そして、実は、「監査人の正確性に関する意見」という1文に収まっているのです。ALL !
入力に会計情報の山、出力に一文。
引用も同じです。入力はフルクォート、出力は1小節。
MT4/5の注文実行時間は、最も楽観的なケースで少なくとも100msであるため、もっぱら
それで？
レート更新の間隔は、お考えの通り「1秒間に平均2～5ティック」です。したがって、この500～200msのうち、100msは端末のレートとサーバーのレートが異なるため、リクオートやスリップが発生しやすい。残りの400-100msはすべて正常です。
注文の実行時刻 と、入力ストリームのデータの一部が破棄される可能性をどのように関連付けるのか、理解できません。
それで？
レート更新の間隔は、おっしゃるとおり「1秒間に平均2～5ティック」です。したがって、この500～200msのうち、100msは端末のレートとサーバーのレートが異なるため、リクオートやスリッページが発生する可能性がある。残りの400-100msはすべて正常です。
注文の実行 時間と、入力ストリームから何らかのデータを放り出す可能性をどう関連づけるのか、私には理解できません。
これらの高速な変更は、実行遅延のため、サーバー上でフィルタリングされます、何が明確ではありません
これらの迅速な変更は、実行遅延のためにサーバー上でフィルタリングされることになり、不明瞭です
サーバーからクライアント端末に配信される気配値の流れが、約定が遅れる開閉注文の有無によって変化するということでしょうか？
サーバーでフィルタリング」とは何ですか？素早い」変化はどこからやってくるのか？
受信データの一部を破棄することの妥当性を問うものであった。
では、読み進めてください。
監査結果はどうですか？
監査に関するすべての情報は、監査報告書（最終版）に記載されています。そして、実は、それは、「正確性に関する監査人の意見」というONEセンテンスに収まっているのです。ALL !
入力に会計情報の山、出力に一文。
引用も同じです。入力はフルクォート、出力は1小節。
なぜ、解析結果が1本の棒になるのでしょう。通常は1シグナルと言われています。また、入力はフルレートデータ、つまりティックデータというのは納得です。
サーバーからクライアント端末に配信される気配値の流れは、約定が遅れる可能性のある開閉注文の有無によって変化するということでしょうか？
サーバーでフィルタリング」とは何ですか？素早い」変化はどこから生まれるのか？
受信データの一部を破棄することの妥当性を問うものであった。
そんなことは想定していない、勝手に決めつけるな。ノイズのレベルなので捨てています。
フィルタリング、サンプリング、補間など、多くの人が（確かに私も）あまり理解していない、非常に狭いトピックに議論が及んでいます。
よくわからないのであれば、古典的な戦略としてタイムフレームを使うべきか、ティック戦略を掘り下げるべきか、無視するべきか。
他にアイデアがあれば、かなり原始的なもの（時間、天候、風、あるいはランダムなどによるエントリー）以外に、時間軸を持たない方向性を教えてください。
フィルタリング、離散化、補間など、多くの人が（私もそうですが）ほとんど理解していない、非常に狭いトピックに議論が及んでいます。
よくわからないなら、タイムフレームを使うようにしたほうがいい、と思う。
非常に原始的なもの（時間による入力、天候による入力、風による入力、あるいはランダムな入力など）を除いて、他のアイデア、時間軸のない方向はないのでしょうか。
路上でパテを交換する方がマシだ。
そんなことは想定していない、勝手に決めつけるな。ノイズレベルなので捨てています
Alexey Volchanskiy 2018.06.22 10:05 2018.06.22 09:05:18 #20 EN
FXでは取るに足らない 」という評価を正当化する根拠を教えてほしい。
MT4/5の注文の実行時間が最も楽観的なケースで100ミリ秒を下回らないという事実のみによるものです
引用終わり
また、ノイズレベルと注文実行時間の関連付けはどのように行ったのでしょうか？
フィルタリング、離散化、補間など、多くの人が（私もそうですが）ほとんど理解していない、非常に狭いトピックに議論が及んでいます。
いいアイデアが浮かんだら、ティックストラテジーを使ってみたり、昔クラシックでやっていたようにタイムフレームを使ったりするんだ。
もしかしたら、非常に原始的なもの（時間による入力、天候による入力、風による入力、一般的にランダムな入力など）を除いて、タイミングATCなしの方向性、他のアイデアもあるかもしれませんね。
ティックかOHLCか、なぜそのような制約があるのですか？何より為替レートの性質を考慮するなど、あらゆるグラフ表現を構築してみてはいかがでしょうか。28レートで7自由度しかない、そこはバルティーニのような6次元立方体の4次元投影を得意とする人が暴れるところです。インクリメントの主成分の7次元ベクトルを解析することができます。
また、「時間枠」のATS自体は、OHLC以外のものを使っても可能です。例えば、ここで言ったように、OHLCの代わりにE1 E2。これは、採算が取れないとわかっているものを犠牲にしてデータを減らすというゲッチ（hrenfx）の考え方に近いですね。