ティック履歴はサーバーで見ることができますか？ - ページ 2

新しいコメント
 
しかし、なぜタイムフレームだけでなく、10、100、500、1000などの数ティック単位で履歴を形成するのでしょうか。この場合、タイムチャートをボリュームに縮小したものであることがわかります。出来高は分析上、非常に重要な指標であることは否定できない。とてもクリアになります。そのほか、ティック数やタイムインジケータなど、必要に応じて履歴を形成することができます。蓄積されたデータは、誰が何を収集したのか、フォーラムで共有することができます。プログラム的に提供することは難しくないと思います。不足したデータ（端末がシャットダウンされた）を補充するために、わずかな期間（例えば1～3日間）ティック履歴を サーバーに保存することができます。
 
出来高は分析上、非常に重要な指標であることは否定できません。とても視覚的なものでしょ
う。

どうやら開発者は、目につくところに大きな文字でホームページを釘付けにすればいいだけのようだ。"ダニ "も "いない "し、"いない "だろう!ダニの議論だけでなく、ブローカーの議論もフォーラムから削除されます」 :o)))。そうでないと、毎週すべてが堂々巡りになってしまいます。ダニを飼う必要性の詳細な根拠もなく、苦しむ人たちの言葉だけ...。
 
どのダニのことなのか、もう少し具体的に教えてください。
リアル アカウントのティック履歴を見るのも面白いかもしれませんね。
文献では、EAを実際の取引に使用する前によく考えなければならないほど、チャートに熱中しています。
そして、私はブローカーが本当のティックのアーカイブをレイアウトしたことをどこにも見たことがない - ので、私は考え始める、多分本当に隠すために何かがある？
 
今度はそこが引っかかるんですね。私は特に、分単位のモデリングに重大な矛盾があることを証明せよ、と言っているのです。特に10点差。ただ、データを取って、研究して、すべての調査結果（過去のファイルも含めて）を公表して、私たちを壁に釘付けにしてください。<br /> translate="no">です。
分モデリング内の誤差は1～2ポイント以内と主張しています。そして、このエラーは全く問題なく、正常なものです。

レナート
絶対に同意見なので、証明はしません。さらに、私は誰かを壁に押し付けるつもりはありません。宣言します。テスターでのダニのモデリングには、かなり満足しています。不満は全くありません。

同時にもう一度繰り返す。
ティック履歴の必要性は、テスターでのモデリングとは関係ない。

そして、その必要性を正当化するために言えることは、すべて上記で述べたとおりです。

ソランドル
ユーザーが積極的かつ粘り強く開発者にニーズを説明しなければ、ユーザーと開発者の両方が被害を受けることになります。
開発者が忍耐と理解、そして戦略的なアプローチで製品を開発しなければ、ユーザーと開発者の両方が被害を受けることになります。
それを理解してほしい。
 
...あと、MT5の話なんですが、Renat、いつ頃発売予定なんですか？
は、MQL4と互換性があるのか、それとも新しいものになるのか？
...MQL4との互換性があるのか、それとも新しいものになるのか？
 
今度はそこが引っかかるんですね。私は特に、分単位のモデリングに重大な矛盾があることを証明せよ、と言っているのです ...<br / translate="no">私は、ミニッツモデリング内の誤差は1～2ポイント以内であると主張しています。そして、その誤差は全く問題なく、正常なものです。

あなたは市場のPRICE（価格）の面について話し続けています。ここで、あなたは間違いなく成功し、PRICEモデリングでのエラーは重要ではありません。
しかし、クォートフローには他のパラメータがあり、特にニュースの動きのある時期には、モデリングによって完全に破壊されます。
私の意見では、あなたは、任意のタイムフレームを取得することができ、そこからtickframe（ローソク足では、例えば、10ティック）、cagiチャート、クロス、ゼロの履歴のみを 必要としています。
つまり、時間軸に関する人為的な制約がすべて取り除かれるのです。
 
私の意見では、我々は、任意の時間枠を得ることができ、そこからティックフレームだけでなく、ティックフレーム（キャンドルでは、例えば、10ティック）、ケージチャートとチックタックつま先を得ることができる唯一のティック履歴が必要です。<br /> 翻訳="no"> つまり、時間枠に関連するすべての人工的な制限は取り除かれます。



まったくその通りです。開発者は、ティックフレームがタイムフレームと同じように存在する権利があることを、本当に証明する必要があるのでしょうか？もし、重要な時間枠のデータが大量にあるため、ONLY tickの履歴を保存することが困難な場合は、少なくとも、現在タイムフレームで行われているように、固定tickframeを保存することができます。これは私の願いであり、テスターやエキスパートアドバイザーなどの無意味なものとは全く関係ありません。リアル口座で 1年ぐらい取引してるけど、手動でしかやらないよ。何らかの値動きがあれば、利益を出して取引するのは初歩的なことですが、価格が1つの場所を前後に漂っているだけなら、専門家アドバイザーは役に立ちません。そして、コンピュータに自分で判断させる--神頼みです。
だから、ティックフレームの方がより正確に値動きを反映していると思うし、個人的には安心できる。そんなに難しいことなのでしょうか？
 
歴史を保存するには、クオリティの高い分量で保存するのが一番良いように思います。
そこから任意のフレームを構築することができます（タイムフレームでも、XやYでも、
、何らかの他の基準に従ってロールアップすることもできます）。
本当に重要なのは、一定の時間間隔で収集されたデータに基づいているMT4のメインチャート、
の軸の均等性 です...

しかし、それは次のMTバージョンで初めて解決されるかもしれません
... それから、少なくとも一度は絵を見ることができます
波で（私はエリオットを書きません、波があるので、しかし、その構造は非常に疑問です？）。
一般的には、QUALITY分の基本的なストーリーに賛成です。
 
時間は価格を設定するのに最適な変数ではなく、価格は操作の数と量にもっと依存し、ティックボリュームは これらのパラメータの関数（またはそれに近いもの）であることに誰も異論はないだろう、と思います。そのため、研究者にとっては、時間軸よりもティックフレームの方が興味深いのです。
いずれにせよ、このブランチに寄せられた意見を単純に推し量れば、「欲しい」という人が絶対多数であることは間違いない。
 
もし 私が自分の端末を作るなら =)))こうしますよ。
サーバーでは、ティックだけを保存し、ダウンロードだけを許可するようにします。
クライアントでは、必要なすべてのTimeFrame（およびTickFrame）をtickから作成します。

したがって、1年間の任意の（any）TFのグラフを得るには、35.7Mbのトラフィックが必要です（Yurixxの計算）。
これで、MT4で同じ期間の履歴をダウンロードするには、約20.763MB（15.71 + 3.142 + 1.047 + 0.524 + 0.262 + 0.065 + 0.011 + 0.002 ）が必要になります。

底力、ティックヒストリーの プラス 面。
- どのTFが欲しいかはユーザー自身が決めることで、いつでも自分で組み立てることができます。
ティック履歴の短所
- の場合、消費されるトラフィックは1.7倍になります（全TFのダウンロード時との比較）。
- プロセッサの負荷が増える（必要なTFを常に構築するため）。


もし 自分が端末を作るなら、まずよく考えてから...。
1234567
新しいコメント