дыры в данных

[[Удален]]

вот хочу некоторые трдности порешать...

1. одновременый доступ ко многим большим сериям. Терминалу не хватает памяти если одновременно обращаться на несколько символов да еще с большой историей.
   
2. сглаживание временных дыр. В тех сериях, с которыми работал я, было обнаружено около 7-10% пропущенной информации.
   
3. восстановление значений во временных дырах. Тут на самом деле еще не совсем понимаю, как организовать такое восстановление... пока придумкал такой чудо - способ: для целевой серии иметь одноименную от другого поставщика (или даже от нескольких) - может у них дыры будут в разных местах, и можно будет на этом сыграть.
   
4. централизованное хранение серий, поставляемых из нескольких терминалов мт и предоставление данных в несколько терминалов. Не очень приятно иметь терминал как штуку в себе по отношению к данным. Можно конечно экспортировать и дальше что то с данными делать но хочется общности.
   

для решения этих пунктов начал писать библиотечку под названием ds (data storage)

1. одновременый доступ ко многим большим сериям. Компонента не держит в памяти постоянно все символы со всей историей а подгружает нужную и выгружает давно не используемую информацию динамически.
   
2. сглаживание временных дыр. Компонента представляет серию в виде (упрощенно) линейного массива значений, индексируемых временем а не номером бара.
   
3. восстановление значений во временных дырах. Компонента употребляет данные одновременно из нескольких источников и сливает их вместе минимизируя дыры.
   
4. централизованное хранение серий, поставляемых из нескольких терминалов мт и предоставление данных в несколько терминалов. Компонента хранит все переданные ей данные в одном месте. Что то типа общего контейнера на всех. Компонента по запросу предоставляет любые данные, которые у нее есть. Компонента одновременно доступна из более чем одного процесса (терминала мт)
   
5. 
   

библиотека оперирует следующими объектами:

• компонента ds
  
• вид данных
  
• подвид данных

схема данных:
компонента содержит набор видов данных (ассоциирую с символом, например EURUSD). Вид данных содержит набор подвидов данных (ассоциирую с поставщиком данных). Вид и подвид содержат серии данных, индексируемые временем.

сценарий работы:

1. создать экземпляр компоненты указав место хранения данных или получить существующий
   
2. зарегистрировать виды и подвиды данных или получить зарегистрированные
   
3. сливать в компоненту данные зарегистрированного вида или подвида
   
4. брать из компоненты данные вида, выровненные по времени и заполненные данными в дырах за счет данных подвидов
   

одновременно один и тот же экземпляр компоненты доступен из разных процессов ос - то есть из разных терминалов, причем оперирует одними и теми же данными (за счет общего места хранения в файловой системе и разделяемой памяти). Таким образом предполагаю такой стиль использования:
в первом терминале работаю с дц на котором торгую, выливаю из него в компонету данные сивола, которым торгую в вид (целевой). Из нескольких других терминалов, соединенных с другими дц, выливаю данные в компоненту как данные подвидов целевого вида. В первом терминале беру из компоненты данные целевого вида, без временных дыр и с заполненными значениями в дырах там, где хотя бы у одного подвида эти данные есть.

значения
курсы физически хранятся в виде 4 байта вещественное. Курсы меньше нуля считаю неизвестными (ими заполнены дыры).
время измеряется в секундах, так же как в мт

прилагаю собранную библиотеку.

она еще в зародышной стадии, но кое что уже работает.
в скором времени допишу и доотлажу саму библиотеку и напишу несколько скриптов для мт

исходные тексты не скрываю, могу предоставить по запросу

кто хочет - может сам скрипты какие или индикаторы для мт набросать...

интерфейс библиотеки

//////////////////////////////////////////////////////////////////////////
//инициализация экземпляра компоненты
//принимает path - путь к директории файловой системы для хранения данных
//возвращает ключ экземпляра или -1 в случае ошибки
int ds_init(
	const char *path);

//////////////////////////////////////////////////////////////////////////
//деинициализация экземпляра компоненты. Все данные сбрасываюся на диск
//принимает key - ключ экземпляра компоненты (см ds_init)
//возвращает всегда 0, даже если ключ неправильный
int ds_deinit(
	int key);
	
//////////////////////////////////////////////////////////////////////////
//регистрация вида данных
//принимает key - ключ экземпляра компоненты (см ds_init)
//принимает name - наименование вида, например "EURUSD"
//возвращает ключ вида или -1 в случае ошибки
int ds_registerKind(
	int key,
	const char *name);
	
//////////////////////////////////////////////////////////////////////////
//регистрация подвида данных
//принимает key - ключ экземпляра компоненты (см ds_init)
//принимает kind - ключ вида данных (см ds_registerKind)
//принимает name - наименование подвида, например "from Alpari"
//возвращает ключ подвида или -1 в случае ошибки
int ds_registerSubKind(
	int key,
	int kind,
	const char *name);
	
//////////////////////////////////////////////////////////////////////////
//установка значения вида данных
//принимает key - ключ экземпляра компоненты (см ds_init)
//принимает kind - ключ вида данных (см ds_registerSubKind)
//принимает time - время в секундах
//принимает value - значение
//возвращает 0 в случае успеха или -1 в случае ошибки
int ds_setTimedValueKind(
	int key,
	int kind,
	double time,
	double value);
	
//////////////////////////////////////////////////////////////////////////
//установка значения подвида данных
//принимает key - ключ экземпляра компоненты (см ds_init)
//принимает subKind - ключ подвида данных (см ds_registerSubKind)
//принимает time - время в секундах
//принимает value - значение
//возвращает 0 в случае успеха или -1 в случае ошибки
int ds_setTimedValueSubKind(
	int key,
	int subKind,
	double time,
	double value);
	
//////////////////////////////////////////////////////////////////////////
//получение набора значений вида данных
//принимает key - ключ экземпляра компоненты (см ds_init)
//принимает kind - ключ вида данных (см ds_registerKind)
//принимает time - время в секундах
//принимает amount - размер массива values
//принимает values - массив размером amount
//пишет в массив values данные согласно запросу
//возвращает количество данных, записанных в массив values или -1 в случае ошибки
int ds_getTimedValuesKind(
	int key,
	int kind,
	double time,
	int amount,
	double *values);
	
//////////////////////////////////////////////////////////////////////////
//получение набора значений подвида данных
//принимает key - ключ экземпляра компоненты (см ds_init)
//принимает subKind - ключ подвида данных (см ds_registerSubKind)
//принимает time - время в секундах
//принимает amount - размер массива values
//принимает values - массив размером amount
//пишет в массив values данные согласно запросу
//возвращает количество данных, записанных в массив values или -1 в случае ошибки
int ds_getTimedValuesSubKind(
	int key,
	int subKind,
	double time,
	int amount,
	double *values);

с вниманием прочитаю любые комментарии, пожелания, критику.

[bank]

