Ну так на сервере MetaQuotes-Demo (где тестит модератор) мин. стоп левел нормально возвращается. Проверьте сами, 0 - не будет.
Я не знаю на каком сервере тестит модератор но у топик стартера стояла проверка на стоп левел и ему продукт вернули на доработку из за ошибки 130. Почитайте ветку с самого начала.
Vitalii Ananev: Я не знаю на каком сервере тестит модератор но у топик стартера стояла проверка на стоп левел и ему продукт вернули на доработку из за ошибки 130. Почитайте ветку с самого начала.
В его случае 130тая может возникать не только тогда, когда сов пытается поставить стоп-лос сильно близко к рынку.
Проверку лучше делать непосредственно при отправке или модификации сл-тп.
Вопрос, а зачем ставить на реале стоп-лосс в 1 пункт?
Только что вспомнил... Когда-то тестировал такой алгоритм с мин. стоп-лосом, проверка в принципе такая-же и никаких ошибок не было как и профита.
Продавец 60 продуктов маркета -- написавший в местном фрилансе 80 задач -- имеющий сайт с рекламой по написанию советников -- и всё это далеко не первый год -- это топикстартер.
И вдруг топикстартер спрашивает, что делать с нулевым стоплевелем и говорит, что модераторы маркета как-то странно проверяют советники маркета.
В противовес его комментариям -- форумчане, имеющие опыт разработок, имеющие опыт выставления продуктов в маркет -- читают его комментарии и недоумевают.
Как по мне -- топикстартер в откровенном неадеквате и тупо высосал из пальца проблему.
Продавец 60 продуктов маркета -- написавший в местном фрилансе 80 задач -- имеющий сайт с рекламой по написанию советников -- и всё это далеко не первый год -- это топикстартер.
И вдруг топикстартер спрашивает, что делать с нулевым стоплевелем и говорит, что модераторы маркета как-то странно проверяют советники маркета.
В противовес его комментариям -- форумчане, имеющие опыт разработок, имеющие опыт выставления продуктов в маркет -- читают его комментарии и недоумевают.
Как по мне -- топикстартер в откровенном неадеквате и тупо высосал из пальца проблему.
может просто общения захотелось? ) программирование ботов очень одинокое занятие
double point=SymbolInfoDouble(symToWorkmodify,SYMBOL_POINT);
int spread=(ask-bid)/point;
Так делить на point нельзя, значение функции SymbolInfoDouble(symToWorkmodify,SYMBOL_POINT)может быть равным нулю. Это касается и других маркет-функций.
К примеру, из-за использования в расчетах AccountInfoInteger(ACCOUNT_LEVERAGE) на чемпионате 2010 года вылетела часть советников с ошибкой Zero divide, когда в OnInit'е эта функция вернула 0.
Вопрос, а зачем ставить на реале стоп-лосс в 1 пункт?
Только что вспомнил... Когда-то тестировал такой алгоритм с мин. стоп-лосом, проверка в принципе такая-же и никаких ошибок не было как и профита.
Зрите в корень. Речь не о том, зачем ставить стоплосс 1 пункт. Речь о том, что стоплосс может оказаться меньше того стоплевела, который скрыт брокером и вычисляется по ширине спреда.
Чтобы пояснить суть проблемы, привожу эксперт, проверка стопов в котором сделана по Вашему алгоритму:
#property strict//--- input parametersinputint i_slSize = 10;
inputint i_tpSize = 10;
inputint i_magicNumber = 32847623;
intOnInit()
{
Print("Величина стоплевел: ", MarketInfo(_Symbol,MODE_STOPLEVEL));
return(INIT_SUCCEEDED);
}
int GetExpertOrderTicket()
{
for (int i = OrdersTotal() - 1; i >= 0; i--)
{
if (!OrderSelect(i, SELECT_BY_POS))
continue;
if (OrderSymbol() != Symbol())
continue;
if (OrderMagicNumber() != i_magicNumber)
continue;
if (OrderType() == OP_BUY)
returnOrderTicket();
}
return -1;
}
voidOnTick()
{
int ticket = GetExpertOrderTicket();
if (ticket < 0)
{
ticket = OrderSend(Symbol(), OP_BUY, 0.01, Ask, 30, 0.0, 0.0, NULL, i_magicNumber);
return;
}
if (!OrderSelect(ticket, SELECT_BY_TICKET) || OrderCloseTime() != 0 || OrderStopLoss() > 0.0 || OrderTakeProfit() > 0.0)
return;
double SL=NormalizeDouble(OrderOpenPrice()-MathMax(i_slSize,(int)MarketInfo(_Symbol,MODE_STOPLEVEL))*_Point,_Digits);
double TP=NormalizeDouble(OrderOpenPrice()+MathMax(i_tpSize,(int)MarketInfo(_Symbol,MODE_STOPLEVEL))*_Point,_Digits);
bool result = OrderModify(ticket, 0.0, SL, TP, 0);
}
Зрите в корень. Речь не о том, зачем ставить стоплосс 1 пункт. Речь о том, что ...
Если зрить в корень -- то надо различать: а) "защиту от дурака покупателя разработчика" и б) расчёт на то, что покупатель идиот. Это разные защиты.
Никакой вменяемый покупатель не будет ставить тейк и стоп отрицательный. Поэтому проверка "как среагирует советник на отрицательный стоп и тейк" -- это расчёт на то, что покупатель идиот.
Создание советника в котором заданный пользователем тейк и стоп принудительно увеличивается постоянно на непонятную величину "2 спреда" -- это "защита от дурака", только защита непокупкой продукта от "дурака разработчика".
Особенно, если разработчик ставит такую защиту, чтобы пройти модерацию маркета.
Если зрить в корень -- то надо различать: а) "защиту от дурака покупателя разработчика" и б) расчёт на то, что покупатель идиот. Это разные защиты.
Никакой вменяемый покупатель не будет ставить тейк и стоп отрицательный. Поэтому проверка "как среагирует советник на отрицательный стоп и тейк" -- это расчёт на то, что покупатель идиот.
Создание советника в котором заданный пользователем тейк и стоп принудительно увеличивается постоянно на непонятную величину "2 спреда" -- это "защита от дурака", только защита непокупкой продукта от "дурака разработчика".
А в думаете тут много вменяемых? :) Особенно среди покупателей
Зрите в корень. Речь не о том, зачем ставить стоплосс 1 пункт. Речь о том, что стоплосс может оказаться меньше того стоплевела, который скрыт брокером и вычисляется по ширине спреда.
Чтобы пояснить суть проблемы, привожу эксперт, проверка стопов в котором сделана по Вашему алгоритму:
Ну так на сервере MetaQuotes-Demo (где тестит модератор) мин. стоп левел нормально возвращается. Проверьте сами, 0 - не будет.
Я не знаю на каком сервере тестит модератор но у топик стартера стояла проверка на стоп левел и ему продукт вернули на доработку из за ошибки 130. Почитайте ветку с самого начала.
В его случае 130тая может возникать не только тогда, когда сов пытается поставить стоп-лос сильно близко к рынку.
Проверку лучше делать непосредственно при отправке или модификации сл-тп.
Вопрос, а зачем ставить на реале стоп-лосс в 1 пункт?
Только что вспомнил... Когда-то тестировал такой алгоритм с мин. стоп-лосом, проверка в принципе такая-же и никаких ошибок не было как и профита.
Продавец 60 продуктов маркета -- написавший в местном фрилансе 80 задач -- имеющий сайт с рекламой по написанию советников -- и всё это далеко не первый год -- это топикстартер.
И вдруг топикстартер спрашивает, что делать с нулевым стоплевелем и говорит, что модераторы маркета как-то странно проверяют советники маркета.
В противовес его комментариям -- форумчане, имеющие опыт разработок, имеющие опыт выставления продуктов в маркет -- читают его комментарии и недоумевают.
Как по мне -- топикстартер в откровенном неадеквате и тупо высосал из пальца проблему.
Продавец 60 продуктов маркета -- написавший в местном фрилансе 80 задач -- имеющий сайт с рекламой по написанию советников -- и всё это далеко не первый год -- это топикстартер.
И вдруг топикстартер спрашивает, что делать с нулевым стоплевелем и говорит, что модераторы маркета как-то странно проверяют советники маркета.
В противовес его комментариям -- форумчане, имеющие опыт разработок, имеющие опыт выставления продуктов в маркет -- читают его комментарии и недоумевают.
Как по мне -- топикстартер в откровенном неадеквате и тупо высосал из пальца проблему.
тут размещенный код:
Так делить на point нельзя, значение функции SymbolInfoDouble(symToWorkmodify,SYMBOL_POINT) может быть равным нулю.
Это касается и других маркет-функций.
К примеру, из-за использования в расчетах AccountInfoInteger(ACCOUNT_LEVERAGE) на чемпионате 2010 года вылетела часть советников с ошибкой Zero divide, когда в OnInit'е эта функция вернула 0.
Вопрос, а зачем ставить на реале стоп-лосс в 1 пункт?
Только что вспомнил... Когда-то тестировал такой алгоритм с мин. стоп-лосом, проверка в принципе такая-же и никаких ошибок не было как и профита.
Зрите в корень. Речь не о том, зачем ставить стоплосс 1 пункт. Речь о том, что стоплосс может оказаться меньше того стоплевела, который скрыт брокером и вычисляется по ширине спреда.
Чтобы пояснить суть проблемы, привожу эксперт, проверка стопов в котором сделана по Вашему алгоритму:
Результат тестирования такого эксперта:
Как видно, способ не проходит элементарную проверку.
Зрите в корень. Речь не о том, зачем ставить стоплосс 1 пункт. Речь о том, что ...
Если зрить в корень -- то надо различать: а) "защиту от дурака покупателя разработчика" и б) расчёт на то, что покупатель идиот. Это разные защиты.
Никакой вменяемый покупатель не будет ставить тейк и стоп отрицательный. Поэтому проверка "как среагирует советник на отрицательный стоп и тейк" -- это расчёт на то, что покупатель идиот.
Создание советника в котором заданный пользователем тейк и стоп принудительно увеличивается постоянно на непонятную величину "2 спреда" -- это "защита от дурака", только защита непокупкой продукта от "дурака разработчика".
Особенно, если разработчик ставит такую защиту, чтобы пройти модерацию маркета.
Если зрить в корень -- то надо различать: а) "защиту от дурака покупателя разработчика" и б) расчёт на то, что покупатель идиот. Это разные защиты.
Никакой вменяемый покупатель не будет ставить тейк и стоп отрицательный. Поэтому проверка "как среагирует советник на отрицательный стоп и тейк" -- это расчёт на то, что покупатель идиот.
Создание советника в котором заданный пользователем тейк и стоп принудительно увеличивается постоянно на непонятную величину "2 спреда" -- это "защита от дурака", только защита непокупкой продукта от "дурака разработчика".
Зрите в корень. Речь не о том, зачем ставить стоплосс 1 пункт. Речь о том, что стоплосс может оказаться меньше того стоплевела, который скрыт брокером и вычисляется по ширине спреда.
Чтобы пояснить суть проблемы, привожу эксперт, проверка стопов в котором сделана по Вашему алгоритму:
Результат тестирования такого эксперта:
Как видно, способ не проходит элементарную проверку.
Если все так плохо то вот
журнал
и никаких проблем.
ну а если вообще все плохо, как правильно подметил Andrey F. Zelinsky
Ухудшать функционал советника только для того, чтобы пойти модерацию маркета -- это однозначная не адекватность.
А в думаете тут много вменяемых? :) Особенно среди покупателей
Думаю, что если провести исследование -- то окажется, что вменяемых покупателей на порядок больше, чем вменяемых разработчиков.
Покупатель может ошибаться. Покупателю можно пояснить. Покупателя можно убедить.
А вот, если у разработчика проблемы со здравым смыслом -- это не исправляется.
Ухудшать функционал советника только для того, чтобы пойти модерацию маркета -- это однозначная не адекватность.