Новая версия платформы MetaTrader 5 build 4040: Улучшения и исправления - страница 29

Новый комментарий
 
Forester #:

Да уж...
Тест за 1 день происходит с 1 тика дня до последнего тика дня (например с 00:00:01 до 23:59:59), но никак не до 1 тика нового дня. Где тут пересечение границы суток в 00:00:00? Сделайте эксперт с принтами тиков и покажите, тик в следущем дне.

Тема вообще не об этом. А о том, что одни инструменты считают своп на последнем тике дня, а другие уже в следующем дне. Логично сделать одинаковое поведение для всех инструментов.

По поводу того, что должно считаться единообразно - думаю, все только "за" - осталось только от MQ услышать, почему так не сделано изначально и будет ли сделано.

По поводу однодневного интервала. Во-первых, не стоит отождествлять тики и интервал. Наличие или отсутствие тиков не отменяет и не сужает сам интервал. Во-вторых, утверждение, что тики одного дня идут "до 23:59:59" неверно (тут уже пытались обратить на это внимание с картинками). Как минимум можно было бы написать "по 23:59:59" (отличие в одну букву, но существенное), но и это неверно. Тики одного дня идут от 00:00:00 (включительно) до 00:00:00 следующего дня (исключительно, открытый на конце интервал). Это может быть 23:59:59.999(999). Когда ваша ТС не закрыла позицию до 00:00:00 следующего дня - она подписалась под снятие свопа - и не важно приписывать ли своп к последнему тику прошедшего дня или к первому тику наступающего. Тот факт, что тестер принудительно закрыл позицию на последнем тике периода тестирования - это вынужденная техническая мера - она не относится к ТС (как указал fxsaber) и потому не должна освобождать от свопа (который ваша ТС по-любому в реальности заплатила бы).

Не закрывать принудительно подвисшие позиции тестер не может, т.к. возникла бы куча других неоднозначностей (в частности, что брать в качестве результата), а закрывать на первом тике след. дня тоже некорректно.

 

Stanislav Korotky #:

Тики одного дня идут от 00:00:00 (включительно) до 00:00:00 следующего дня (исключительно, открытый на конце интервал).

Наверное, если бы принудительно закрытие указывалось бы с этим временем, вопросов было бы меньше по свопам, но больше по выходу за пределы торговой сессии.
 
fxsaber #:
Наверное, если бы принудительно закрытие указывалось бы с этим временем, вопросов было бы меньше по свопам, но больше по выходу за пределы торговой сессии.

Вот именно. Если указывалось бы такое время, то и цена бралась бы "из будущего" - или не бралась... Тут как ни сделай - кто-нибудь начнет возмущаться ;-).

 
b4082, неоднозначность доступа к protected полям/методам. 
class A
{
protected:
  int i;
  
  void f() {}
};

class B : public A
{
  B()
  {
    A a;
    
    this.f(); // MT4/5: OK.
    a.i = 0;  // MT5: OK. MT4:'i' - protected member access error
    
    a.f();    // MT4/5: 'A::f' - cannot access protected member function
  }
};
Строка для поиска: Oshibka 086.
 
Привет разработчики. У меня возникли некоторые ошибки в тестере стратегий. Ошибки возникают, когда количество входных комбинаций, отображаемых внизу вкладки входных данных, превышает 64-битное целое число. Одна из ошибок, которая возникает, заключается в том, что если в разделе форвардного тестирования выполнено более 65 536 проходов, то при 65 536 проходах тестер стратегий будет завершать неудачные проходы снова и снова. На вкладке журнала появится сообщение об ошибке: «Проходы не обработаны и возвращены в очередь задач». Если вы попытаетесь остановить тестер или закрыть программу, она зависнет на неопределенный срок. Фернандо повторил и написал об этом здесь: (https://www.mql5.com/en/forum/457425). Есть еще 3 ошибки, которые возникают при превышении 64-битного целочисленного значения. Я не очень хорошо умею их описывать, но старался изо всех сил в этом посте: (https://www.mql5.com/en/forum/454524). Я думаю/надеюсь, что когда один будет исправлен, он исправит и остальные 3, потому что все они происходят, когда вы превышаете целочисленное значение. Обычно я использую тестер стратегий, чтобы попытаться оптимизировать нейронную сеть с большим количеством весов и смещений. Входные комбинации для всех весов и смещений очень часто превышают 64-битное целое значение, что затрудняет оптимизацию больших нейронных сетей. Если бы кто-нибудь мог взглянуть на это, я был бы признателен. Спасибо.
 
Stanislav Korotky #:

По поводу однодневного интервала. Во-первых, не стоит отождествлять тики и интервал. Наличие или отсутствие тиков не отменяет и не сужает сам интервал. Во-вторых, утверждение, что тики одного дня идут "до 23:59:59" неверно (тут уже пытались обратить на это внимание с картинками). Как минимум можно было бы написать "по 23:59:59" (отличие в одну букву, но существенное), но и это неверно. Тики одного дня идут от 00:00:00 (включительно) до 00:00:00 следующего дня (исключительно, открытый на конце интервал). Это может быть 23:59:59.999(999). Когда ваша ТС не закрыла позицию до 00:00:00 следующего дня - она подписалась под снятие свопа - и не важно приписывать ли своп к последнему тику прошедшего дня или к первому тику наступающего. Тот факт, что тестер принудительно закрыл позицию на последнем тике периода тестирования - это вынужденная техническая мера - она не относится к ТС (как указал fxsaber) и потому не должна освобождать от свопа (который ваша ТС по-любому в реальности заплатила бы).

"до 00:00:00 следующего дня (исключительно)" говорит именно о том, что позиция закрыта ДО начала следующего дня и оснований для начисления свопа нет.

Окончание интервала тестирования (включая принудительное закрытие в конце теста) не должно переходить на следующий день.

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

 

Объясните по макросам:

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
#property script_show_inputs

#define ONEPARAM 1
#define TWOPARAM 2

#define CONCAT(ONE,TWO) #ONE"."#TWO 


void OnStart()
  {
//---
   Print(CONCAT(ONEPARAM,TWOPARAM));
  }

Результат работы старого релиза ( в частности 3211 от 14.02.2022 ) :  1.2

Результат работы текущего релиза и нескольких до него: ONEPARAM.TWOPARAM

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
#property script_show_inputs


#define DEFINES_GROUP_NAME(text) input group text 
#define GROUP(number) DEFINES_GROUP_NAME("Группа"##number)

GROUP(1);
GROUP(2);
GROUP(3);

void OnStart()
  {
   
  }

Данный скрипт в старых релиза ( в частности 3211 от 14.02.2022 )  компилится и работает.

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

Соответственно вопрос, это баги последних версий или изменение в логике работы с макросами?


Так же непонятен следующий  момент:

#property script_show_inputs


#define CONCAT(name1,type1) #name1 "_" #type1
#define GROUP(name1,type1) input group #name1 "_" #type1;

GROUP(Param,Simple);

void OnStart()
  {
//---
   Print(CONCAT(Param,Simple));
  }

Макрос CONCAT отрабатывает, в то время  как  макрос GROUP при компиляции выдает ошибку:

Но если мы GROUP слегка обрежем :

#define GROUP(name1,type1) input group #name1

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

Разве логика макроподстановки здесь должна работать по другому?

 
Forester #:

Советник:

Тест за 1 день по EURCHF начисляет свопы в конце дня для принудительно закрытых сделок в конце теста (end of test). Почему? Ведь в тестах по EURUSD и USDCHF не начисляет. Думаю надо или все символам начислять или всем не начислять, т.е. д.б. одинаковое поведение.

Что-то остранное происходит. Теперь за эту дату, свопы не начисляют в конце теста, и еще несколько точек проверил летом 2022 - тоже без свопов.

А вот если проверить сентябрь 2022 или 2023, то свопы опять появились.


На бету не обновлялся - все тот же релиз 4040. Тики не перезагружал.
Почему произошли изменения? - либо сотрудников ДЦ подключили к проблеме и они что-то исправил на своей стороне, либо серверный софт обновили у этого ДЦ.
Но теперь стала вообще странная - рандомная логика, в каких то периодах нет свопов в конце теста, а в в каких то есть. Т.е. если это было решение, то не кардинальное исправление ошибки на уровне логики, а какой-то костыль по датам, которые были замечены?

Жаль, что разработчики молчат и не пишут - работают ли над вопросом.

 

Объекты с более высоких интервалов не всегда отображаются на более низких интервалах, когда график увеличен, но они должны быть видны в том месте, где они должны быть видны. Пример на чистом графике US500: я перехожу на интервал H3 и рисую уровни Фибоначчи https://i.imgur.com/SyB23dS.png , затем перехожу на интервал M3 https://i.imgur.com/NxrhbIz.png и уровень виден при цене около 4588, я увеличиваю масштаб, и при этом уровне цены не видно этого уровня Фибоначчи https://i.imgur.com/r9BwXJt.png , я уменьшаю масштаб графика, и снова видна зеленая более толстая линия от уровней Фибоначчи https://i.imgur.com/BDRbUNe.png . Это был пример для воспроизведения, но у меня также были аналогичные ситуации с прямоугольниками, нарисованными на более высоких интервалах, и на более низких интервалах они иногда отображались, а иногда нет.


Относится также к стабильной версии 4040.

 
elavr # :

Объясните по макросам:

Результат работы старого релиза ( в частности 3211 от 14.02.2022 ) :  1.2

Результат работы текущего релиза и нескольких до него:  ONEPARAM.TWOPARAM

Вам необходимо обновить свой код. Препроцессор теперь будет работать больше как C++: https://gcc.gnu.org/onlinedocs/cppinternals/Macro-Expansion.html.

 #define TO_STRING(x)    #x
 #define CONCAT(ONE,TWO) TO_STRING(ONE) "." TO_STRING(TWO)
Macro Expansion (The GNU C Preprocessor Internals)
  • gcc.gnu.org
Macro Expansion (The GNU C Preprocessor Internals)
1...222324252627282930313233343536...38
Новый комментарий
Причина обращения: