Ошибки, баги, вопросы - страница 3121

[Alexey Viktorov]

x572intraday #:
 Если кто в курсе, подскажите. Если заливаешь в CodeBase новую версию существующего кода, то у предыдущих проголосовавших сбрасывается запрет на повторное голосование и они могут заново проголосовать за новую версию? Сам я в этом сильно сомневаюсь, но если бы была такая возможность, было бы справедливо сбрасывать предыдущую оценку в замен новой (которая гипотетически призвана быть не ниже предыдущей), поскольку код развивается и новая версия может удовлетворить голосовавшего в большей степени, а старая оценка за старый код станет уже недействительной. (Правда, с ростом функционала растёт и код, а потому могут быть и новые ошибки и глюки, ещё более забористые. Может быть всякое... и новая оценка может оказаться ниже, но меня это устраивает.)

Да хватит уже волосы рвать за низкую оценку ваших …кодов. Если человек поставил вашему коду оценку 1, то это не означает, что код такой и есть. Ну переделайте его хоть 100 раз… и все 100 раз этот код будет оценен именно так. Разве это так трудно понять?

[x572intraday]

Alexey Viktorov #:

Да хватит уже волосы рвать за низкую оценку ваших …кодов. Если человек поставил вашему коду оценку 1, то это не означает, что код такой и есть. Ну переделайте его хоть 100 раз… и все 100 раз этот код будет оценен именно так. Разве это так трудно понять?

 Возможно, Ваше резюме и отражает реальное положение дел в сфере голосования и это печалит. Но я печалюсь не о себе — эти виртуальные звёздочки с чаем не выпьешь и в кошелёк на положишь, я разочаровываюсь в концепции способа презентации продуктов для новых пользователей, беспокоясь именно о них. Там, где нет достоверной оценки/рейтинга, пользователи просто не смогут эффективно искать желаемый продукт по критерию "Сортировка по рейтингу". Получается, рейтинговая система — пустышка и остаётся искать нужный продукт по названию/описанию, а не доверяться бестолковому количеству звёзд. А то так и будут вылавливать всякое... то, что плавает на поверхности (заслуженно или не очень), а то, что им действительно нужно, будет недосмотрено. Я просто предложил это изменить в сторону большей продуманности. Но если с такой действительностью никто бороться не собирается, я умываю руки.

[Vitaly Muzichenko]

x572intraday #:

 Возможно, Ваше резюме и отражает реальное положение дел в сфере голосования и это печалит. Но я печалюсь не о себе — эти виртуальные звёздочки с чаем не выпьешь и в кошелёк на положишь, я разочаровываюсь в концепции способа презентации продуктов для новых пользователей, беспокоясь именно о них. Там, где нет достоверной оценки/рейтинга, пользователи просто не смогут эффективно искать желаемый продукт по критерию "Сортировка по рейтингу". Получается, рейтинговая система — пустышка и остаётся искать нужный продукт по названию/описанию, а не доверяться бестолковому количеству звёзд. А то так и будут вылавливать всякое... то, что плавает на поверхности (заслуженно или не очень), а то, что им действительно нужно, будет недосмотрено. Я просто предложил это изменить в сторону большей продуманности. Но если с такой действительностью никто бороться не собирается, я умываю руки.

