Миграция с С# на МТ5 - страница 2

Новый комментарий
 
Renat Fatkhullin:

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

Нашел CreateBitmap и пр. , но что с этим делать не понимаю. М.б кто нибудь нарисует простенький экземпл в неск строчек.

Допустим надо передать массив double a[15,60] из одного советника в другой.

PS не могу найти, статические классы в MQL существуют?

 
Yuriy Asaulenko:
Часть индикаторов меняются достаточно медленно, и от их отставания в пределах неск тиков существенно ничего не меняется. А те, что критичны, можем дождаться завершения расчетов. Я и написал - по возможности, независимо от  того закончились ли вычисления в других потоках.
Значит, их не нужно считать на каждом тике. Если все равно советник не получит самые последние данные - зачем их все время рассчитывать?
 
Yuriy Asaulenko:

Нашел CreateBitmap и пр. , но что с этим делать не понимаю. М.б кто нибудь нарисует простенький экземпл в неск строчек.

Допустим надо передать массив double a[15,60] из одного советника в другой.

Проще через гл. переменные. Имя можно генерировать из счетчиков цикла. Что-то типа:

for ( int i = 0; i < 10; i ++ )
{
  for ( int u = 0; u < 10; u ++ )
  {
     GlobalVariableSet( "EA_Name_" + (string)i + "_" + (string)u, i*u );
  }
}
 
Andrey Khatimlianskii:

Проще через гл. переменные. Имя можно генерировать из счетчиков цикла. Что-то типа:

Да, спасибо, я именно так и собирался сделать. Т.к. имя переменной - строка. Вначале я этого не понял и полагал, что можно как к элементу массива.

Но через битмапы тоже интересно было бы разобраться.

 
Andrey Khatimlianskii:
Значит, их не нужно считать на каждом тике. Если все равно советник не получит самые последние данные - зачем их все время рассчитывать?

Да, Вы правы. Их достаточно считать через неск. тиков, но обязательно по close, при закрытии свечи. Считается только потому, что так проще. Тем более, что даже если считать время от времени, проблему задержек это не снимет, они все равно возникнут на тиках, где медленные сигналы считаются.

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

 
Yuriy Asaulenko:

Да, Вы правы. Их достаточно считать через неск. тиков, но обязательно по close, при закрытии свечи. Считается только потому, что так проще. Тем более, что даже если считать время от времени, проблему задержек это не снимет, они все равно возникнут на тиках, где медленные сигналы считаются.

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

Почему?

Если написать индикатор так, чтоб он рассчитывался не каждый тик, а раз в 30 секунд/минуту/1 бар, то тормозить будут только те запросы, которые приходятся на новый интервал расчета.

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

 

Например, если в 15:30:00 ваш индикатор начал считаться, а закончил в 15:30:12, то в этом промежутке советник все равно получит старые данные, и если новые данные дали бы сигнал на вход, то он будет пропущен (появится только после 15:30:12).

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

12
Новый комментарий