Помогите вникнуть в ошибку 131 - страница 2

Новый комментарий
 
Dmitriy Susloparov:

А разве я говорил о нормализации?

Идем к началу ветки: есть три причины ошибки 131: меньше минимума, больше максимума, нет кратности шагу.

Четвертой причины видимо, нет. Минимум - максимум проверить просто? Ну вроде бы, да.

А кратность что ли трудно проверить? Или Вы думаете, я пишу "кратность", а сам вместо этого делаю нормализацию?

Признаться, я не делаю как в "тут", а делаю вот так:

if (fmod(Lots, Step) == 0) { -- блок кода, выставляющий ордер --   }

Это я как-то неправильно проверяю кратность что ли?

Ну, тады ой.
 

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

double lotstep = MarketInfo(Symbol(),MODE_LOTSTEP);  
lotsize = NormalizeDouble((MathRound(lotsize/lotstep))*lotstep,2);
 
Dmitriy Susloparov:

И еще я думал, что если тестирование происходит без подключения к торговому счету,

то Marketinfo() все равно работает, просто возвращает дефаулты.

Встречал, что Marketinfo() возвращает нуль, если, как я догадываюсь, ДЦ поленился заколотить туда конкретные данные. Но давно, какой параметр запрашивал, не помню. Сейчас прямо проверил, запустил сбор данных, получил вот такую таблицу, где часть сведений действительно задана нулевыми значениями. Может, при тестировании еще какая-нибудь часть обнуляется, не знаю.

 
Aleksey Semenov:
lotsize = NormalizeDouble((MathRound(lotsize/lotstep))*lotstep,2);

Да и тут, кстати, подводный камушек есть: почему это там жестко забита цифра 2?

Кто обещал, что нормализацию ВСЕГДА надо делать до 2-х знаков?

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

Я это делаю ДО проверки на кратность.

 
Vladimir:

Встречал, что Marketinfo() возвращает нуль, если, как я догадываюсь, ДЦ поленился заколотить туда конкретные данные. Но давно, какой параметр запрашивал, не помню. Сейчас прямо проверил, запустил сбор данных, получил вот такую таблицу, где часть сведений действительно задана нулевыми значениями. Может, при тестировании еще какая-нибудь часть обнуляется, не знаю.


Вот то то ж оно.

На других форумах проскакивало такое, что типа, вообще, если тестируете без подключения к счету,

не верьте Marketinfo(), она глюкавая и может выдавать всякую ересь.

Если даже не доверять таким постам, все равно получается, что если хоть немного сервер поработал

на счете с кривой спецификацией символа, то в последствии, при тестировании без подключения к

счету, дефаулты так и остаются кривыми навсегда.

В результате, разработчик обязан перед проверками, перечисленными в "тут", каким-то образом

проверять на достоверность еще и саму спецификацию символа.

 
Dmitriy Susloparov:

Да и тут, кстати, подводный камушек есть: почему это там жестко забита цифра 2?

Кто обещал, что нормализацию ВСЕГДА надо делать до 2-х знаков?

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

Я это делаю ДО проверки на кратность.

да это общепринятый костыль для упрощения, уверен если бы это было критически важно то количество знаков после запятой для лота возвращала бы отдельная специальная функция, и когда нормализация явно задана до 2 знаков то на душе как-то спокойнее, не могу сейчас проверить что было бы например с шагом 0.1, но уверен что всё было бы впорядке
 
Aleksey Semenov:
да это общепринятый костыль для упрощения, уверен если бы это было критически важно то количество знаков после запятой для лота возвращала бы отдельная специальная функция, и когда нормализация явно задана до 2 знаков то на душе как-то спокойнее, не могу сейчас проверить что было бы например с шагом 0.1, но уверен что всё было бы впорядке

На самом деле, если соблюсти кратность, то размер лота и так окажется нормализованным.

А поскольку сейчас сплош и рядом минимальный лот и шаг 0.01, получить ошибку 131 у себя дома надо постараться.

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

 

Вот такую тему читал на одном из форумов:

Помогите разобраться с этим советником, советник простой но меня интересует почему он не хочет умножать лоты доливочных ордеров на дробную переменную, например 1.4, только целые, 2 или 3. Спасибо.


Во вложении советник, и вот кусок кода

   // Перед этим в цикле перебор ордеров, увеличение переменной b и присвоение BuyMinLot значения OtderLots()
   if(b==0)
      LotBuy=Lot;
   else
      LotBuy=BuyMinLot*KLot;

   if(s==0)
      LotSel=Lot;
   else
      LotSel=SelMaxLot*KLot;

   if(b==0 || (b>0 && Ask<NormalizeDouble(BuyMinPrice-Distance*Point(),Digits())))
     {
      if(OrderSend(Symbol(),OP_BUY,LotBuy,Ask,Slippage,0,0,"Comment",MagicNumber,0,clrBlue)<0)
         Print("Error N ",GetLastError());
     }

Лот по умолчанию 0.01 потому и дальнейшее обсуждение было об умножении этого размера лота.  0.01*1.5 = 0.015... в OrderSend лот не нормализуется, соответственно должна быть ошибка.

Но

Проверил, если округлить, то получится 0.01, 0.02, 0.03 и тд., а у этого советник все время 0.01.


выходит что нет ошибки... выходит что просто отбрасывается лишняя часть числа?

 

Кстати, а нигде не проскальзывает отрицательное значение объема? Такое точно приводит к ошибке 131.

 
Alexey Viktorov:

выходит что нет ошибки... выходит что просто отбрасывается лишняя часть числа?

Это такая слабость домашнего тестирования: я без нормализации пытался 0.025 к примеру объем

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

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

жить, если только на продажу советник не выкладывать.

123
Новый комментарий
Причина обращения: