Errors, bugs, questions - page 220

 
Yedelkin:
Ais:

We are talking about points close to the "Balance max" scale, which represents the "Result" column data, not the "Pass" column, so the sorting should be by the "Result" column

Of course :) Probably because of the circled hints "the specified value mustbe in the middle of the table window so that both lower and higher values are visible at the same time" :)

After sorting "the specified value should be in themiddle of the tabular window so that both smaller and larger values are visible at the same time", in order to show that the nearest value is not hidden by the tabular window boundary:

 
Ais:

After sorting "the specified value shouldbe in the middle of the table window so that both smaller and larger values are visible at the same time", in order to make it visible that the close value is not hidden behind the lower or upper border of the table window, therefore from the above figure this possibility can be allowed.

:):):) Definitely :) Especially, when one considers that from the cited screenshots it is clear both, that the sorting itself is present and that any "middle of the table window" is out of the question :)

But the theorising based on assumptions and assumptions goes far beyond the question"How about clicking here?". The answer to that question is simple: clicking doesn't make sense (given the sorting available).

 

1. the "click" question was not meant for you, because you cannot answer it, as you did not do the calculations.

2. Correct sorting is still missing.

3. Precisely because "no "middle of the table window" is in question", any conclusions drawn would be premature.

 
Ais:

The question was not meant for you.

:) Here's the decisive argument :) It's all classic :) Screenshots don't count :)

Let me explain. The question concerns anyone who has obtained results similar to those of sultanm'a. Before asking such questions, it would be a good idea to carefully read the screenshots. Then the question would have disappeared on its own.

Ais:

2. The correct sorting is still missing.

This will have to be remembered: turns out, there are right and wrong sorts. :) It all depends on how the author interprets them :)
 

The "click" question was not meant for you, because you cannot answer it, as you did not do the calculations, or rather, you do not have the results of the calculations.

The decisive argument is highlighted in colour.

 
Ais:

The "click" question was not meant for you, because you cannot answer it, as you did not do the calculations.

The decisive argument is highlighted in colour.

:) I will have to repeat it: The question concerns anyone who has obtained results similar to those of sultanm. Before asking such questions, it would be a good idea to carefully read the screenshots. Then the question would have disappeared on its own.

I have a whole cart full of similar calculation results. If sultanm has once again raised the issue, it does not mean that no one else is interested.

As for "highlighting the decisive arguments", that action shows that their author simply ignores sultanm's implementation of normal sorting, the presence of which can be seen with the naked eye in the screenshot he cited.

I should also add that sorting by the "Profit" column and sorting by the "Result" column are alternative sorting methods (for the purposes that sultanm or I want). To insist on using only one of the alternative sorting methods is a bit strange.

 

In the last build, CopyClose,CopyTime,CopyHigh... stopped working. And it doesn't work when copying by start and end dates of the required time interval. All indicators and Expert Advisors use these functions. Therefore, all work has stopped.

void OnStart()
  {
//---
datetime time,time1;
double Arr[];
time= D'2010.12.03 00:00'  ;
time1=D'2010.12.01 00:00'   ;    
 int copy=  CopyHigh(_Symbol,NULL,time,time1,Arr);
 Print("copy ",copy);
         
  }

Документация по MQL5: Доступ к таймсериям и индикаторам / CopyClose
Документация по MQL5: Доступ к таймсериям и индикаторам / CopyClose
  • www.mql5.com
Доступ к таймсериям и индикаторам / CopyClose - Документация по MQL5
 
Yedelkin:
Ais:

The "click" question was not meant for you, because you cannot answer it, as you did not do the calculations, or rather, you do not have the results of the calculations.

The decisive argument is highlighted in colour.

:) I will have to repeat it: The question concerns anyone who has obtained results similar to those of sultanm. Before asking such questions, it would be a good idea to carefully read the screenshots. Then the question would have disappeared on its own.

I have a whole cart full of similar calculation results. If sultanm has once again raised the issue, it does not mean that no one else is interested.

As for "highlighting the decisive arguments", that action shows that their author simply ignores sultanm's implementation of normal sorting, the presence of which can be seen with the naked eye in the screenshot he cited.

I should also add that sorting by the "Profit" column and sorting by the "Result" column are alternative sorting methods (for the purposes that sultanm or I want). To insist on using only one of the alternative sorting methods is a bit strange.

1. The question concerns anyone, but it's not for you, becauseyou can't answer it, becauseyou didn't do the calculations, or rather, you don't have the results of the calculations.

2. "Before asking such questions, it would be a good idea to carefully read the screenshots. Then the question would have disappeared on its own.

The question arose after careful reading, because it became clear that:

2.1. the sorting has been done on different indicators, as the "Balance max" indicator, whose values are given without sorting in the "Result" column, and the "Profit" indicator are different indicators, even if related;

2.2. after sorting by the indicator under study, the values nearest above and below should be visible simultaneously or, as a last resort,the scroll bar of the table window.

 

Ya :) There's no point in repeating the obvious.

 
sultanm:

Strange. This is the third time. There are two points on the graph that are close in value and one in the results.

it's the same result! the input parameters for these points are the same!

in the tester log for the second point you will find something like "result found in cache". that is, in some new iteration of the genetic algorithm tests may be run with such parameters that have already been used before. the result will be taken from the cache. in this case the point on the graph will be, but there will be no duplicate string in the results.

By the way, it seems to me that if modeling of requotes is chosen, then this cache should not be used. what do the developers think about it?

and another bug: when my genetic algorithm went beyond 10496, the graph began to display incorrectly - vertically it scaled correctly, you could understand that higher results were found, but horizontally it did not update. points as if added somewhere to the right, already beyond the border of the graph.

Reason: