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

[Slava]

Fleder:

Компилятор воспринимает число 13.7 как тип double. Но в то же время это число может быть без потерь преобразовано в тип float

и это предупреждение излишне. 

Откуда у Вас сведения, что вещественное число 13.7 может быть преобразовано в тип float без потерь?

[Artem Temnikov]

stringo:
Откуда у Вас сведения, что вещественное число 13.7 может быть преобразовано в тип float без потерь?

А разве нет? Число 13.7 = 0.137*1е+2. Разве преобразовывая три разряда после запятой в тип float  можно допустить потери? По моим наблюдениям точность начинает теряться при попытке преобразовать

числа от шести разрядов после запятой и более. 

 

Пробовал использовать тип float для сохранения пятизначных котировок символов (например, 1.38829) в бинарный файл. После их обратного чтения из файла и попыток отобразить на чарте в  виде

свечного индикатора наложенного на свечи самого чарта замечал кое-где небольшие несовпадения. Но после нормализации до пятого знака они исчезали. 

Но там происходили двойные потери точности: сначала из double в float, а затем обратно из float в double. 

[Slava]

https://www.mql5.com/ru/docs/convert/normalizedoubleFleder:

А разве нет? Число 13.7 = 0.137*1е+2. Разве преобразовывая три разряда после запятой в тип float  можно допустить потери? По моим наблюдениям точность начинает теряться при попытке преобразовать

числа от шести разрядов после запятой и более. 

 

Пробовал использовать тип float для сохранения пятизначных котировок символов (например, 1.38829) в бинарный файл. После их обратного чтения из файла и попыток отобразить на чарте в  виде

свечного индикатора наложенного на свечи самого чарта замечал кое-где небольшие несовпадения. Но после нормализации до пятого знака они исчезали. 

Но там происходили двойные потери точности: сначала из double в float, а затем обратно из float в double. 

Нет. Это - бесконечная дробь. Мы писали, писали, а Вы не читаете

[Artem Temnikov]

stringo:
Нет. Это - бесконечная дробь. Мы писали, писали, а Вы не читаете

Мы читаем! Но потеря происходит "технически" (особенности формата) и в тех разрядах, которые и не нужны.

void OnStart()
{
  Print((float)(13.7));   //13.7 - потерь "не видно"
  Print((double)(13.7));  //13.7 - здесь тоже
}

[A100]

A100:

Тоже возник такой crash. Возникает при запуске скрипта, если не сопадает build Терминала (910) и Компилятора(921)

 

А вот и код

class A  {
        int     array[];
};
void OnStart()
{
        A *a = new A();
        if ( a != NULL )
                delete( a );
}

Компилятор 930, Терминал 910. Результат: 

 

[Artem Temnikov]

A100:

А вот и код

Компилятор 930, Терминал 910. Результат: 

 

А как так получилось, что терминал 910, а компилятор 930?

Если оба 910, то этот скрипт не "падает".

[A100]

Просто не один терминал (точно не знаю, но по-моему в Маркете это обычное дело)

Могу поделиться оригиналом из папки ...\MQL5\Scripts

[Artem Temnikov]

A100:

Просто не один терминал (точно не знаю, но по-моему в Маркете это обычное дело)

Могу поделиться оригиналом из папки ...\MQL5\Scripts

Что ж, что и требовалось доказать Win XP 32 bit :

[Renat Fatkhullin]

Обновитесь на 930 билд полностью, пожалуйста.

[M24]

Renat:
Обновитесь на 930 билд полностью, пожалуйста.

   Доброго времени суток. Обновился до 930 билда. Возникла следующая проблема: метод StringSplit лепит в результирующий массив дополнительное пустое поле.

   Если исполнить скрипт:

   ushort fields_delimiter=StringGetCharacter("_",0);
   string str="_мама_мыла_раму_";
   string str_array[];
   int fields_num=StringSplit(str,fields_delimiter,str_array);
   for(int i=0;i<fields_num;i++)Print("str_array["+i+"] = "+str_array[i]);

   то получим в результате:

  str_array[0] =

  str_array[1] = мама

  str_array[2] = мыла

  str_array[3] = раму

  str_array[4] =

  Элемента под индексом 4 быть не должно. До обновления все работало, после не сходится количество полей в строке при сравнении. Приходится проверять элементы массива на пустую строку.