Libraries: MT4Orders QuickReport - page 6

New comment
 
Forester #:

The information on max long drawdown is interesting. I made it for the whole array of strings. I haven't updated the code on the site yet.
But it's not quite clear what the date is for. If we make a point of division into back/forward tests (as I suggested), then we need to calculate statistics on them separately in 2 tables (max drawdown periods will be there too).

I have made a complete calculation of statistics for back/forward tests
.

The file has been updated.
 
Forester #:

What's not quite clear with the date is what it's for.

If you want to see from 2020 - please. From 2023, no problem. It's just that sometimes you don't care what it was in 2010. And it shows that the longest duration was in 2010.
 
fxsaber #:
If you want to watch from 2020, you're welcome to. From 2023, no problem. It's just that sometimes you don't care what it was in 2010. And it shows that the longest duration was in 2010.
Ah - got the point. Not for a tester with one expert/strategy, but for a real account where different ideas were tested.

Setting a Forward date would help to separate the stats.

 
Forester #:
Ah - got the point. Not for a tester with one expert/strategy, but for a real account where different ideas were tested.

I would use it myself only for a Tester. Real drawdowns are not interesting at all.

 
Forester #:
What's wrong with that?

Potentially dangerous style. For example, some time later you will want to write your own custom date formatting function and its call will be written in one super-duper long line out of habit:

Print("From " + TimeToString(From[i], TIME_DATE) + " MaxLengthDD = " + (string)(MaxLengthDD(BeginDD, EndDD, From[i]) / (25 * 3600)) + " days: " + Format(BeginDD) + " - " + Format(EndDD));

But there is no guarantee that Format-ids will be called after MaxLengthDD, just because they are listed to the right among the summands.

In principle, a one-line super-long record has negative sides: it is difficult to read and understand (in fact, it is difficult to repeat in your mind the parsing of an expression as a compiler does, but a human is not a compiler after all), it is difficult to debug. And such a compact record does not give any gain in performance either.

 

Super library! Thanks to the author!

Suggestions for improvements:
- hide interactive chart (or add another mechanism for this) when clicking on the chart again,
- save source in UTF-8, so that it could be read normally by GitHub (this is a one-time event, which will not threaten anything, but will add convenience)
- check file name for forbidden characters (\ / / : * ? ? " < > | : :), and replace them with something neutral (-, for example)
- add a parameter to save reports to the common folder of terminals, so that you don't have to search for them in agents' folders.


Thanks again, very handy tool!

 
Andrey Khatimlianskii folder of terminals, so as not to search for them in agents' folders


Thanks again, very handy tool!

I did it all.
Added 2 new parameters to the call
void QuickReport(string file_name, bool is_open_file_in_browser=true, int virtual_number=0, bool hide_account_and_name=false, bool common_path=false, bool fileANSI=true){...}
common_path - save to common terminal folder. To prevent files from being overwritten by another agent during optimisation, added agent number (3000, 3001,...) to file names. When saving in the tester folder (false), they are saved in the folder of the agent that performed the calculations.
fileANSI - save in ANSI encoding or in UNICODE. The size of UNICODE files is 2 times larger and they take longer to process, so if you upload a lot of data, for example 1 GB, it is more economical to use ANSI. UNICODE is added for compatibility with third-party services if you need it.

Character checker and hide button are also added, but I didn't describe them.
 
Forester #:
Added 2 new parameters to the call
This is how new parameters will be added. That is why it is better to write the signature once, where the structure of conditions is input. Then the signature will not change. That's what I did in Report.
 
fxsaber #:
This is how new parameters will be added. That is why it is better to write the signature once, where the structure of conditions is input. Then the signature will not change. That's what I did in Report.
Perhaps it is better. But it is necessary to maintain the current scheme of calls for compatibility with ready-made programmes that use the library, so that someone does not have to edit the code.
 
Forester #:
Probably better. But it is already necessary to maintain the current call scheme, for compatibility with ready-made programmes that use the library, so that someone doesn't have to edit the code.

Overloading will help.

12345678910
New comment