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

 
私はSolandによって提案された合理的な根拠があると思いますが、個人的に私は研究のためにそれらを必要とし、私はほとんど1週間で深刻な何かを提供することができないことを恐れて、私はちょうどブランチの出現の前にそのような指標を持っている、私の友人の一人が書いたが、問題があります - 彼はそれぞれの初期化の後にダニのファイルを削除し、彼も私は仕事を終えることができませんでした。ティックが来ても音量が1も変わっていないことがあるので、一定の音量に従ってバーを形成する。
//+------------------------------------------------------------------+
//|                                                    TickSaver.mq4 |
//|                               Copyright © 2006, Cherednikov K.M. |
//|                                            mailto:chkm76@mail.ru |
//+------------------------------------------------------------------+
#property copyright "Copyright © 2006, Cherednikov K.M."
#property link      "mailto:chkm76@mail.ru"

#property indicator_chart_window
#property indicator_buffers 1
#property indicator_color1 Black

#include <WinUser32.mqh>
//---- input parameters
extern int NumTicksPerBar=3;
extern int Minutes_for_HSTfilename=3;

//---- buffers
double ExtMapBuffer1[];

//---- глобальные переменные
int hFile=-1;
int iFilePos;
int CurrTickNumber=0;
datetime i_time, i_time_bar0;
double d_open, d_low, d_high, d_close, d_volume;
double d_low_bar0, d_high_bar0, d_volume_bar0;

//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int init()
  {
   int    nVersion=400;
   string szCopyright;
   string szSymbol=Symbol();
   int    iDigits=Digits;
   int    iUnused[13];

   //---- indicators
   SetIndexStyle(0,DRAW_LINE);
   SetIndexBuffer(0,ExtMapBuffer1);
   hFile=FileOpenHistory(szSymbol + Minutes_for_HSTfilename + ".hst", FILE_READ);
   if(FileSize(hFile)<0){
   // Дабы не затереть реальные файлы историй, в имя файла добавлен "0" перед периодом
   hFile=FileOpenHistory(szSymbol + Minutes_for_HSTfilename + ".hst", FILE_BIN|FILE_WRITE);
   if(hFile < 0) return(-1);
   //---- Записать заголовок hst-файла
   szCopyright="(C)opyright 2003, MetaQuotes Software Corp.";
   FileWriteInteger(hFile, nVersion, LONG_VALUE);
   FileWriteString(hFile, szCopyright, 64);
   FileWriteString(hFile, szSymbol, 12);
   FileWriteInteger(hFile, Minutes_for_HSTfilename, LONG_VALUE);  //  файл - М2
   FileWriteInteger(hFile, iDigits, LONG_VALUE);
   FileWriteInteger(hFile, 0, LONG_VALUE);
   FileWriteInteger(hFile, 0, LONG_VALUE);
   FileWriteArray(hFile, iUnused, 0, 13);
   FileFlush(hFile);
   iFilePos=FileTell(hFile);
    }
    
    else{ iFilePos=FileTell(hFile); }
   i_time = CurTime();
   i_time_bar0 = Time[0];
   d_open = Close[0];
   d_low = d_open;
   d_high = d_open;
   d_close = d_open;
   d_volume = 1;
   d_volume_bar0 = Volume[0];

   /*d_low_bar0 = Low[0];
   d_high_bar0 = High[0];*/
   
   //----
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator deinitialization function                       |
//+------------------------------------------------------------------+
int deinit()
  {
   if(hFile>=0)
    { 
      FileClose(hFile); 
      hFile=-1; 
    }
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int start()
  {
   CurrTickNumber++;
   //********* Обновление данных в переменных текущего бара **************
   d_close = Close[0];
   if (d_low > d_close) d_low = d_close;
   if (d_high < d_close) d_high = d_close;

   // Объем
   if (i_time_bar0!=Time[0])  // если на реальном графике появился новый бар, а для 
                              //   нас еще не набралось тиков закончить тиковый бар...
    { //расчитать изменение объема с учетом пополнения предыдущего реального бара
      d_volume += Volume[1] + Volume[0] - d_volume_bar0;
      i_time_bar0 = Time[0];
    }
   else
    { //расчитать изменение объема только с учетом текущего реального бара
      d_volume += Volume[0] - d_volume_bar0;
    }
   d_volume_bar0 = Volume[0];

   // Обновление данных последнего бара
   FileSeek(hFile, iFilePos, SEEK_SET);
   FileWriteInteger(hFile, i_time, LONG_VALUE);
   FileWriteDouble(hFile, d_open, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_low, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_high, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_close, DOUBLE_VALUE);
   FileWriteDouble(hFile, d_volume, DOUBLE_VALUE);

   if (CurrTickNumber==NumTicksPerBar)
   {
      iFilePos=FileTell(hFile);
      CurrTickNumber=0;
      i_time = CurTime();// / 60 / Minutes_for_HSTfilename;
      //i_time *= 60 * Minutes_for_HSTfilename;
      d_open = Close[0];
      d_low = d_open;
      d_high = d_open;
      d_close = d_open;
      d_volume = 1;
      FileWriteInteger(hFile, i_time, LONG_VALUE);
      FileWriteDouble(hFile, d_open, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_low, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_high, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_close, DOUBLE_VALUE);
      FileWriteDouble(hFile, d_volume, DOUBLE_VALUE);
   }
   FileFlush(hFile);

   // Обновление окна автономно открытого файла
   int hwnd=WindowHandle(Symbol(), Minutes_for_HSTfilename);
   if (hwnd!=0) PostMessageA(hwnd, WM_COMMAND, 33324, 0);

   Comment("Отладочная Инфа: \n"+
           "Тиков в баре: " + CurrTickNumber +
           "\nOpen=" + d_open + "    Close=" + d_close +
           "\nHigh=" + d_high + "    Low=" + d_low +
           "\nVol=" + d_volume +
           "\nПозиция файла: " + iFilePos
   );

   return(0);
  }
//+------------------------------------------------------------------+


 
個人的には、開発者が技術的な問題を人為的に作り出し、MTを改善する気がない(あるいは不可能である)ことを正当化するために、ティックの歴史という観点から見ているような気がするのです。<br /> translate="no">。
ティックファイル文字列(Time,Close,Volume) = (int,double,double) = (4,8,8,) = 20 bytes.である。


引用符は、それに応じて10000と100(日本語の場合)を掛けることで整数に格納することができる。
また、キーポイントと最後の引用符からの相対的なオフセットを保存することができます。
これらの問題はすべて技術的なものです。
一番の問題は、戦略的なことです。
クオーターはNOT WANTで、やらないのだと思います。競合他社に圧迫された場合のみ、カチッとした端末が前提になる。
もうひとつ問題があります。お客さまは端末代を払っていない。
サーバーを購入するDTが支払うものであり、DTはティックターミナルには興味がありません。
 
証券会社はティックターミナルに興味がない。証券会社の相場のクセを利用して動くピップスマンがいるからだ。

証券会社がターミナル(ティックやタイムターミナル)のことを考えることはまずないでしょう。彼らは他のことに興味があるのです。証券会社に必要なものは、すでに開発元から与えられていると思います(自動売買の許可・禁止、市場価格以外での取引中止など)。チャンピオンシップの統計によると、どの証券会社も良い「台所」を手配することができ、何か特別なティック端末が登場しても、基本的には何も変わらないし、少なくとも証券会社は、それが開発されれば、導入に反対することはほとんどないだろう。まあ、まだティックシリーズを導入する必要性の詳細な証拠がないため、問題は今のところでしょう。
何でもできる-どんなティックやタイムフレームでも」というOmegaプラットフォームからティックプルーフの結果を見てみるのも面白いかもしれませんね。

ブローカーについての議論は、すでにこのフォーラムの範疇を超えていますが。これから掃除するんだろうなぁ:o)
 
solandr の提案には合理的な根拠があると思うのですが、個人的には研究用に必要なので、1週間ではまともなものが提供できないのでは......と思っています。

"MQL4:ティックコレクター
Expert Advisorは指定したシンボルのティック履歴を保存する
 
延々と続く無意味な口先だけのチクリ合戦から、詳細なエビデンスに移行することを提案します。そのためには、次のようなことが必要です。必要であれば、選択されたティック数のティックシリーズを生成し、データをCSVファイルに書き出す簡単なスクリプトを作成することができます。さらに、このファイルをEXCELで開き、EXCELの標準ツールでティックシリーズの図を描くことができます。このようなチャートが、例えば指定したティックフレームで一週間利用可能であれば、標準のMT4チャートと比較し、例えばトレンドサポート/レジスタンスラインなどを使って標準の時系列から何らかの方法で受け取ることができなかった、いくつかの追加のエントリ/エグジットポイントがティックフレームのチャートから得られたことを示すことができます。

Dearsolandr!
なぜ、この極論に苛立つのですか?なぜ、あなたは未来について、何をすべきか、何をすべきでないか、すべてを知っていると信じ込んでいるのですか?

あなたの提案する「証明書作成」プログラムは、原理的に間違っています。ティックトレードの成功だけを信用できる論拠にしたいのでしょう。そう考えると、既存のT/Fは全く必要ないことになります。

お知らせします。ティック履歴を書き込むだけでなく、チャート上にリアルタイムで表示するExpert Advisorを ずいぶん前に書いたことがあります。つまり、他のフレームでできることは、すべてティックチャートでできるのです。MT4+MCL4がいかに強力なツールであるか、改めて実感しました。 また、このサービスをビルトイン化することがそれほど難しくないことも示しています。

それに、ティックデータの調査にはかなりの時間を費やしています。そのために市場で成功したかどうかは、絶対に関係ない。人が何かを成し遂げるかどうかは、その人の能力と努力の結果です。しかし、結果を出すためには、まず能力を持っていなければならない。この条件は十分ではなく、必要である !:-)

なぜ、ティックフレームではなく、タイムフレームで動作する可能性があるのでしょうか?このような状況は、開発者の能力(時間、人など)に限りがあるため、理解できることです。しかし、サービスの完成度や戦略という点では、まったくもって容認できない。したがって、多少なりとも今日の市場に合っていれば、明日はそうではない。
 
2Jhonny
ショーランドの提案には合理的な根拠があると思いますが、個人的には研究のために必要で、1週間では本格的なものは提供できないと思っていますが、その種のプリプロダクションのインジケーターはあります


そのとおりです。まさにその通りです。

ちなみに、このことはEAとして実装すべきです。インジケータがティックをスキップする !
ファイルの破損を防ぐため、次のようにファイルを開く必要があります:FILE_BIN|FILE_READ|FILE_WRITE
そして、書き込む前に、書き込みポインタをファイルの末尾にセットしてください。
 
Yurixx さん、私は自分の意見を言っただけですよー。ここは自由な場であり、誰もが自分の意見を表明する権利を持っていますよね。それとも、常に多数派の意見に耳を傾けるべきなのでしょうか?しかし、大多数は「漏れる」のです。チャンピオンシップを見てください。

人々は開発者に歴史を刻む ことを求めたが、開発者はきっぱりと拒否した。では、次はどうするか?開発者が「働く人々の願い」を聞いてくれなかったという不満を、ここに山ほど書き込むだけでしょう?私は、開発者に圧力をかけるための合理的な選択肢を提案した、ただそれだけです。もし、みなさんが、この問題に対して何の進展もなく、ただ延々と口先だけの文句を言うだけなら、どうぞ、私個人は何も文句はありませんよ。
 
"MQL4: Tick collector <br / translate="no"> Expert Advisorは、指定したシンボルのティック履歴を保存します。


もちろん、Expert Advisorには感謝したいのですが、今調べたら、データをcsvで保存するのに対して、私のは履歴に保存して、オフラインでチャートを開いて分析できるように設計されているんですね。
 
もちろんExpert Advisorのおかげですが、今調べたら、csvで保存するのに対して、私のは履歴で保存するようになっていて、このチャートはオフラインで開いて分析することができます。

"MQL4: simple_csv2fxt "です。
シンプルなcsvからfxtへの変換ツールです。


私のExpert Advisorとこのスクリプトを組み合わせて、少し手直しすれば完璧です;)
 
ティックデータが必要かどうかは、答えは明白で、より多くの可能性が提供されればされるほど、より完全で高品質なサービスとなり、どちらかを必要とする人々が必ず存在するからです...。この機能は近い将来実装されるのか、という問いに対する答えです。- 明らかに違う...そこには、ひとつの重要な理由があると思うのですが...。すなわち - 新しい契約の形で、この段階でMetakvotesの収益をもたらし、これが論理的で正しいもののみ実装されます...収入が仲介会社(ブローカー、DCなど)をもたらすように、その後、彼らの生活を簡素化することが実装されますが、彼らの生活を複雑にするものではありません...
チクタクデータは、以下の理由で彼らの生活を複雑なものにします。
1.ティックデータがあれば、ティックシンボルで取引するExpert Advisorが必ず出てくるので、そのようなExpertが重なると大変なことになるのです。
2)信頼性の高いダニデータがあれば、テスターでダニの専門家をテストできる可能性が出てくる(これも数が増えることになる)。
3.ティックデータにアクセスした後、一般の人々はリアルボリュームへのアクセスを要求するだろう :)))))
4.4位は開発者のやる気のなさ、忙しさ(証券会社の需要があれば、2週間で作ってしまう)。
5.そして最後に、非常識なトラフィックとディスク容量についての「切り札」的な議論...。