Errors, bugs, questions - page 257

 
alexvd:

It doesn't look like it.

It turns out that there were only 2 (out of 45) losing trades, both of which were buying.

Maybe I'm looking in the wrong place?


Marked in red: Short positions are 5 out of 45. Let's assume 40 is 95%. Question - Why 5 = 100%, it is logical to assume - 5%.

Although it seems to me that in this case it should be 5 (11.11%) and 40 (88.89%).

alexvd:

Try clearing the cache. Tried different options, different browsers - the addition was successful.

You are inserting a picture directly into a comment and not as an atach, aren't you?

Yes, in the text. I'll try that, although it was added to this forum without any problems... :)
 
Interesting:

Marked in red: Short positions are 5 out of 45. Let's say 40 is 95%. Question - Why 5 = 100%, it is logical to assume 5%.

Although, it seems to me that there should be 5 (11.11%) and 40 (88.89%) trades.

A total of 45 trades:

  1. 5 on sale, 40 on purchase
  2. 2 unprofitable (2 to buy), 43 profitable (total).

Here we have the following results

5 Sell deals - 5, and 100% of them were profitable (not losing) (i.e. all the deals were profitable).

Buy trades - 40, 38 of them are profitable, i.e. 38*100%/40=95%.

Further

Profitable deals - 43 out of 45, i.e. 43*100%/45 = 95.56%

Loss trades - 2 out of 45, i.e. 2*100%/45 = 4.44%.

 
alexvd:

A total of 45 trades:

  1. 5 on sale, 40 on purchase
  2. 2 losing trades (2 buying trades), 43 profitable trades (total)

The total number of deals we have

Sell deals - 5, out of them winning (not losing) deals - 100% (i.e. all of them were profitable)

Buy trades - 40, 38 of them are profitable, i.e. 38*100%/40=95%.

Further

Profitable deals - 43 out of 45, i.e. 43*100%/45 = 95.56%

Loss trades - 2 out of 45, i.e. 2*100%/45 = 4.44%

Thank you, it is now clear what is what...
 

I have noticed this effect. When adding the indicator to the chart(in a separate window), the main candlestick chart stops updating (the price freezes), although in the window with quotes everything is OK - the price changes from red to green. Although the indicator has been added only to the window of one symbol, the price also freezes in the other window. Initialization and calculation of the indicator are inside the body: if(prev_calculated==0). Closing prices not starting from the previous day participate in the calculation (the current close price does not participate). After the indicator calculation is completed, the price starts moving and changing synchronously with the window.
You can see it in the picture:

 
-Alexey-:

I have noticed this effect. When adding the indicator to the chart(in a separate window), the main candlestick chart stops updating (the price freezes), while in the window with quotes everything is OK - the price changes from red to green. Although the indicator has been added only to the window of one symbol, the price also freezes in the other window. Initialization and calculation of the indicator are inside the body: if(prev_calculated==0). Closing prices not starting from the previous day participate in the calculation (the current close price does not participate). After the indicator calculation is completed, the price starts moving and changing synchronously with the window.
You can see it in the picture:

The first calculation turns out to be very resource intensive. Check it, maybe the indicator code is not written in the most optimal way.

 
alexvd:

The first calculation turns out to be very resource intensive. Check if the indicator code is not written in the most optimal way.

Dear alexvd, unfortunately the Indicator now has more than 3000 lines of code with more than 20 classes and it is difficult to optimize the code (several hundred billion computing operations in loops), and this number may grow up to 10000 roughly. I meant that it is possible to somehow separate the updating of quotes in the candlestick chart into a separate program thread and the loading of indicator calculations into a separate thread. Frankly speaking, when I started my work I did not think the performance issue would arise so urgently on a desktop computer, while I want to use a small laptop as well.
 
-Alexey-:
I meant that it is possible to separate the updating of quotes in the candlestick chart into a separate program flow and the loading of indicator calculations into another flow.
Updating of quotes in the chart is just a display of the terminal base data, on which indicators are also calculated. To save resources, terminal base data is passed to the indicator as the input data, i.e. it cannot be changed until the indicator calculation is completed.
 
antt:
Updating of quotes on the chart is just a display of the terminal database data, which is also used to calculate the indicators. To save resources, terminal base data is passed to the indicator as input data, i.e. it cannot be changed until the indicator is calculated.
Got it, thanks!
 
-Alexey-:
Dear alexvd, unfortunately the Indicator now has more than 3000 lines of code consisting of about more than 20 classes and it is quite difficult to optimize the code (several hundred billion computational operations in loops), while this number may grow up to 10000 roughly. I meant that it is possible to somehow separate the updating of quotes in the candlestick chart into a separate program thread and the loading of indicator calculations into a separate thread. Frankly speaking, when I started my work, I did not expect that the performance issue would arise so urgently on a desktop computer, while I want to use a small notebook computer as well.

Try to optimise the performance of the indicator, the number of objects and lines is not important. Most likely it is possible to make the existing indicator (with 3000 lines) work with necessary speed.

An interesting variant is to put all resource-intensive calculations into timer (if it appears to be possible), then these calculations will not be performed on every tick.

And I'd like to optimise the calculator's box as much as possible (to reasonable limits).

 
Interesting:

Try to optimise the indicator, the number of objects and lines is not important. Most likely it is possible to make the existing indicator (with 3000 lines) work with necessary speed.

An interesting variant is if we put all resource-intensive calculations in a timer (if possible), then these calculations will not be performed on every tick.

And the calculator block should be optimized as much as possible (within reasonable limits).

In principle, it is possible to optimize work a little, because some identical data are calculated in objects of different classes, i.e. not once. But here we face another problem, namely - moving away from the concept of many black boxes, each of which can be debugged and be confident in it (i.e. each object is a fully autonomous unit, and if calculation of some intermediate data, which is identical in different objects, move outside of objects, autonomy will be lost, allowing to debug each class separately. In this case the structuring of the program will be lost, i.e. I won't be able to understand what I've written and a slightest error will be impossible to catch. Debugging speed will also increase dramatically as I'll have to run the whole algorithm instead of just a part of it. That's how the number of objects influences the speed.

That's why I think that similar optimization may be tried in the final stage, when the indicator is completely created, debugged and tested, but unfortunately it's still a long way off (I have been working at the initial stage for about 4 months now, since I finally realized that I am ready to try it). In books on Econometrics and Mathematics everything is scattered in fragments in different books (there is no practically unified presentation of material in details), the authors have errors and discrepancies in terms and algorithms, which are found by beginners only when referring to encyclopedic dictionaries, theoretical information comes into conflict with possibility of its practical realization, i.e. realization as numerical methods, and numerical methods themselves in their turn make requirements for functionality of software environment), the process is long tedious and viscous.

According to the logic of calculation, it must occur after formation of each candle, so it was originally supposed to be placed in the body of the function "is new bar", but the fact that its time can exceed this interval made me place it in the body of the function if(prev_calculated==0) so it would occur only once at the stage of debugging. I'll think about your timer suggestion - thanks.

Документация по MQL5: Основы языка / Функции
Документация по MQL5: Основы языка / Функции
  • www.mql5.com
Основы языка / Функции - Документация по MQL5
Reason: