Errors, bugs, questions - page 711

[Anatoli Kazharski]

sergeev:
Use the classes.

Yeah, that's right. I hadn't realised. I don't even remember it, it's been suggested before.

That's how it turned out:

struct Buff { double b[]; };
//---
Buff lbuff[];
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   int i=2,j=1000;
//---
   ArrayResize(lbuff,i);
   ArrayResize(lbuff[0].b,j);
   ArrayResize(lbuff[1].b,j);
  }

Rosh:
Have a look at overloading operations section for example for CMatrix class, maybe this will suit you.

Thanks, I will study it.

[Yedelkin]

Rosh:

The fact is that a real number is stored in memory with no more than 17 significant digits.

Try this example to feel the difference:

We'll correct the description in the help.

Yes, Renat already explained above that Print() outputsdata of double type accurate to 4, not 16 decimal digits after the dot. That was the whole sticking point from the user's point of view.

[Rashid Umarov]

Yedelkin:

Yes, Renat already explained above that Print() outputsdata of double type to 4, not to 16 decimal digits after the point. That was the problem from the user's point of view.

No, Print() prints in %.16G format, which means that it will try to print a number with a dot and 16 significant digits. In this case, the number stored is 199.99999999999997, which has 17 significant digits (3 digits before the decimal point + 14 after the decimal point). When I try to print 16 digits, rounding starts, 7 is rounded to 10, one goes to higher digit, and 9 is there. The domino principle starts, the number printed gets rounded to 200.

Try an example:

void OnStart()
  {
   double a,b;

   a=7.0/200.0;
   b=7.0/a;
   Print("Print(b)=",b);
   Print("Print(DoubleToString(b,16))=",DoubleToString(b,16));
   double epsilon=MathPow(10,-13);
   Print("-------- После вычитания ",epsilon,"---------");
   b=b-epsilon;
   Print("Print(b)=",b);
   Print("Print(DoubleToString(b,16))=",DoubleToString(b,16));

   
  }

Look at PrintFormat().

[Yedelkin]

Rosh:

No, Print() outputs in %.16G format, which means that it will attempt to output a number with a full stop and 16 significant digits. In this case, the number stored is 199.9999999999999997, which has 17 significant digits (3 digits before the decimal point + 14 after the decimal point). When I try to print 16 digits, rounding starts, 7 is rounded to 10, one goes to the next higher digit, and 9 is there. The domino principle starts, the printed number is rounded to 200.

Take a look at PrintFormat().

Now I understand why we focus on the number of significant numbers being stored.

...But if a real number is stored with not more than 17 significant digits (in our case it is 199.99999999999997), where do the significant digits come from?

MP 0 victorg2 (EURUSD,M1) 11:04:42 Print(DoubleToString(b,16))=199.999999999999999716

? (I counted 19 discharges)

[Slava]

"In combat situations, the number of pi can be as high as four".

DoubleToString works slightly differently from the formatting in the printer (which is left to the CRT)

DoubleToString converts integer and fractional parts to strings separately and with a slightly faster algorithm than standard formatting.

[Yedelkin]

stringo:

In DoubleToString the integer and fractional parts are converted to strings separately and by a slightly faster algorithm than the standard formatting.

But then it turns out that a bit more than 17 significant digits are stored in memory . Otherwise where would the integer and fractional parts for conversions to strings come from? I.e. regardless of whether Print() or DoubleToString() is it, they get their data from somewhere (if we're talking specifically about storing "in memory with no more than 17 significant digits").

...Maybe, of course, I got caught up in the phrase "storing in memory", and I don't quite get it right due to my ignorance of the nature of storing real numbers.

[Slava]

Yedelkin:

But then it turns out that there are slightly more than 17 significant digits stored in memory . Otherwise, where do the integer and fractional parts for conversions to strings come from? I.e. whether Print() or DoubleToString(), they get their data from somewhere (if we're talking specifically about storing "in memory with no more than 17 significant digits").

...Maybe, of course, I got hooked on the phrase "storing in memory", and I don't quite get it right due to my ignorance of the nature of storing real numbers.

Sometimes up to 20 significant digits are stored, but not guaranteed. And in general, the larger the number in the integer part, the less accurate it is in the fractional part.

Why do you need 16 decimal places? Academic interest?

[Yedelkin]

stringo:

Sometimes up to 20 significant digits are stored, but it is not guaranteed. And in general, the larger the number in the integer part, the less accurate it is in the fractional part.

Why do you need 16 decimal places? Academic interest?

:) So as not to play spoiled telephone, let's look at the backstory.

Here victorg asked a question concerning Print() function's work and values it produces.

Here I showed him the reason.

Since he did not want to bother with problems of the Print() function,

I had the nerve to point out that the description of the Print() functionsays that "data of the double type are printed with an accuracy of 16 decimal digits after the point. Actuallyit turned out that the Print() function prints somewhat rounded data with a concrete example attached.

Then a heated discussion ensued, in the end no one was able to refute my example, and Renat outlined the first version and said that the reference book would be corrected.

A few days later, Roche put forward a second version, where the number 17 was mentioned.

Having joined the discussion, you suggested a third version, viz:"In DoubleToString the integer and fractional parts are separately converted to strings and by a slightly faster algorithm than the standard formatting" I.e. it already turned out to be a matter of algorithm speed.

Then I drew your attention to the fact that, in general, it was about the size of the stored number from the second version of Roche.

stringo:

Why do you need 16 decimal places? Academic interest?

Now you can answer those questions. I gave an example where the Print() function outputs rounded data. I didn't ask about the reasons for such behavior. My example was not disproved but I was just advised to use a different function and started explaining the reasons. And among these explanations there appeared a mention of 16 (17) decimal places. Since not everything was clear to me in those explanations, I asked questions "as I went along". - So it was not even an academic interest on my part, but simply a desire to understand what the idea was trying to convey to me.

[Victor]

Yedelkin:

. . . So it's not even academic interest on my part, but simply a desire to understand what message I was trying to get across.

I couldn't agree more. Academic interest has nothing to do with it.

Read"real number" in the documentation. IEEE standard 754, there are 15 significant digits in the table for double . Taking this into account, there are four options - 15, 16, 17 significant digits and option when integer part and fractional part are stored separately. But it doesn't work like that! What does academic interest have to do with it? It's more about elementary formal logic, which, by the way, is the basis of this programming language.

It seems to me that the programmer should write programs, not investigate the compiler.

PS

I'd like to take this opportunity to clarify:

If I increase the size of a dynamic array using the ArrayResize() function, is it guaranteed that the data previously placed in it will be preserved? Perhaps this point should be explicitly mentioned in the documentation (in the ArrayResize() function description).If anyone knows, please advise.

[Rashid Umarov]

victorg:

If I increase the size of a dynamic array with ArrayResize(), is it guaranteed that the data previously placed in it will be preserved? Perhaps this point should be explicitly mentioned in the documentation (in the description of the ArrayResize() function).If anyone knows, please advise.

They will be when the size is increased, otherwise there is no point in such a function.