Errors, bugs, questions - page 1129

 

A100:
32'535'244'799 != 32'535'215'999 - какое правильное? 

The correct one would be 32'535'215'999 for"3000.12.31 23:59:59"

And32'535'244'799 would be correct for"3001.01.01 07:59:59"

 
Fleder:

The limit for datetime type is simply not defined correctly:

Apparently the limit is defined considering the possibility of presenting local time in GMT or UTC at the same time. It would then make sense to make a wider range (+/-12 hours) from -43'200 to 32'535'291'599
 
Fleder:

The compiler treats the number 13.7 as the double type. But at the same time this number can be losslessly converted to the float type

and this warning is unnecessary.

How do you know that a real number 13.7 can be converted to the float type without loss?
 
stringo:
How do you know that the real number 13.7 can be converted to the float type without losses?

Isn't it? The number 13.7 = 0.137*1e+2. By converting three decimal places to float type, is there any loss? From what I've seen, accuracy is lost when you try to convert

numbers with six decimal places or more.

I tried using the float type to save five-digit character quotes (e.g. 1.38829) to a binary file. After reading them back from the file and trying to display them on a chart as

The chart indicator applied to the candlesticks of the chart itself has small discrepancies. But after the normalization to the fifth digit they disappeared.

But there was a double loss of accuracy there: first it was from double to float and then back from float to double.

 
https://www.mql5.com/ru/docs/convert/normalizedouble Fleder:

Isn't it? The number 13.7 = 0.137*1e+2. By converting three decimal places to float type, is there any loss? From what I've seen, accuracy is lost when you try to convert

numbers with six decimal places or more.

I tried using the float type to save five-digit character quotes (e.g. 1.38829) to a binary file. After reading them back from the file and trying to display them on a chart as

The chart indicator applied to the candlesticks of the chart itself has some small discrepancies. But after the normalization to the fifth digit they disappeared.

But there was a double loss of accuracy: first from double to float, and then back from float to double.

No. It is an infinite fraction. We wrote and wrote, but you don't read.
 
stringo:
No. It's an endless fraction. We wrote and wrote and you don't read

We read! But the loss happens "technically" (peculiarities of the format) and in those fractions which are not even needed.

void OnStart()
{
  Print((float)(13.7));   //13.7 - потерь "не видно"
  Print((double)(13.7));  //13.7 - здесь тоже
}
Особенности работы с числами типа double в MQL4 - Статьи по MQL4
  • www.mql5.com
Особенности работы с числами типа double в MQL4 - Статьи по MQL4: примеры использования экспертов, тестирования и оптимизации
 
A100:

I've had this crash as well. Occurs when running a script if the Terminal (910) and Compiler (921) do not match

Here is the code

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

Compiler 930, Terminal 910. Result:

 
A100:

Here's the code

Compiler 930, Terminal 910. Result:

How come the terminal is 910 and the compiler is 930?

If both are 910, then this script does not 'crash'.

 

Just not one terminal (I don't know exactly, but I think this is common in the Market)

I can share the original from the ...\MQL5\Scripts folder

Files:
Crash.ex5  4 kb
 
A100:

Just not one terminal (I don't know exactly, but I think this is common in the Market)

I can share the original from the ...\MQL5\Scripts folder

Well, that's what I had to proveWin XP 32 bit: