Если названия неудобны, предложите более понятную комбинацию переменных. Слегка переделать мне не сложно. Их там все равно минимум две, так как надо минимальную дистанцию задать.
Возможно я реализовал не то, что вы предлагали. Просто я мог неверно вас понять. В принципе можно сделать, чтобы величина TP не зависела от гэпа и была постоянной, но тогда число таких ордеров при откате вырастет и с каждого вы потеряете спред.
Все вы сделали правильно, kiocera - и код у вас первоклассный.
Можно отметить, что такого уровня, абсолютной отработки гэпов я не встречал нигде - и на этом кусочке кода мы круче всех в мире. :d
И надо добавить, что мы входим в период, когда рынок колотить будет совершенно не по децки - так что максимальная отработка гэпов предельно полезна и абсолютно своевременна.
Что касается того, что именно пользовательских переменных управления отработкой гэпов должно быть две, то есть у меня сомнения.
Собственно, именно на этом я и затормозился, потому что не сходу въехал почему вы считаете, что их должно быть две.
Как по мне, пользователям и одной переменной, например, GapOrderControl вроде достаточно...
Дело в том, что пользователю сложно, а иногда и невозможно корректно задать значение управляющей переменной PriceGapOrderDistance.
Кроме того, что в разных ДЦ для разных пар разные спрэды - так и еще и в течение дня спрэд может очень широко плавать.
И вполне вероятна ситуация, при которой ТП послегэпового ордера нельзя или невыгодно будет ставить туда, куда предписывает пользователь в переменной PriceGapOrderDistance.
Как минимум, возникает некоторая неоднозначность ситуации.
Поэтому, если мне не изменяет память, я предлагал вычислять позицию установки ТП послегэпового ордера (например, бай) как уровень открытия ордера согласно шага сетки плюс текущий спрэд плюс пара пипс сдвига-резерва (чуть более широкий зазор для повторного открытия послегэпового ордера).
(Правда, насчет "плюс спрэд" я полностью не уверен - но вроде надо?...
Или резервной пары пипс достаточно, чтобы повторно открыть послегэповый ордер примерно там, где он и должен быть согласно шага сетки?)
Тогда минимальный гэп, при котором у послегэпового ордера должно выставляться промежуточное ТП, должен быть не менее вычисленного значения PriceGapOrderDistance плюс стоплэвел (т.к. ТП вряд ли можно выставить ближе, чем стоплэвел).
При таком подходе, если PriceGapOrderDistance вычисляется программно, для управления отработкой гэпов вроде бы достаточно одной управляющей переменной:
GapOrderControl=0:
- послегэповый ордер увеличивается пропорционально размеру гэпа и
- ТП всей сетки устанавливается согласно заданного пользователем ТайкПрофит;
GapOrderControl=х - при гэпе от х пипсов:
- послегэповый ордер в любом случае не увеличивается и устанавливается того же размера, как будто гэпа не было;
- если заданные ДЦ спрэд и стоплэвел позволяют, устанавливается промежуточный ТП на вычисляемом минимальном расстоянии от того уровня, на котором ордер бы открылся, если бы не было гэпа. Ранее построенная часть пирамиды не корректируется;
- иначе ТП всей сетки устанавливается согласно заданного пользователем ТайкПрофит.
Предполагаю, что если по умолчанию задать GapOrderControl равным где-то 12-15 пипсам, то пользователи на большинстве пар вряд ли когда либо будут изменять такую настройку.
В общем, kiocera, сам фрагмент обработки гэпов у вас выписан отменно. Это стильная фишка бота!
Но, имхо, можно упростить пользовательский интерфейс, сделать его более интуитивно понятным и мнемоничным, введя переменную GapOrderControl и сделав внутренними существующие.
Это, конечно, не обязательно - но можно.
Взгляните на код - может, это не потребует существенной коррекции и стоит упростить пользователям управление гэпами.
P.S. kiocera, относитесь с улыбкой к тому, что я периодически и без предупреждения ныряю в детали.
Когда-то, страшно вспомнить когда, я закончил институт по специальности "Организация машинной обработки экономической информации".
Ну и потом сколько-то лет писал программы для использования их людьми, абсолютно не разбирающихся в компьютерах - что тогда было тотально.
Всему, чему меня учили, я, конечно, уже забыл.
Но иногда во мне просыпаются инстинкты. :d
Добавлено: 17-06-2012 20:46:19
Сейчас бот на старте ищет последний ордер и проверяет, является ли он гэп-ордером с коротким TP. Если является, то берет TP от предыдущего ордера.
Затем пирамида продолжает строиться уже с новой сеткой.
Размер лота нового колена будет Lots*(Booster^Level), где Level рассчитывается, как округление до ближайшего целого от Log(Max_Lot / Lots) / Log(Booster).
То есть, берется логарифм по основанию Booster.
Тогда объем сделки определяется по объему последней сделки, а не по количеству открытых колен.
Такой способ более адекватен, чем просто подсчет числа открытых в пирамиде ордеров.
На мой взгляд, это действительно адекватный подход.
Да и нет же цели достигать неких теоретических вершин, абсолюта.
Сугубо практический подход к боту.
Есть вроде только 2 причины изменения геометрии сетки и/или нагрузки на депо - по вине рынка/ДЦ и по решению пользователя.
По вине рынка или ДЦ - это гэпы и их последствия бот должен пытаться нейтрализовать или использовать по максимуму.
Насколько могу судить, отработка гэпов в 2.4.003.02 выполнена теоретически исчерпывающе.
Правда, были и минусовые гэпы до -10 пипс - в конце импульса или на новостях, но алгоритма обработки таких гэпов не вижу.
Так что можно будет посмотреть еще отработку нештатных ситуаций ордеров и терминала - и эту подсистему бота считать завершенной.
Глядя формально, вроде надо адекватно отрабатывать 4 варианта изменения настроек пользователем:
1) увеличение шага - раздвигание сетки;
2) уменьшение шага - сужение сетки;
3) увеличение бустера или минлота;
4) уменьшение бустера или минлота.
При этом можно предположить осмысленное поведение пользователя, который меняет заранее подготовленные сэты и выбирает для этого моменты с минимумом ордеров в рынке.
Логически непротиворечивыми выглядят следующие комбинации изменения настроек пользователем:
А) = 1) + 4)
Б) = 2) + 3)
Комбинация А) (увеличение шага и/или уменьшение минлота и/или бустера) возникает, когда пользователь опасается резких движений на рынке и хочет уменьшить нагрузку на депозит.
Нагрузку на депо можно дополнительно уменьшить, установив Order2Booster=false.
При этом возникает некоторая вероятность, что уже открытые к этому моменту пирамиды позднее закроются в не критичный минус.
Однако уменьшать доходность пользователь без веских на то причин не стал бы - тем более что при этом есть некоторый риск убытка по уже открытым пирамидам.
Пользователь видит более серьезные риски и принимает меры к их демпфированию, если готов пойти на какой-то минус по уже открытым пирамидам.
Поэтому я не вижу ни причин, ни алгоритма попытки сохранения большей доходности открытых пирамид, если пользователь решил уменьшить нагрузку на график и депо.
Имхо, риск некоторого минуса по уже открытым пирамидам в комбинации А) можно оставить без программной отработки.
Комбинация Б) (уменьшение шага и/или увеличение минлота и/или бустера) соответствуют решению пользователя перейти к торговле на более спокойном рынке и/или с большей доходностью.
Единственный просматривающийся при этом незначительный риск - получение несущественного минуса по одной из открытых пирамид за счет меньшего ТП.
Однако больше шансов, что задаваемые пользователем более агрессивные настройки принесут больший плюс на уже открытых пирамидах.
Имхо, комбинация действий пользователя Б) несет скорее позитивные вероятности и не требует дополнительного программного сопровождения.
В итоге, глядя формально, выглядит так, что изменение пользователем параметров пирамиды по ходу торгов не требует дополнительной программной отработки сверх имеющейся.
С учетом же отработки гэпов и уже реализованного пользовательского сервиса, имхо, разработку основной вертушки бота можно считать минимально завершенной. =d> <:-p :d>Собственно, 2.4.003.02 сейчас уже заметно лучше оригинального коммерческого бота.
Возможные 3 опции дополнительного пользовательского сервиса постараюсь выписать сегодня - но они не обязательны, хотя могут быть весьма полезны в условиях реальных торгов.
Да и потом эти фрагменты можно будет использовать программно в других будущих частях бота.