右のTCのいくつかの兆候 - ページ 13 1...67891011121314151617181920...37 新しいコメント Vladimir 2020.03.02 14:45 #121 Serqey Nikitin: なぜ、主な属性である「利益」から始めないのか？ あなたがチェックした正しい機能を、利益を生まない人が必要とするのか？ これは純粋な科学なのか？ この純粋な科学を、トレーダーが必要とする性質と結びつけてみてください-そしてこの性質は、利益のためだけにあるのです...! 縛り付けよう。事後的に、価格（時間）関数がすでに分かっている場合。通貨ペアは1つです。あとは、最大の利益を得るために、取引の開始と終了のタイミングを選択するだけです。グローバルな最小値で買いポジションを建て、グローバルな最大値でそれを決済し、次のグローバルな最小値で決済する売りポジションを建てるという具合です。といった具合に。 この時のレートの動きがオーバーヘッド（スプレッド、手数料...）よりもはるかに大きい場合、我々はまた、その時間の位置を閉じて、反対のものを開いて、リトレースメント領域で反転ポイントを挿入することができます。そして、可能な限りの利益を回収する、これ以上はない。 結論から言うと決定する瞬間は、価格が極端に上昇する瞬間である。Fが単調な場合、価格（時間）関数の代わりに極値F（価格（時間））を探索した場合に保存されるものである。 Serqey Nikitin 2020.03.02 15:21 #122 Vladimir: 縛りましょう。事後的に、価格（時間）関数がすでに分かっている場合。通貨ペアは1つです。あとは、最大の利益を得るために、取引の開始と終了のタイミングを選択するだけです。グローバルな最小値になった時点で買い取引を開始し、グローバルな最大値になった時点で決済し、次のグローバルな最小値になった時点で売り取引を開始し、決済するというように定義します。 といった具合に。この時のレートの動きがオーバーヘッド（スプレッド、手数料...）よりもはるかに大きい場合、我々はまた、その時間の位置を閉じて、反対のものを開いて、リトレースメント領域に反転点を挿入することができます。そして、可能な限りの利益を回収する、これ以上はない。 結論から言うと決定する瞬間は、価格が極端に上昇する瞬間である。Fが単調な場合、価格（時間）関数の代わりに極値F（価格（時間））を探索した場合に保存されるものである。 1組のためにTSをカスタマイズするような特殊なケースは必要ありません。 ヒストリーマッチングと呼ばれるものです。 しかし、これらの調整によって、必ずしもこのTS RIGHT! RIGHT TSは、ストラテジーの設定が1つのペアで利益を出しているが、同じ設定で追加の最適化をしていない場合、他のペアでも利益を出している場合である。 そして、この場合、成功するかどうかは、相場、正しいか、間違っているか、何らかの条件によって変化するかではなく、ストラテジーのアイデアにかかって います。 Maxim Kuznetsov 2020.03.02 16:17 #123 Vladimir: 縛りましょう。事後的に、価格（時間）関数がすでに分かっている場合。通貨ペアは1つです。あとは、最大の利益を得るために、取引の開始と終了のタイミングを選択するだけです。グローバルな最小値になった時点で買い取引を開始し、グローバルな最大値になった時点で決済し、次のグローバルな最小値になった時点で売り取引を開始し、決済するというように定義します。 といった具合に。この時のレートの動きがオーバーヘッド（スプレッド、手数料...）よりもはるかに大きい場合、我々はまた、その時間の位置を閉じて、反対のものを開いて、リトレースメント領域で反転ポイントを挿入することができます。そして、可能な限りの利益を回収する、これ以上はない。 結論から言うと決定する瞬間は、価格が極端に上昇する瞬間である。それらは、価格（時間）関数の代わりに極値F（価格（時間））を探索した場合、Fが単調であれば、保存されるものである。 主な取引問題（抽象的な関数で言えば）：極限と「その局所性」をリアルタイムに識別すること。ある極限がほぼ、あるいはすでに到達しており、価格的にも時間的にも反対の極限まで十分なギャップがあるという「警笛」／評価を与えることを意味します。 二次的な課題として、直近の価格時点における極値不在を確認する。このタスクが最初のタスクと根本的に異なるという微妙な点が、あなたの心を揺さぶるのです この2つの課題は、予測であり、互いに矛盾する可能性もあるため、確実に解決していくしかないのです。 Nikolai Semko 2020.03.02 17:05 #124 Renat Akhtyamov: ニコライ、最終的な数字を見せてくれないか。 チラッチラッ あるんじゃないかと思うんだけど、まだわからない。 その姿は、すべて森の中にある。 しかし、私が言っているのは、理想的な 正しいTSの属性、つまり、人が目指すべきもの、私自身が目指すべきものです。 この話題については、すでにこの掲示板でいろいろとお話ししてきました。 このスレッドでは重要な追加事項が非常に懇願されています。いい意味で、もちろん、別の話題であるべきです。 適切なTCには、適切なデータ構造、ストレージ、アクセスベースが必要です。 現在のものは、きちんとしたTSを作るには非常に煩雑で扱いにくいものです。 その結果、より便利でコンパクト、かつ軽快になったと思います。 一言で言えば、「説明できる」。 まず、すべての分単位をポンピングし、次にすべてのティックを徐々にポンピングする。はい、時間がかかるかもしれません（1つのシンボルにつき数分）。 次に、分足のデータベースが形成されるが、Open, Close, Hight, Lowがそれぞれ4回ずつ追加される構造になっている。私の実装では、この構造はバーあたり約13バイトを占有しています。MqlRates構造体（60バイト）より5倍コンパクトで、同時に情報量も多い。これは、インクリメントのみを格納し、迅速なアクセスや検索のためにインデックス配列を追加することで実現されています。 MqlRatesの分棒の配列は、役に立たないので削除されました。ティックの配列はまだここにあります（これはメモリ消費の大部分を占めます。） このデータベースは、全歴史で100〜200Mbを占めるところを、すでに1文字で30〜40Mbを占めています。 このデータベースから、数ミリ秒で簡単に任意の期間のタイムフレームを作成することができ、Open、Close、Hight、Lowの時間がまだわかっているため、より情報量が多くなります。 ただし、これはあくまで中間データベースであり、Expert Advisorをロードして シンボルの必要なパラメータをすべて計算する段階でシンボルを分析するために必要なだけです（シンボルの動作特性は外しています）。 検索方法で選ぶのではなく、計算することを重視しています。テスターやテスターグレイル好きにはたまらない言葉です。これは、パターン認識と数キロバイトから数十キロバイトの多次元統計配列の形成という、かなり複雑な多段階のシステムである。この一連の作業には5秒程度かかります。 その後、tick配列も削除することができ、30～40MBのデータベースから最大1MBの対数圧縮されたデータベースが作成されます。このデータベースには、現在の瞬間からシンボルの全歴史が網羅されています。最初は数千の刻みがあり、それが徐々に週足に増えていく。風景を見るときの視覚も、同じ原理です。風景の中の物体は、近くにあるものほど細かく、遠くにあるものほど不要なものなので、細かくはありません。目の構造や錐体・杆体の数を知っている人なら、完全視力の人の写真が100メガピクセル程度であることを理解しているはずだ。 その後、30〜40Mbの塩基を削除し、1Mb以下の塩基だけを残せばよいのです。 数分の準備でTCは終了です。 次に、取引に応じてティックをデータベースに追加し、例えば30.5分ごとに再パッケージ化します。シンボル特性の多次元テーブルを補足・更新しています。 1シンボル1Mbで、詳細な履歴が残るというのは、美点ですよね。これによって、タイムフレームに依存しない適切なTSを作成することができます。 私は間違っているだろうか？ すべての数値は絶対に本物です。 TheXpert 2020.03.02 17:11 #125 Nikolai Semko: 私が間違っているのでしょうか？ 質問 - なぜ、制作のためのすべての履歴を保存するシステムが必要なのでしょうか？) Nikolai Semko 2020.03.02 17:14 #126 TheXpert: 質問 - なぜ、制作に全履歴保存システムが必要なのでしょうか？) 正しいTCのために。 もっとよく読んでみてください。ストレージ全体の占有量は1MB未満です。 TCは全履歴を見るべき。 私のTSではこうなっています。ダニの一匹一 匹は、ダニから週までの全歴史上のパターン認識です。対数圧縮とサイクルフリー計算手法により、全歴史の認識サイクルに対して1ミリ秒を大きく下回る時間を実現しました。 TheXpert 2020.03.02 17:18 #127 Nikolai Semko: 正しいTSのために。 データの保存の原理はTSの「正しさ」とは関係ない) Nikolai Semko 2020.03.02 17:22 #128 TheXpert: データの保存の原理は、TSの「正しさ」とは関係ない) 正しいTSを構築できる可能性があるということです。より良いレンガ、より頑丈なレンガで頑丈な建物を作る方がはるかに簡単なのです。 私は、自分の経験や体験に基づいた意見を述べているだけです。 私は誰にも何も押し付けないし、議論するつもりもない。 Maxim Kuznetsov 2020.03.02 18:05 #129 Nikolai Semko: きちんとしたTCを構築できるようになることです。より良い、より強いレンガから頑丈な建物を建てる方がずっと簡単です。 私は、自分の経験や体験に基づいた意見を述べているに過ぎません。 私は何も課さないし、議論するつもりもない。 「正しさ」、そして一般的に、TCの個々の概念とは何なのか:-) 私がこのトピックのメッセージを理解する限り、数学的公式のセットとしてのある種の取引システムと売買の瞬間の決定は、座標にリンクしてはいけません（時間の瞬間に依存せず、以前の動きのみに依存し、絶対値には 依存せず、相対価格の広がりに依存します）。これを「正しい」と呼ぶことにします。 しかし、それが市場に関するものであればナンセンスなので、正しいとは言いたくない。抽象化について、畳み掛けるように。 Документация по MQL5: Математические функции / MathAbs www.mql5.com Математические функции / MathAbs - справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5 fxsaber 2020.03.02 18:39 #130 Nikolai Semko: 正しいTSを構築できるかどうかです。 TheXpertは、「正しい」という言葉をわざと引用符で囲んでいるのです。このトピックを作成したとき、この言葉によって、まったく本題から外れた発言がこれほど多くなるとは予想もできませんでした。言葉の力が良い方向に作用していないケースです。名前を変えられない。他の名前も思いつかない--。 1...67891011121314151617181920...37 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
なぜ、主な属性である「利益」から始めないのか？ あなたがチェックした正しい機能を、利益を生まない人が必要とするのか？ これは純粋な科学なのか？
この純粋な科学を、トレーダーが必要とする性質と結びつけてみてください-そしてこの性質は、利益のためだけにあるのです...!
縛り付けよう。事後的に、価格（時間）関数がすでに分かっている場合。通貨ペアは1つです。あとは、最大の利益を得るために、取引の開始と終了のタイミングを選択するだけです。グローバルな最小値で買いポジションを建て、グローバルな最大値でそれを決済し、次のグローバルな最小値で決済する売りポジションを建てるという具合です。といった具合に。 この時のレートの動きがオーバーヘッド（スプレッド、手数料...）よりもはるかに大きい場合、我々はまた、その時間の位置を閉じて、反対のものを開いて、リトレースメント領域で反転ポイントを挿入することができます。そして、可能な限りの利益を回収する、これ以上はない。
結論から言うと決定する瞬間は、価格が極端に上昇する瞬間である。Fが単調な場合、価格（時間）関数の代わりに極値F（価格（時間））を探索した場合に保存されるものである。
縛りましょう。事後的に、価格（時間）関数がすでに分かっている場合。通貨ペアは1つです。あとは、最大の利益を得るために、取引の開始と終了のタイミングを選択するだけです。グローバルな最小値になった時点で買い取引を開始し、グローバルな最大値になった時点で決済し、次のグローバルな最小値になった時点で売り取引を開始し、決済するというように定義します。 といった具合に。この時のレートの動きがオーバーヘッド（スプレッド、手数料...）よりもはるかに大きい場合、我々はまた、その時間の位置を閉じて、反対のものを開いて、リトレースメント領域に反転点を挿入することができます。そして、可能な限りの利益を回収する、これ以上はない。
結論から言うと決定する瞬間は、価格が極端に上昇する瞬間である。Fが単調な場合、価格（時間）関数の代わりに極値F（価格（時間））を探索した場合に保存されるものである。
1組のためにTSをカスタマイズするような特殊なケースは必要ありません。 ヒストリーマッチングと呼ばれるものです。
しかし、これらの調整によって、必ずしもこのTS RIGHT!
RIGHT TSは、ストラテジーの設定が1つのペアで利益を出しているが、同じ設定で追加の最適化をしていない場合、他のペアでも利益を出している場合である。
そして、この場合、成功するかどうかは、相場、正しいか、間違っているか、何らかの条件によって変化するかではなく、ストラテジーのアイデアにかかって います。
縛りましょう。事後的に、価格（時間）関数がすでに分かっている場合。通貨ペアは1つです。あとは、最大の利益を得るために、取引の開始と終了のタイミングを選択するだけです。グローバルな最小値になった時点で買い取引を開始し、グローバルな最大値になった時点で決済し、次のグローバルな最小値になった時点で売り取引を開始し、決済するというように定義します。 といった具合に。この時のレートの動きがオーバーヘッド（スプレッド、手数料...）よりもはるかに大きい場合、我々はまた、その時間の位置を閉じて、反対のものを開いて、リトレースメント領域で反転ポイントを挿入することができます。そして、可能な限りの利益を回収する、これ以上はない。
結論から言うと決定する瞬間は、価格が極端に上昇する瞬間である。それらは、価格（時間）関数の代わりに極値F（価格（時間））を探索した場合、Fが単調であれば、保存されるものである。
主な取引問題（抽象的な関数で言えば）：極限と「その局所性」をリアルタイムに識別すること。ある極限がほぼ、あるいはすでに到達しており、価格的にも時間的にも反対の極限まで十分なギャップがあるという「警笛」／評価を与えることを意味します。
二次的な課題として、直近の価格時点における極値不在を確認する。このタスクが最初のタスクと根本的に異なるという微妙な点が、あなたの心を揺さぶるのです
この2つの課題は、予測であり、互いに矛盾する可能性もあるため、確実に解決していくしかないのです。
ニコライ、最終的な数字を見せてくれないか。
チラッチラッ
あるんじゃないかと思うんだけど、まだわからない。
その姿は、すべて森の中にある。
しかし、私が言っているのは、理想的な 正しいTSの属性、つまり、人が目指すべきもの、私自身が目指すべきものです。
この話題については、すでにこの掲示板でいろいろとお話ししてきました。
このスレッドでは重要な追加事項が非常に懇願されています。いい意味で、もちろん、別の話題であるべきです。
適切なTCには、適切なデータ構造、ストレージ、アクセスベースが必要です。
現在のものは、きちんとしたTSを作るには非常に煩雑で扱いにくいものです。
その結果、より便利でコンパクト、かつ軽快になったと思います。
一言で言えば、「説明できる」。
まず、すべての分単位をポンピングし、次にすべてのティックを徐々にポンピングする。はい、時間がかかるかもしれません（1つのシンボルにつき数分）。
次に、分足のデータベースが形成されるが、Open, Close, Hight, Lowがそれぞれ4回ずつ追加される構造になっている。私の実装では、この構造はバーあたり約13バイトを占有しています。MqlRates構造体（60バイト）より5倍コンパクトで、同時に情報量も多い。これは、インクリメントのみを格納し、迅速なアクセスや検索のためにインデックス配列を追加することで実現されています。
MqlRatesの分棒の配列は、役に立たないので削除されました。ティックの配列はまだここにあります（これはメモリ消費の大部分を占めます。）
このデータベースは、全歴史で100〜200Mbを占めるところを、すでに1文字で30〜40Mbを占めています。
このデータベースから、数ミリ秒で簡単に任意の期間のタイムフレームを作成することができ、Open、Close、Hight、Lowの時間がまだわかっているため、より情報量が多くなります。
ただし、これはあくまで中間データベースであり、Expert Advisorをロードして シンボルの必要なパラメータをすべて計算する段階でシンボルを分析するために必要なだけです（シンボルの動作特性は外しています）。 検索方法で選ぶのではなく、計算することを重視しています。テスターやテスターグレイル好きにはたまらない言葉です。これは、パターン認識と数キロバイトから数十キロバイトの多次元統計配列の形成という、かなり複雑な多段階のシステムである。この一連の作業には5秒程度かかります。
その後、tick配列も削除することができ、30～40MBのデータベースから最大1MBの対数圧縮されたデータベースが作成されます。このデータベースには、現在の瞬間からシンボルの全歴史が網羅されています。最初は数千の刻みがあり、それが徐々に週足に増えていく。風景を見るときの視覚も、同じ原理です。風景の中の物体は、近くにあるものほど細かく、遠くにあるものほど不要なものなので、細かくはありません。目の構造や錐体・杆体の数を知っている人なら、完全視力の人の写真が100メガピクセル程度であることを理解しているはずだ。
その後、30〜40Mbの塩基を削除し、1Mb以下の塩基だけを残せばよいのです。
数分の準備でTCは終了です。
次に、取引に応じてティックをデータベースに追加し、例えば30.5分ごとに再パッケージ化します。シンボル特性の多次元テーブルを補足・更新しています。
1シンボル1Mbで、詳細な履歴が残るというのは、美点ですよね。これによって、タイムフレームに依存しない適切なTSを作成することができます。
私は間違っているだろうか？
すべての数値は絶対に本物です。
Nikolai Semko:
私が間違っているのでしょうか？
質問 - なぜ、制作に全履歴保存システムが必要なのでしょうか？)
正しいTCのために。
もっとよく読んでみてください。ストレージ全体の占有量は1MB未満です。
TCは全履歴を見るべき。
私のTSではこうなっています。ダニの一匹一 匹は、ダニから週までの全歴史上のパターン認識です。対数圧縮とサイクルフリー計算手法により、全歴史の認識サイクルに対して1ミリ秒を大きく下回る時間を実現しました。
正しいTSのために。
データの保存の原理はTSの「正しさ」とは関係ない)
データの保存の原理は、TSの「正しさ」とは関係ない)
正しいTSを構築できる可能性があるということです。より良いレンガ、より頑丈なレンガで頑丈な建物を作る方がはるかに簡単なのです。
私は、自分の経験や体験に基づいた意見を述べているだけです。
私は誰にも何も押し付けないし、議論するつもりもない。
きちんとしたTCを構築できるようになることです。より良い、より強いレンガから頑丈な建物を建てる方がずっと簡単です。
私は、自分の経験や体験に基づいた意見を述べているに過ぎません。
私は何も課さないし、議論するつもりもない。
「正しさ」、そして一般的に、TCの個々の概念とは何なのか:-)
私がこのトピックのメッセージを理解する限り、数学的公式のセットとしてのある種の取引システムと売買の瞬間の決定は、座標にリンクしてはいけません（時間の瞬間に依存せず、以前の動きのみに依存し、絶対値には 依存せず、相対価格の広がりに依存します）。これを「正しい」と呼ぶことにします。
しかし、それが市場に関するものであればナンセンスなので、正しいとは言いたくない。抽象化について、畳み掛けるように。
正しいTSを構築できるかどうかです。
TheXpertは、「正しい」という言葉をわざと引用符で囲んでいるのです。このトピックを作成したとき、この言葉によって、まったく本題から外れた発言がこれほど多くなるとは予想もできませんでした。言葉の力が良い方向に作用していないケースです。名前を変えられない。他の名前も思いつかない--。