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

Новый комментарий
 
Nikolai Semko:

решил проверить бредовую версию по быстродействию.
И результат удивил. 
Сравнение даже предварительно нормализованных double происходит в среднем даже более медленее, чем если double сравнивать через эпсилон или через преобразование в int

Результат:

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

Удивительно, функция округления до целого возвращает не целое, а действительное число, надо ещё и тип к целому приводить. Где логика языка?
 
Nikolai Semko:

Неужели производительность операции сравнения двух double зависит от значений самых переменных. Сомневаюсь.

Похоже что да. Весьма странно.
Если заменить строчку в примере выше

double test = 1.11;

на 

double test = NormalizeDouble(1.11,2);

то простое сравнение двух double начинает работать быстрее других вариантов. Хотя что там double, что там double. Казалось бы какая разница? А итоговая производительность выше в два раза. Чудеса какие-то.

2020.08.10 17:40:13.583 TestCompareDouble (USDCAD,H4)   простое сравнение предварительно нормализированых double 1 - 552 микросекунд, всего совпадений = 507
2020.08.10 17:40:13.583 TestCompareDouble (USDCAD,H4)   простое сравнение предварительно нормализированых double 2 - 954 микросекунд, всего совпадений = 507
2020.08.10 17:40:13.583 TestCompareDouble (USDCAD,H4)   сравнение double через эпсилон                             - 778 микросекунд, всего совпадений = 507
2020.08.10 17:40:13.583 TestCompareDouble (USDCAD,H4)   сравнение double через преобразование в int                - 854 микросекунд, всего совпадений = 507
Файлы:
TestCompareDouble.mq5  5 kb
 
Alexey Navoykov:

Тест некорректный.  Почему вы делите на 100000.0 только один раз в конце?  Оно должно выполняться на каждой итерации, и потом суммироваться.  Вот тогда это будет честное сравнение.  А так у вас никакая не нормализация, а вы просто оптимизировали свой тестовый алгоритм. Естественно так будет и быстрее, и точнее (т.к. уменьшается накопленная ошибка)

да, Вы правы. Точность будет такая же, как у NormalizeDouble, если делить на каждой итерации. Но скорость все равно будет выше, чем с NormalizeDouble. 

2020.08.10 21:38:48.652 TestCompareDouble (USDCAD,H4)   простая сумма                            - 1394 микросекунд, сумма = -3604329.1567609389312565
2020.08.10 21:38:48.652 TestCompareDouble (USDCAD,H4)   сумма с NormalizeDouble                  - 5861 микросекунд, сумма = -3604329.1543100476264954
2020.08.10 21:38:48.652 TestCompareDouble (USDCAD,H4)   сумма, нормализированная через int       - 2179 микросекунд, сумма = -3604329.1543100476264954

Спасибо.

 

Вообще конечно после округления до целого возврат не целого числа это не гуд. Ранее в принтах встречал после раунд почти целые числа с нулями после запятой и единицей в конце или с девятками после запятой. Думал баг. Оказывается непонятная позиция разрабов. По хорошему при округлении до целого, после запятой в двоичном виде нужно убрать остаток, но видимо обнулить мантиссу сложно / невозможно. Про нормализацию еще более сложно, даже если перенести запятую на 5 знаков и привести к целому в двоичном виде то обратное приведение к дабл даст разность с целым типом.

Грусть, приходиться костылить при вроде простых операциях сравнения.

Не питон.))))

 
Valeriy Yastremskiy:

Вообще конечно после округления до целого возврат не целого числа это не гуд. Ранее в принтах встречал после раунд почти целые числа с нулями после запятой и единицей в конце или с девятками после запятой. Думал баг. Оказывается непонятная позиция разрабов. По хорошему при округлении до целого, после запятой в двоичном виде нужно убрать остаток, но видимо обнулить мантиссу сложно / невозможно. Про нормализацию еще более сложно, даже если перенести запятую на 5 знаков и привести к целому в двоичном виде то обратное приведение к дабл даст разность с целым типом.

Грусть, приходиться костылить при вроде простых операциях сравнения.

В выражениях после округления могут присутствовать ещё какие-то операции с полученным результатом, и совсем необязательно целочисленные. Тогда придётся из int преобразовывать обратно в double, создавая оверхед на ровном месте.  Зачем оно надо?

Никто не мешает создать свои функции RoundInt или RoundLong, которые будут возвращать требуемый тип.

 

Есть проблема в тестере в маркете.

Если проверяется мультивалютный советник то тестер зависает.

Причина: Советник в процессе анализа финансового инструмента натыкается на инструменты в которых нет истории или инструмент не правильно оформлен.

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

Тестер в маркете пишет слишком долгое тестирование.

Предполагаю что советник натыкается на несколько таких битых финансовых инструментов.

Об этой проблеме писалось несколько раз и год назад, а воз и ныне там....

 
Vladimir Pastushak:

Об этой проблеме писалось несколько раз и год назад, а воз и ныне там....

У меня не воспроизводится. Приложите свой исходник.

 

Можно прокомментировать почему функция не работает? Не переключается на 0 график. 

ChartSetInteger(0,CHART_BRING_TO_TOP,0,true);

второе и дальнейшее применение шаблона дублирует окна 

ChartApplyTemplate(0,"Template.tpl");

До обновления эти функции работали.

 
fxsaber:

У меня не воспроизводится. Приложите свой исходник.

Тестировать на серверах Демо Метаквотс

void OnStart()
  {
   int m_all_symbols = SymbolsTotal(false);
   string m_sym_name = "";
   for(int i = 0; i < m_all_symbols; i++)
     {
      // ======================================================================
      // === Получили имя символа
      if((m_sym_name = SymbolName(i, false)) != NULL)
        {
         // ======================================================================
         // === Если символ не выбран в окне маркет ватч
         if(!SymbolInfoInteger(m_sym_name, SYMBOL_SELECT))
            if(!SymbolSelect(m_sym_name, true))
               Print(" SymbolSelect " + m_sym_name);
         ulong get = GetMicrosecondCount();
         MqlRates rateM1[1440];
         if(CopyRates(m_sym_name, PERIOD_M1, 0, 1440, rateM1) > 0)
           {
            Print(m_sym_name, "  ", (GetMicrosecondCount() - get));
           }
         else
            Print("Error  ",m_sym_name, "  ", (GetMicrosecondCount() - get));
        }
     }
  }


2020.08.11 20:20:55.657 test (EURUSD,M15) MXNJPY  1998

2020.08.11 20:20:55.659 test (EURUSD,M15) NZDMXN  1979

2020.08.11 20:20:55.661 test (EURUSD,M15) USDCOP  1973

2020.08.11 20:20:55.663 test (EURUSD,M15) USDARS  2093

2020.08.11 20:20:55.665 test (EURUSD,M15) USDCLP  1929

2020.08.11 20:21:25.259 test (EURUSD,M15) Error  AUS200  29593673

2020.08.11 20:21:54.837 test (EURUSD,M15) Error  FCHI40  29578404

2020.08.11 20:22:24.336 test (EURUSD,M15) Error  GDAXIm  29498485

2020.08.11 20:22:53.949 test (EURUSD,M15) Error  HSI50  29612968

2020.08.11 20:23:23.458 test (EURUSD,M15) Error  Jap225  29509059

2020.08.11 20:23:52.919 test (EURUSD,M15) Error  ND100m  29461316

2020.08.11 20:24:22.425 test (EURUSD,M15) Error  SP500m  29505571

2020.08.11 20:24:51.860 test (EURUSD,M15) Error  SPN35  29435460

2020.08.11 20:25:21.273 test (EURUSD,M15) Error  STOX50  29412578

2020.08.11 20:25:50.663 test (EURUSD,M15) Error  UK100  29389644

2020.08.11 20:26:20.205 test (EURUSD,M15) Error  Brent  29542597

2020.08.11 20:26:49.667 test (EURUSD,M15) Error  Crude  29462066

2020.08.11 20:27:19.194 test (EURUSD,M15) Error  NatGas  29526780




 
Vladimir Pastushak:

Тестировать на серверах Демо Метаквотс

Пардон, сейчас зависает наглухо....

Этот скрипт не вызвал на моей машине зависания Терминала.

1...281628172818281928202821282228232824282528262827282828292830...3519
Новый комментарий
Причина обращения: