右のTCのいくつかの兆候 - ページ 15

 
Nikolai Semko:

もし、あなたのTSが動作するためにすべての履歴を必要としないなら、私はあなたに悪い知らせをします。

しかし、歴史の影響は、その深さによって指数関数的に薄れていく。それはそうですね。

だから、私は歴史を対数で表現しているのです。

つまり、20年分の履歴を使うなら、最も近い週刊誌の記事は全体の8割の大きさになるのです。


ZS 重力とよく似ていますね。私たちの惑星の軌道は、光が250万年かけて到達する隣の銀河、アンドロメダ星雲の重力に大きく影響されていることをご存知でしょうか。

数字、数字、数字。

地球は太陽の周りを秒速約30kmで回っています。

太陽は銀河の中心を秒速230kmで回っている。

私たちの天の川銀河とアンドロメダ星雲の銀河は、秒速300kmで互いに接近している。

ZS 続編は...。それだけではありません

我々の銀河系とその近隣の銀河は、M83銀河に向かって毎秒500kmの速度で移動している。

私たちの銀河系は、全体として秒速約1000kmで宇宙を移動しています。

ドラッグは?

 

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

良好なTSの兆候あり

fxsaber, 2020.03.01 21:56

コメントで、時間を反転させた後のTSの挙動について考えてみてはどうかと提案されました。まるで巻き戻しが作動したかのように、刻みは逆に(未来から過去へ)進みます。

また、どのシンボルで反転がTSの結果に影響を与えないと、それは市場パターンの重大な変化であるために、読み取ることができます。

幸いなことに、FXのシンボルは、理論的には、この時間反転で相場パターンを破壊することはないはずです。これをあるTSでテストしてみると、面白いことがわかりました。


まず、MQL5でティックシリーズの反転を行うコードです。

int TimeDayOfWeek( const datetime Date )
{
  MqlDateTime mTime;
  
  TimeToStruct(Date, mTime);
  
  return(mTime.day_of_week);
}

#define  HOUR 3600
#define  DAY (24 * HOUR)
#define  WEEK 7

// https://www.mql5.com/ru/forum/170953/page8#comment_6940794
datetime GetTimeDayOfWeek( const datetime TimeSource, const int Shift = 0, const ENUM_DAY_OF_WEEK Day = SUNDAY )
{
  const datetime Res = TimeSource / DAY * DAY;
  
  return(Res - (((WEEK + (TimeDayOfWeek(Res) - Day)) % WEEK) + Shift * WEEK) * DAY);
}

void ReverseTick( MqlTick &Tick, const long &Offset )
{
  Tick.time_msc = Offset - Tick.time_msc;
  Tick.time = (datetime)(Tick.time_msc / 1000);
  
  return;
}

// Инверсирование времени.
void ReverseTicks( MqlTick &Ticks[] )
{
  const int Size = ArraySize(Ticks);
  
  if (Size)
  {
    const long Offset = (long)(GetTimeDayOfWeek(Ticks[0].time, 0, MONDAY) + GetTimeDayOfWeek(Ticks[Size - 1].time, -1, SATURDAY)) * 1000;

    for (int i = 0; i < Size; i++)
      ReverseTick(Ticks[i], Offset);

    ArrayReverse(Ticks);
  }

  return;  
}


この機能をベースに、反転したシンボルを作成するスクリプトが添付されている。私たちは、それを使って仕事をします。その結果は以下の通りです。


ストレートシンボルにオプティマイザーのベストパス。


時間反転シンボルにも同じパスがある。


結論はない。


この結果は、理論的な興味のみです。解釈が難しいです。

コードシンボルがあり、希望すれば誰でも反転したシンボルにTSを試すことができます。

 
Алексей Тарабанов:

ドラッグは?

私が見る限り、この掲示板の中でも食指が動く方だと思います。そして、自分が言っていることを整理することに気を配っていますね。

 
Uladzimir Izerski:

私が見る限りでは、この掲示板の中でも特にエッジの効いた人たちだと思います。そして、発言にも気を配っていますね。

私は彼に尋ねたのであって、あなたではない)。

 
fxsaber:

この結果は、今のところ理論的な興味にとどまっています。解釈が難しいです。

シンボルコードがあるので、希望すれば誰でも反転したシンボルでTSを試せます。

シンメトリーは、その栄光の姿を現したのです。そうでなければならない。そして、もっと早く何かを証明したかったのです。(焦りました))

 
Алексей Тарабанов:

私は彼に尋ねたのであって、あなたではない)

空疎で下品な質問をしないこと。そうやって自分の信用を落としているだけなのです。

 
Uladzimir Izerski:

空疎で下品な質問をしないこと。こうやって自分の信用を落としていくだけなんだよ。

ネジがないんです。

 
Алексей Тарабанов:

困っているわけではないんです。

控えめというのが正しいでしょう。

 
Nikolai Semko:

...

適切なTSには、適切なデータ構造、ストレージ、アクセスベースが必要です。

現在のものは、きちんとしたTSを作るには非常に面倒で不器用です。

その結果、より便利でコンパクト、かつ軽快になったと思います。

一言で説明すると

...

その後、tick配列も削除し、30~40MBのデータベースから最大1MBの対数圧縮データベースを形成することができます。 このデータベースには、現在の瞬間からシンボルの全歴史が網羅されています。

...

データベースの "対数圧縮 "に興味があります。詳しく教えてください。

 
Vladimir:

データベースの「対数圧縮」に興味津々もう少し具体的に教えてください。

それはちょっと違うんじゃないですか?

正しくは、「データ表現の対数スケールによる圧縮」です。

簡単なことです。

このようなシステムにおけるバーの構造を紐解いてみると、こうなる。

struct iRates {
   double    open;
   double    high;
   double    low;
   double    close;
   datetime  open_time;
   datetime  high_time;
   datetime  low_time;
   datetime  close_time;
   int       volume;
};

で、バーの時間帯は配列内の各バーで異なる。

例えば、28000のような棒グラフが有限の配列で存在する。

ゼロバーの時間は、例えば1秒とする。
1本目のバーの期間は int(1.00047) = 1秒となります。
2本目のバーの期間は int(1.00047^2) = 1秒となります。
3本目のバーの期間は int(1.00047^3) = 1秒となります。
...
の場合、1500bar の期間は int(1.00047^1500) = 2 秒となります。
...
の場合、3000bar の期間は int(1.00047^3000) = 4 秒となります。
...
10000 bar の期間は int(1.00047^10000) = 109 秒 = 1 分 49 秒となります。
...
12000 bar の期間は int(1.00047^12000) = 281 秒 = 4 分 41 秒となります。
...
15000 bar の期間は int(1.00047^15000) = 1150 秒 = 19.21 分 ...となる。
...
17000本目のバーの期間は int(1.00047^17000) = 2945秒 = 49分 ... です。
...
20000本目のバーの期間は int(1.00047^20000) = 12061 seconds = 3.35 hours となります。
...
25000本目のバーの期間は int(1.00047^25000) = 126404 秒 = 1.46 日となります。
...
27999本目のバーの期間は int(1.00047^27999) = 517331秒=5.99日となります。


棒グラフは1本あたり平均20バイト程度の大きさでパックされて格納されている

クイックアクセス用のインデックスアレイは 全体の5%程度を占める

つまり、このデータベースの総容量は28000*20*1.05=588kBで、この配列で40〜50年の歴史をカバーすることになる。