Ну раз так, давай-те рассмотрим ваш код

   int calculated=iBars(_Symbol,PArray[0]);

   if(calculated<=0)
      return(0);

   if(!GlobalVariableGet(_Symbol+": PSR_bars_calculated") || calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated") ||
      calculated>GlobalVariableGet(_Symbol+": PSR_bars_calculated")+1)
   {
      if(!GlobalVariableGet(_Symbol+": PSR_SingleActuation") || (GlobalVariableGet(_Symbol+": PSR_SingleActuation") &&
         calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated")))
      {
         for(int p=0; p<ArraySize(PArray); p++)
         {

На каждом тике срабатывает доступ к глоб.переменным, за один раз аж 4 запроса

Из этого следует, что на личной машине использовать такой код НЕЛЬЗЯ, можно где-то на чужой, на которой не жалко жёсткого диска.

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

В ДеИните удаление объектов происходит странным образом, тут ничего страшного нет, но плохой пример для начинающих, если сделать нормально, то при создании объектов ввести префикс и по нему удалять без лишних пересчётов.

Я за ваш код ставлю 2 балла. 

За работу индикатора - не знаю, не запускал.

Объективно?

[x572intraday]

Vitaly Muzichenko #:

Ну раз так, давай-те рассмотрим ваш код

На каждом тике срабатывает доступ к глоб.переменным, за один раз аж 4 запроса

Из этого следует, что на личной машине использовать такой код НЕЛЬЗЯ, можно где-то на чужой, на которой не жалко жёсткого диска.

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

В ДеИните удаление объектов происходит странным образом, тут ничего страшного нет, но плохой пример для начинающих, если сделать нормально, то при создании объектов ввести префикс и по нему удалять без лишних пересчётов.

Я за ваш код ставлю 2 балла. 

За работу индикатора - не знаю, не запускал.

Объективно?

 1. На каждом тике есть обращение к ГП именно для того, чтобы на каждом тике, а также при каждой переинициализации (например, переходах по ТФам) не выполнялся весь основной и более тяжёлый код в OnCalculate() и работа индикатора происходила быстрее. Обсчёт новых данных — только с появлением нового младшего бара D1, что намного реже, чем на каждом тике.

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

 3. Про НЕЛЬЗЯ — сильно преувеличено. Можете скачать и убедиться лично: индикатор летает.

 4. Не знал, что ГП скидываются на ЖД, а потом оттуда же читаются каждый раз при обращении к ним в пределах запущенной сессии MT5. Мне до сих пор думается, что с ЖД они однократно считываются в ОЗУ при запуске терминала и живут уже там, а индикатор обращается за ними в ОЗУ, а не к ЖД.

 5. Не считаю, что ArraySize() — дорогая функция. А если и дорогая, то в конкретно данном коде этого заметно не будет. Оптимизацию на этот счёт я бы, возможно, провёл в первом своём индикаторе, где эта функция встречается часто, а сам индикатор гораздо более сложный и ресурсоёмкий.

 6. В OnDeinit() я использую:

ObjectsDeleteAll(0,StringSubstr(EnumToString(PArray[p]),7)+" "+line_types[lt]+" l",0,-1);

где как раз и есть удаление по префиксу " l" (при создании объектов использовались имена " label" и " line".

 7. Вы сейчас сделали то, что должен сделать пользователь, скачавший и разобравшийся в коде. Вы нашли недочёты — это тоже часть обучения MQL.

 8. Итого: 1.) мой главный аргумент дозволенности неидеального кода именно этого индикатора — простота, компактность да и без того скорость... плюс идеальная работа задуманного; 2.) мой второй главный аргумент неидеального кода — отсутствие даже плохих аналогов по части скорости и универсальности (см. обсуждение чужого оригинала) и наличие улучшений по сравнению с оригиналом, который, кстати говоря, узконаправлен и не свёрнут в компактные циклы по части большого числа однотипно повторяющихся блоков.

 9. Несмотря на п. 7., разобрались Вы в чужом коде не особо. Ваша оценка в 2 балла слишком занижена. Я бы пока не рекомендовал Вам оценивать программные продукты по коду. Про объективность ничего не скажу, ибо просто потому, что от какого-либо одного пользователя невозможно ждать объективности в принципе. Объективная оценка (рейтинг) возможна только в виде суммы оценок нескольких вменяемых пользователей и уж никак не обязана быть непременно высокой.

[Vitaly Muzichenko]

x572intraday #:

 1. На каждом тике есть обращение к ГП именно для того, чтобы на каждом тике, а также при каждой переинициализации (например, переходах по ТФам) не выполнялся весь основной и более тяжёлый код в OnCalculate() и работа индикатора происходила быстрее. Обсчёт новых данных — только с появлением нового младшего бара D1, что намного реже, чем на каждом тике.

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

 3. Про НЕЛЬЗЯ — сильно преувеличено. Можете скачать и убедиться лично, что индикатор летает.

 4. Не знал, что ГП скидываются на ЖД, а потом оттуда же читаются каждый раз при обращении к ним в пределах запущенной сессии MT5. Мне до сих пор думается, что с ЖД они однократно считываются в ОЗУ при запуске терминала и живут уже там, а индикатор обращается за ними в ОЗУ, а не к ЖД.

 5. Не считаю, что ArraySize() — дорогая функция. А если и дорогая, то в конкретно данном коде этого заметно не будет. Оптимизацию на этот счёт я бы, возможно, провёл в первом своём индикаторе, где эта функция встречается часто, а сам индикатор гораздо более сложный и ресурсоёмкий.

 6. В OnDeinit() я использую:

где как раз и есть удаление по префиксу " l" (при создании объектов использовались имена " label" и " line".

 7. Вы сейчас сделали то, что должен сделать пользователь, скачавший и разобравшийся в коде. Вы нашли недочёты — это тоже часть обучения MQL.

 8. Итого: 1.) мой главный аргумент дозволенности неидеального кода именно этого индикатора — простота, компактность да и без того скорость... плюс идеальная работа задуманного; 2.) мой второй главный аргумент неидеального кода — отсутствие аналогов по части скорости и универсальности (см. обсуждение чужого оригинала) и наличие улучшений по сравнению с оригиналом, который, кстати говоря, узконаправлен и не свёрнут в компактные циклы по части большого числа однотипно повторяющихся блоков.

 9. Несмотря на п. 7., разобрались Вы в чужом коде не особо. Ваша оценка в 2 балла слишком занижена. Я бы пока не рекомендовал Вам оценивать программные продукты по коду. Про объективность ничего не скажу, ибо просто потому, что от какого-либо одного пользователя невозможно ждать объективности в принципе. Объективная оценка (рейтинг) возможна только в виде суммы оценок нескольких вменяемых пользователей и уж никак не обязана быть непременно высокой.

Удаление по префиксу, это так:  ObjectsDeleteAll(0,"pref_"); //    "pref_label" и " pref_line"

Добавьте хотя if первой строкой в OnCalculate, чтобы обращение было на новом баре, а не на каждом тике, как сейчас

[x572intraday]

Vitaly Muzichenko #:

Удаление по префиксу, это так:  ObjectsDeleteAll(0,"pref_"); //    "pref_label" и " pref_line"

Добавьте хотя if первой строкой в OnCalculate, чтобы обращение было на новом баре, а не на каждом тике, как сейчас

 Кстати сказать, по поводу п. 7.: ошибки я встречал даже в Документации к MQL5, которые не исправляются уже много лет.

[x572intraday]

Vitaly Muzichenko #:

Удаление по префиксу, это так:  ObjectsDeleteAll(0,"pref_"); //    "pref_label" и " pref_line"

 Удалять так, как предлагаете, нет разумной возможности, так как начало префикса динамическое: либо {D1}, либо  {W1}, либо {MN1}, а уж потом идёт неизменяемый префикс в виде " l...". Можно поменять местами динамический и статический префиксы и спокойно удалять по Вашему варианту, но это неразумно, поскольку неудобно воспринимать информацию как "R1   {D1}", а удобнее "{D1}   R1". Всё это я давно продумал и сделал именно как сделал.

[Vitaly Muzichenko]

x572intraday #:

 Удалять так, как предлагаете, нет разумной возможности, так как начало префикса динамическое: либо {D1}, либо  {W1}, либо {MN1}, а уж потом идёт неизменяемый префикс в виде " l...". Можно поменять местами динамический и статический префиксы и спокойно удалять по Вашему варианту, но это неразумно, поскольку неудобно воспринимать информацию как "R1   {D1}", а удобнее "{D1}   R1". Всё это я давно продумал и сделал именно как сделал.

DrawTheLine("pref"+line_types[lt], St

[x572intraday]

Vitaly Muzichenko #:

 Всё-таки да, в принципе, можно и так. Выше я лихо объяснялся, думая в это время об:

ObjectSetString(0,tf+" "+LineType+" label",OBJPROP_TEXT,"{"+tf+"}   "+LineType);

а не об имени объектов. На графике читают ведь именно то, что задано с помощью OBJPROP_TEXT для лейблов, а вот имена объектов можно подписывать менее удобочитаемо, ибо они скрыты и их редко кто читает.

 С другой стороны, в "Списке объектов" (Ctrl+b) желательно видеть и удобочитаемые имена объектов, так что всё же предпочтительнее мой вариант. Плюс ко всему, бывают случаи, когда имена объектов вынуждены быть предельно длинными, так что лишние "pref_" будут совершенно недопустимыми.

[Vitaly Muzichenko]

x572intraday #:

 Всё-таки да, в принципе, можно и так. Выше я лихо объяснялся, думая в это время об:

а не об имени объектов. На графике читают ведь именно то, что задано с помощью OBJPROP_TEXT для лейблов, а вот имена объектов можно подписывать менее удобочитаемо, ибо они скрыты и их редко кто читает.

 С другой стороны, в "Списке объектов" (Ctrl+b) желательно видеть и удобочитаемые имена объектов, так что всё же предпочтительнее мой вариант. Плюс ко всему, бывают случаи, когда имена объектов вынуждены быть предельно длинными, так что лишние "pref_" будут совершенно недопустимыми.

а если у кого-то на графике ещё будет стоять программа с графическими объектами, то ваш типа префикс "l" < где как раз и есть удаление по префиксу " l" (при создании объектов использовались имена " label" и " line" >

Убьёт все объекты начинающиеся на "l" в сторонней программе. Это не совсем хорошее решение