Invalid Stops на лимитах и пропущенные стопы и тейки.

Новый комментарий
 
Время от времени нормализация приводит к тому, что эпсилон оказывается не с той стороны.

2006.11.03 00:17:11 test EURUSDm,M5: OrderSend(EURUSDm, 2, 0.98, 1.2775, 1, 1.274, 1.2878) error 130: invalid stops
2006.11.03 00:17:11 test EURUSDm,M5: bid/ask 1.2778000000000001/1. 2780000000000000, open/stop/take 1.2775000000000001/1.2740000000000000/1.2878000000000001

В логе BUY_LIMIT не прошел потому, что цена лимита отличается от Ask на 4.9999999999999999, а не ровно на 5.0000000000000000. Это торговля на демо.

Точно также иногда пропускаются стоплоссы/тейкпрофиты, если установленное значение отличается от рынка на эпсилон, т.е., например, стоплосс оказывается меньше Low на 0.0000000000000001 на длинной позиции. С этим сталкивался при тестировании.

Может, все-таки, в торговой арифметике учитывать эпсилон при сравнении даблов? Или, вообще, в целочисленных пойнтах все считать?
 
Сравнивайте текущее с значение с новым значением на величину Пойтна
 
<Или, вообще, в целочисленных пойнтах все считать?>
Именно так и делаю, и всем советую. Только при операции с ордером на сервер отсылается число с плавающей точкой, нормализованное на число разрядов по данному символу. Это не гарантирует от возникновения ситуации, описанной здесь: '2006.11.01 18:48:30 '5636': order #669040 sell 0.10 USDJPY closing at 117.0100 failed [Modification denied. Order too close to market]' , однако хотя бы со своей стороны можно быть спокойным.
 
Rosh:
Сравнивайте текущее с значение с новым значением на величину Пойтна
Rosh, не понял ничего.

Какое текущее значение с новым значением чего? И где кто должен сравнивать?
 
alexjou:
<Или, вообще, в целочисленных пойнтах все считать?>
Именно так и делаю, и всем советую. Только при операции с ордером на сервер отсылается число с плавающей точкой, нормализованное на число разрядов по данному символу. Это не гарантирует от возникновения ситуации, описанной здесь: '2006.11.01 18:48:30 '5636': order #669040 sell 0.10 USDJPY closing at 117.0100 failed [Modification denied. Order too close to market]' , однако хотя бы со своей стороны можно быть спокойным.
И я так делаю. Проблема в том, что OrderSend и тестер - нет. И это не гарантирует от ситуации, описанной здесь.
 
Irtron:
Rosh:
Сравнивайте текущее с значение с новым значением на величину Пойтна
Rosh, не понял ничего.

Какое текущее значение с новым значением чего? И где кто должен сравнивать?
Тогда я тоже не понял, вот эта фраза что означает?


Точно также иногда пропускаются стоплоссы/тейкпрофиты, если установленное значение отличается от рынка на эпсилон, т.е., например, стоплосс оказывается меньше Low на 0.0000000000000001 на длинной позиции. С этим сталкивался при тестировании.

 

Никогда с таким не сталкивался ни в тестере, ни на демо. Насколько я понимаю, назначение параметра Slippage != 0 как раз и должно избавить от таких ситуаций. Т.е. на сервере операции с ордерами производятся с плавающей точкой или в целочисленной арифметике?

 
Rosh:
Тогда я тоже не понял, вот эта фраза что означает?


Точно также иногда пропускаются стоплоссы/тейкпрофиты, если установленное значение отличается от рынка на эпсилон, т.е., например, стоплосс оказывается меньше Low на 0.0000000000000001 на длинной позиции. С этим сталкивался при тестировании.


Тестер производит сравнение даблов без нормализации. То есть, если идет тестирование по ценам открытия и на каком то баре оказывается, что предыдущий Low дотронулся до стоплосса на длинной позиции, он иногда может не сработать из-за того, что эпсилон (ошибка дискретизации) не учитывается при сравнении:
OrderStopLoss 1.2740000000000000
Low[1] 1.2740000000000001

Та же проблема при сравнении разницы рынка с лимитом. Если от рынка отнять 5 и попытаться открыть buy limit, терминал, прибавляя 5, иногда получает значение, меньшее рыночного на эпсилон, и отказывает в размещении ордера, как в логе.

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

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

0-й слипаж пофиксен, все остальное ждет своего разрешения.
Новый комментарий
Причина обращения: