Тестирование Систем прогнозирования в реальном времени - страница 74

 
neoclassic писал(а) >>
Можно посмотреть файл forecast.csv

уже нет :о( Но на на выходных я еще нагенерю! :о)

 
Мне понять структуру данных. Я помню решал аналогичную задачу, нужно было вывести траектории на график. Но для этой цели использовал индикатор. Так вот, нужно было получить длину траекторий для определения SetIndexShift. Файл с траекториями был в таком формате: строки со значениями 1й траектории, пустая, 2й, пустая и тд. Чтобы определить длину каждый отсчет проверял на пустую строку, и когда находил ее - начинал заполнять следующий буфер и определялся со сдвигом. Надеюсь помог.
 
grasn >>:

Я таки написал скрипт формирования массива вероятных реализаций (очень простой получился):

Вот работа скрипта:

Вот как автоматически определять длину прогнозной выборки из текстового файла - это для меня загадка, пока задается руками. Если есть идеи - подскажите, плииз.

У меня в ShowSeries есть функция определения размера серии - делается влоб путем лишнего упреждающего чтения файла, вот так:

int GetFileCount()
{
  int count = 0;
  int columns = 0;
  int handle = FileOpen(FileName, FILE_CSV|FILE_READ, Delimiter);
  if(handle > 0)
  {
    while(!FileIsEnding(handle))
    {
      string x = FileReadString(handle);
      if(StringLen(StringTrimLeft(StringTrimRight(x))) == 0) break;
      if(count == 0)
      {
        columns++;
      }
      if(FileIsLineEnding(handle))
      {
        count++;
      }
    }
    FileClose(handle);
  }
  Comment("Column ", ColumnNo, "(", columns, "),", " Lines:", count);
  return(count);
}

Если сохранять в файл двоичного формата, то можно быстро вычислить по очевидной формуле (длина-файла - заголовок-если-есть)/размер-одной-записи.

А вот выгоду от использования кучи объектов вместо индикаторов я не понимаю. Я обычно наоборот, если случается необходимость использовать какой-то код, в котором применены объекты, переделываю его на буфера. Единственные объекты, которые нужны, это надписи, имхо ;-), и то только потому, что метаквоты не удосужились сделать текстовые индикаторы.

И еще важный момент. По объектам не удастся построить ТС. Индюк должен быть сигнальным - давать доступные через iCustom сигналы.

Я б это направление с объектами прикрыл как неправильное бай-дизайн ;-). Но Вам конечно виднее.

 
neoclassic >>:
Мне понять структуру данных. Я помню решал аналогичную задачу, нужно было вывести траектории на график. Но для этой цели использовал индикатор. Так вот, нужно было получить длину траекторий для определения SetIndexShift. Файл с траекториями был в таком формате: строки со значениями 1й траектории, пустая, 2й, пустая и тд. Чтобы определить длину каждый отсчет проверял на пустую строку, и когда находил ее - начинал заполнять следующий буфер и определялся со сдвигом. Надеюсь помог.

там матрица. Мне нужно просто определить размер этой матрицы.

 
marketeer >>:

У меня в ShowSeries есть функция определения размера серии - делается влоб путем лишнего упреждающего чтения файла, вот так:

Если сохранять в файл двоичного формата, то можно быстро вычислить по очевидной формуле (длина-файла - заголовок-если-есть)/размер-одной-записи.

А вот выгоду от использования кучи объектов вместо индикаторов я не понимаю. Я обычно наоборот, если случается необходимость использовать какой-то код, в котором применены объекты, переделываю его на буфера. Единственные объекты, которые нужны, это надписи, имхо ;-), и то только потому, что метаквоты не удосужились сделать текстовые индикаторы.


Функцию я увидел и даже концептуально понял, что она делает. Остается разобраться как это работает. Ок. возбму таймаут на выходные, подумаю, если не пойму - буду клянчить объяснить.


И еще важный момент. По объектам не удастся построить ТС. Индюк должен быть сигнальным - давать доступные через iCustom сигналы.

Я б это направление с объектами прикрыл как неправильное бай-дизайн ;-). Но Вам конечно виднее.


Это я знаю, но мне пока исключительно для визуализации прогнозов. Торговаться то конечно будет уровень, а данные я в матрицы буду загонять :о)

 
grasn >>:

там матрица. Мне нужно просто определить размер этой матрицы.

Если каждая строка матрицы - траектория, то я бы сделал так
   while(FileIsEnding(Handle)==false)
   {
      if(FileIsLineEnding(Handle)) //если строка закончилась, начинаем новую траекторию с 0
      {
         i=0;
      }

      COUNT=FileReadString(Handle);
      realisation=NormalizeDouble(StrToDouble(COUNT), 5);

      ObjectCreate(DoubleToStr(idCount, 10), OBJ_ARROW, 0,Time[0]-timeShift*15*60)+(i)*Period()*60+1, realisation);
      ObjectSet(DoubleToStr(idCount, 10), OBJPROP_ARROWCODE, 250);
      
      i=i+1;
      idCount=idCount+1;

   }
 
neoclassic >>:
Если каждая строка матрицы - траектория, то я бы сделал так

До сего момента grasn генерил файлы, где строки - это отсчеты времени, а траектории писались по столбцам. Оставить именно такую раскладку было бы удобнее, по крайней мере имхо;-) -я её везде использую. Кстати, и Дедуктор тоже.

 

Я посмотрел код индикатора, который grasn выложил на предыдущей странице, он считывает траектории по строкам. Проблема насколько я понял - нужно знать длину траекторий, что бы вовремя начинать отрисовку с 0-го бара.

Предложенный мной способ автоматически определяет конец строки и передергивает каретку :-)

Насчет того, что удобнее - согласен.

 
Коллеги, спасибо огромное за консультацию. Буду пробовать.
 

EURUSD, M15.

Прогноз на 300 отсчетов (чуть больше 3 дней).

Основные траектории:


Две наиболее вероятные группы траекторий, приблизительно "равноправные":


Перенес на MT:



PS1: На всякий случай - система тестируется, использовать для торговли еще рано.

PS2: Сильно подозреваю, что график "сдвинется" в историю при первой котировки.

Файлы:
files.rar  44 kb