Ошибка компилятора. В приведённом коде он не может определиться между даун-кастом (который всегда разрешён неявно), и ап-кастом (который вообще недопустим в других языках в неявном виде). Если уж в MQL по какой-то причине разрешают неявный ап-каст (что само по себе ошибка), то он хотя бы должен иметь приоритет ниже, чем у даун-каста.
class A { };
class B : public A { };
class C : public B { };
void f(A*) { };
void f(C*) { }
voidOnInit()
{
B* b;
f(b); // 'f' - ambiguous call to overloaded function
}
Имеем маленькую сеть агентов, часть в локальной сети, часть удаленно находятся, все объединены с помощью Hamachi в одну сеть.
Откомпилированный файл занимает примерно 11 мегабайт, исходник 20.
Интернет не очень быстрый скорость на отдачу/прием - 766/6137 kbps.
Агенты не продаются через CLOUD, единовременно используются только мной.
При оптимизации очень часта ситуация, когда агенты на удаленной сети не могут начать работу, вот лог относительно одного из агентов с такой проблемой:
LD 002:40:54.613 SVA_03 connecting to ***.***.***.***:2000
OO 002:40:54.613 SVA_03 connecting to ***.***.***.***:2001
FG 002:40:54.613 SVA_03 connecting to ***.***.***.***:2002
QS 002:40:54.643 SVA_03 connected
RN 002:40:54.708 SVA_03 authorized (agent build 1950)
FR 002:40:58.576 SVA_03 connected
GE 002:40:58.579 SVA_03 connected
FD 002:41:00.560 SVA_03 authorized (agent build 1950)
DO 002:41:00.562 SVA_03 authorized (agent build 1950)
DE 002:50:56.093 SVA_03 connection closed
QN 002:50:56.125 SVA_03 connecting to ***.***.***.***:2002
DS 002:50:56.962 SVA_03 connected
PM 202:50:58.635 SVA_03 occupied by another terminal
QN 002:51:01.033 SVA_03 connection closed
KS 002:51:01.033 SVA_03 connection closed
RL 002:51:01.060 SVA_03 connecting to ***.***.***.***:2000
ED 002:51:01.060 SVA_03 connecting to ***.***.***.***:2001
MF 002:51:01.760 SVA_03 connected
DI 002:51:01.763 SVA_03 connected
OK 202:51:03.244 SVA_03 occupied by another terminal
DQ 202:51:03.247 SVA_03 occupied by another terminal
GS 002:51:58.032 SVA_03 connecting to ***.***.***.***:2002
NF 002:51:58.057 SVA_03 connected
KG 002:51:58.112 SVA_03 authorized (agent build 1950)
IE 002:52:03.114 SVA_03 connecting to ***.***.***.***:2000
NL 002:52:03.114 SVA_03 connecting to ***.***.***.***:2001
QJ 002:52:03.622 SVA_03 connected
CM 002:52:03.624 SVA_03 connected
DL 002:52:04.674 SVA_03 authorized (agent build 1950)
PG 002:52:04.678 SVA_03 authorized (agent build 1950)
QQ 003:01:59.032 SVA_03 connection closed
LK 003:01:59.072 SVA_03 connecting to ***.***.***.***:2002
HO 003:02:00.103 SVA_03 connected
FQ 203:02:01.789 SVA_03 occupied by another terminal
Решением является уменьшения числа удаленных агентов и запуск их по одному-двум.
Как я понимаю, что происходит передача данных, которая обрывается из-за повторного запроса терминала на соединение, т.е. терминал не знает, что уже передает данные агенту и нужно просто подождать окончания их передачи.
P.S. Если чего то не хватает, то просьба сразу не банить, а истребовать недостающую информацию, что принято в цивилизованном обществе - регламента то сейчас для баг репортов нет!
Да, текущее значение при увеличении буферов нужно принудительно обнулять, если все условия не исполняются. Я сообщу о результате, когда внесу исправления и проведу тесты.
//---
Результаты оптимизации не совпадают с результатами тестов.
Вопрос по библиотеке Alglib к разработчикам. На их оф. сайте (англоязычном) есть некоторые интересные обновления, например что касается машинного обучения. Её как-то можно обновить будет, хотя бы частями? интересует обновленный случайный лес, например. В нем, похоже, обновлено всего несколько методов\классов.. но разбираться в этом самостоятельно конечно тот еще челлендж
Замените индикатор на что-нибудь из стандартной поставки. Если исчезнут расхождения - проблема в Вашем индикаторе.
Обнаружил, что многие результаты совпадают.
Теперь ищу, при каких параметрах бывают несовпадения и почему.
По крайней мере изменения есть в результатах оптимизации в билде 1973. Нет чрезмерно завышенных показателей фактора восстановления, как было показано ранее на скриншотах.
Использую только Bruteforce-оптимизацию. На моих советниках все совпадает идеально даже тогда, когда используется предсказание, какой будет результат Тестера.
Использую только Bruteforce-оптимизацию. На моих советниках все совпадает идеально даже тогда, когда используется предсказание, какой будет результат Тестера.
Провёл сейчас множество оптимизаций с разными временными диапазонами и разными диапазонами параметров эксперта. Полное совпадение.
Перед этим скорее всего старые результаты оптимизации (генетический алгоритм) рассматривал.
Точнее сказать ускорение от 20% до 15 раз при добавлении на разных сценариях. Замена ускорена в 3 раза. Удаление до 36 раз.
Ваш пример с пустыми 10 млн тиками теперь отрабатывается за приемлемое время:
раньше уходил в экстремально долгий процессинг.
Код для теста
Результат
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Баг компилятора: неверный приоритет кастинга
Alexey Navoykov, 2019.01.19 00:38
Ошибка компилятора. В приведённом коде он не может определиться между даун-кастом (который всегда разрешён неявно), и ап-кастом (который вообще недопустим в других языках в неявном виде). Если уж в MQL по какой-то причине разрешают неявный ап-каст (что само по себе ошибка), то он хотя бы должен иметь приоритет ниже, чем у даун-каста.
В C++ естественно всё компилируется нормально.
Спасибо за УДО!
Рискну описать пока другую проблему.
Билд 1950
Оптимизация в режиме "Математические вычисления".
Имеем маленькую сеть агентов, часть в локальной сети, часть удаленно находятся, все объединены с помощью Hamachi в одну сеть.
Откомпилированный файл занимает примерно 11 мегабайт, исходник 20.
Интернет не очень быстрый скорость на отдачу/прием - 766/6137 kbps.
Агенты не продаются через CLOUD, единовременно используются только мной.
При оптимизации очень часта ситуация, когда агенты на удаленной сети не могут начать работу, вот лог относительно одного из агентов с такой проблемой:
Решением является уменьшения числа удаленных агентов и запуск их по одному-двум.
Как я понимаю, что происходит передача данных, которая обрывается из-за повторного запроса терминала на соединение, т.е. терминал не знает, что уже передает данные агенту и нужно просто подождать окончания их передачи.
P.S. Если чего то не хватает, то просьба сразу не банить, а истребовать недостающую информацию, что принято в цивилизованном обществе - регламента то сейчас для баг репортов нет!
Билд 1973.
Проблема больше не проявляется. У себя изменений никаких не делал.
Поспешил с выводами. Проявляется.
Обнуление последних элементов индикаторных буферов на случай, когда условия не исполняются, не дало результата.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Новая версия платформы MetaTrader 5 build 1930: Плавающие окна графиков и .Net библиотеки в MQL5
Anatoli Kazharski, 2019.01.17 22:22
Да, текущее значение при увеличении буферов нужно принудительно обнулять, если все условия не исполняются. Я сообщу о результате, когда внесу исправления и проведу тесты.//---
Результаты оптимизации не совпадают с результатами тестов.
Билд 1973.
Проблема больше не проявляется. У себя изменений никаких не делал.
Поспешил с выводами. Проявляется.
Обнуление последних элементов индикаторных буферов на случай, когда условия не исполняются, не дало результата.
//---
Результаты оптимизации не совпадают с результатами тестов.
Замените индикатор на что-нибудь из стандартной поставки. Если исчезнут расхождения - проблема в Вашем индикаторе.
Замените индикатор на что-нибудь из стандартной поставки. Если исчезнут расхождения - проблема в Вашем индикаторе.
Так и пытаюсь выяснить, в чём именно проблема.
В тестере, в индикаторе, в эксперте. Неважно.
На графике всё показывает правильно. В режиме визуализации в тестере тоже.
Почему результаты оптимизации врут?
Замените индикатор на что-нибудь из стандартной поставки. Если исчезнут расхождения - проблема в Вашем индикаторе.
Обнаружил, что многие результаты совпадают.
Теперь ищу, при каких параметрах бывают несовпадения и почему.
По крайней мере изменения есть в результатах оптимизации в билде 1973. Нет чрезмерно завышенных показателей фактора восстановления, как было показано ранее на скриншотах.
Так и пытаюсь выяснить, в чём именно проблема.
В тестере, в индикаторе, в эксперте. Неважно.
На графике всё показывает правильно. В режиме визуализации в тестере тоже.
Почему результаты оптимизации врут?
Использую только Bruteforce-оптимизацию. На моих советниках все совпадает идеально даже тогда, когда используется предсказание, какой будет результат Тестера.
Использую только Bruteforce-оптимизацию. На моих советниках все совпадает идеально даже тогда, когда используется предсказание, какой будет результат Тестера.
Провёл сейчас множество оптимизаций с разными временными диапазонами и разными диапазонами параметров эксперта. Полное совпадение.
Перед этим скорее всего старые результаты оптимизации (генетический алгоритм) рассматривал.
Вопрос закрыт. Всем спасибо за помощь.