если объединять котировки, то у разных ДЦ разные часовые пояса UTC и неделя на дневных графиках может состоят из 5ти или из 6ти свечей ((

у меня дополнительные терминалы не передают котировки а делают предварительные расчеты и через CSV-файлы передают эти полуфабрикаты на ведущий терминал

[[Удален]]

sabluk >>:

если объединять котировки, то у разных ДЦ разные часовые пояса UTC и неделя на дневных графиках может состоят из 5ти или из 6ти свечей ((

у меня дополнительные терминалы не передают котировки а делают предварительные расчеты и через CSV-файлы передают эти полуфабрикаты на ведущий терминал

разные часовые пояса победю точно.

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

на основном символе есть данные за [..., пт, сб, пн...] а на доп символах только [..., пт, пн...]? Тогда буду искать поставщиков которые в субботу работают..

Объединять серии планирую не в лоб, немного сопрягая. Еще не сформулировал точно, примерно так:

• найти дыру в целевой серии
• подобрать доп серии, у которых в месте дыры и в ее окресностях есть значения
• примерно нормировать доп серии по значениям из окресности дыры
• насунуть нормированные значения из доп серий в целевую серию
  

а какие у вас предварительные расчеты?

[bank]

shtoba >>:

а какие у вас предварительные расчеты?

да просто значения некоторых индикаторов для советника

[Mikhail Simakov]

вам делать нечего?

[[Удален]]

через CSV-файлы

кстати, уже сейчас эта библа позволяет транслировать серии между терминалами через шареную память, что намного оперативней и легковесней в плане машинных ресурсов

[[Удален]]

m_a_sim >>:
вам делать нечего?

а какой выбор? Мне нужны такие данные. Какие варианты?

[bank]

shtoba >>:

кстати, уже сейчас эта библа позволяет транслировать серии между терминалами через шареную память, что намного оперативней и легковесней в плане машинных ресурсов

согласен, мне знаний не хватало самому такое закодить, респект

[Vadim Zhunko]

Полезное дело. Сам хотел на Java написать это. Всё времени не хватает.

Имею ввиду собирать историю из нескольких поставщиков.

Есть ещё вариант. Существует полная тиковая история. Может из неё формировать бары? Там можно будет даже тиковые (равнообъёмные) бары делать.

[[Удален]]

shtoba >>:
вот хочу некоторые трдности порешать...

сценарий работы:

1. создать экземпляр компоненты указав место хранения данных или получить существующий
   
2. зарегистрировать виды и подвиды данных или получить зарегистрированные
   
3. сливать в компоненту данные зарегистрированного вида или подвида
   
4. брать из компоненты данные вида, выровненные по времени и заполненные данными в дырах за счет данных подвидов
   

одновременно один и тот же экземпляр компоненты доступен из разных процессов ос - то есть из разных терминалов, причем оперирует одними и теми же данными (за счет общего места хранения в файловой системе и разделяемой памяти). Таким образом предполагаю такой стиль использования:
в первом терминале работаю с дц на котором торгую, выливаю из него в компонету данные сивола, которым торгую в вид (целевой). Из нескольких других терминалов, соединенных с другими дц, выливаю данные в компоненту как данные подвидов целевого вида. В первом терминале беру из компоненты данные целевого вида, без временных дыр и с заполненными значениями в дырах там, где хотя бы у одного подвида эти данные есть.

а что мешает использовать базы данных? специализировнный продукт, который хранит в одном общем месте и разделяет память, да еще и в сжатом виде) 

все что вы делаете легко левой ногой организовать в бд, сливаете с разных терминалов данные и потом собираете запросами в любом удобном виде, и по-скорости будет быстрее

не очень вникал  в то что вы написали, но голосую за бд в вопросах хранения и операций с большими объемами данных

[[Удален]]

Zhunko >>:

Полезное дело. Сам хотел на Java написать это. Всё времени не хватает.

Имею ввиду собирать историю из нескольких поставщиков.

Есть ещё вариант. Существует полная тиковая история. Может из неё формировать бары? Там можно будет даже тиковые (равнообъёмные) бары делать.

ыыы...

1.бары. Библа не работает с ohlc, только штучные значения... не было надобности в полноценных барах. И скорее всего надобности не будет (с моей стороны). Можно вместо одной серии использовать 4. Только их тогда придется ручками сформировать/рассортировать: эта серия - open, эта - close, тд. а библа будет только хранить.

2. тики

а. тик по времени. Библа не поддерживает плавающий шаг отсчетов, можно сделать маленький но чтоб постоянный был - с тиками плохо вяжется. Что то типа "секундок" - да.

б. тик по объему. Время подменить на объем?.. Но тогда по концепциям библы у объема должен быть шаг, как тут считать, что будет значением.. не очень представляю. И вот еще момент - среди тиков невозможно определить есть ли среди них дыры.. имхо. Никогда не работал с равнообъемами, где гоню - поправьте