Баго-фича при сохранении данных Trade
Atom
10.11.2012


Решил описать один неприятный эффект, с которым мне пришлось столкнуться и который, увы, забрал много времени.

Если Trade.Price содержит «лишние» десятичные цифры после запятой (по всей видимости, цифры большей точности, чем Security.MinStepPrice), то при сохранении таких данных в TradeStorage и последующем чтении данные очень сильно искажаются ( более чем на 100%) из-за больших накапливающихся ошибок.

У меня этот эффект возник при генерации и сохранении искусственных сделок, информацию для которых я брал из альтернативных (кастом) таблиц (мировые индексы, по которым не поступала информация в таблицу всех сделок).

Теги:


Спасибо:


Mikhail Sukhov

Фотография
Дата: 11.11.2012
Ответить


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

Mikhail Sukhov

Фотография
Дата: 12.11.2012
Ответить


Mikhail Sukhov Перейти
Проблема определена. Будет фикс на Кодеплексе. Сейчас хранилище поддерживает цены, не кратные шагу. Предполагается, что такая цена может возникнуть у внесистемных сделок (не обязательное условие).


Фикс доступен на кодеплексе. Просьба отписаться о результатах.
Спасибо:

DrChemist

Фотография
Дата: 14.11.2012
Ответить


Проверил на версии 4.1.6
Подтверждаю. Проблема устранена полностью . Данные читаются и восстанавливаются точно с любым количеством десятичных знаков после запятой в поле Price.

Для тех, кому это может быть нужно, обращаю внимание, что, по всей видимости, формат записи изменился. Мне не удалось прочитать данные записанные версией 4.1.6 программой, использующей библиотеку 4.1.5

Однако я обнаружил еще один эффект, с которым хотел бы разобраться.
Дело в том, что я обнаружил, что в хранилище сохраняются не все искусственные сделки, которые я создаю.
Возможно, происходит некоторая фильтрация ( возможно, правильная) или в _tradesBuffer Гидры или в самом хранилище.

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

Вот типичный пример, сделанный по моим собственным независимым логам:

Код

1. miniSP500&WIDX,20:14:01,2012-11-14 20:14:01.0(00:00:01.9850995),1365.73553345389,buy
2. miniSP500&WIDX,20:14:01,2012-11-14 20:14:01.0(00:00:01.9850995),1365.73553345389,sell
3. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:00.9850995),1365.73553345389,buy
4. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:00.9850995),1365.73553345389,sell
5. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:01.9444995),1365.73704038577,buy
6. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:01.9454995),1365.73704038577,sell
7. miniSP500&WIDX,20:14:03,2012-11-14 20:14:03.0(00:00:00.9464995),1365.73704038577,buy
8. miniSP500&WIDX,20:14:03,2012-11-14 20:14:03.0(00:00:00.9464995),1365.73704038577,sell


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

Если посмотреть, например, на строки 2 и 4, 5 и 7, то видно, что они соответствуют строго одному и тому же компьютерному времени, но задержки как-бы разные. Все параметры сделки, кроме времени в них идентичны.

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

Из хранилища были прочитаны вот эти данные:

Код

[1]	{2012-11-14 20:14:01 0 1365.73553345389 1}
[2]	{2012-11-14 20:14:01 0 1365.73553345389 1}
[3]	{2012-11-14 20:14:02 0 1365.73553345389 1}
[4]	{2012-11-14 20:14:02 0 1365.73553345389 1}
[7]	{2012-11-14 20:14:03 0 1365.73704038577 1}
[8]	{2012-11-14 20:14:03 0 1365.73704038577 1}


Т.е. сделки, соответствующие строкам 5 и 6 были отфильтрованы (отбракованы?) и не были сохранены.

Хотелось бы понять более четко, действительно ли делается какая-либо отбраковка данных при сохранении, и по каким принципам?


Спасибо: Геннадий Ванин (Gennady Vanin)

Mikhail Sukhov

Фотография
Дата: 15.11.2012
Ответить


DrChemist Перейти

Хотелось бы понять более четко, действительно ли делается какая-либо отбраковка данных при сохранении, и по каким принципам?


В примере нет самого важного параметра - номера сделки.
Спасибо:

DrChemist

Фотография
Дата: 16.11.2012
Ответить


Mikhail Sukhov Перейти

В примере нет самого важного параметра - номера сделки.


Что-то я недооценил этот параметр. Его нет потому, что его нет[bored] Т.е. он всегда ноль.
Искусственные сделки я создаю вот таким кодом, который находится в подкрученном HydraQuikTrader.cs:
(QuikStockIndexes - моя собственная структура, используемая в кастом таблице, откуда я буру данные)

Код

                List<Trade> toTrades = new List<Trade>();
                foreach (QuikStockIndexes si in _idxData)
                {
                    var mySecurLst = _secur.Where(s => (s.Id == (si.SecurID + "@" + si.ClassID)));
                    if (mySecurLst.Any())
                    {
                        var mySecur = mySecurLst.First();
                        var myTrade = new Trade
                        {
                            Security = mySecur,
                            Price = si.Price, //decimal.Round(si.Price, 4),
                            Volume = 1,
                            Time = si.UpdateTime,
                            Latency = si.Latency,
                            OrderDirection = OrderDirections.Buy
                        };
                        toTrades.Add(myTrade);
                    }
                }

                smTestLog( toTrades);

                if (toTrades.Any())
                    RaiseNewTrades(toTrades);


Для правильного сохранения нужно обязательно определять еще и Id?
Тогда не подскажете ли как правильно его определять? Можно ли использовать простой счетчик или нужно что-то более сложное?
Спасибо:


Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy