Is it possible to implement a RELIABLE accounting of the aggregate position structure in MT5? - page 31

 
kombat >> :

How many...

The banks of the Russian Federation are the successors to the banking system of the USSR, the banking system of the USSR is the successor to the bank of Tsarist Russia, the bank of the CR is the successor to ...

Do the math...

;)

Perhaps they would like those around them to believe it. But in fact they are nouveau riche with no history, no name, no reputation.

 
Avals >> :

The point is that some of this routine, which is typical of multi-expert trading in MT4, was automatic and was built into the architecture, which is not the case in MT5. Which of course is not fatal, but not convenient for everyone.

I'd even say it's not convenient or comfortable for everyone

neither am i.

But in most cases it's just a matter of habit:


Is it possible to implement in MT5 a RELIABLE accounting of the structure of an aggregate position?


maybe

Save to the file the information that is lost when you switch from the lot system to the netting system.

This will not slow down the performance of your EAs

-----

actually, it would be interesting to listen to developers

why they are against the implementation of both systems simultaneously

I think this would seriously increase the size of the distribution

and also slow down the whole system.

but you'd have to ask them.

 
knt-kmrd >> :

Is it possible to implement a RELIABLE accounting of the aggregate position structure in MT5?


possible

save in a file the information that is lost when you switch from the lot system to the netting system

This will not slow down the work of your Expert Advisors.

The issue is not the complexity of the implementation, but the reliability of the solution. Such a method has already been discussed and examples of its unreliability have been given.

 

It should be noted that these examples, as well as the concept of "reliability" itself, do not convince many people. You routinely substitute concepts, and by "reliability" you mean something else.


bingo - the thousandth flubber!

 
getch >> :

The question is not about the complexity of implementation, but the reliability of the solution. Such method has already been discussed and examples of its unreliability were given.


So tell me, dummy (sorry in advance, didn't read the topic first, lots of text)

how is reading from a file different from reading from the history, or from calling a standard µl4-function?

you can put anything you want in the file

You can set open time, open price and ticket number...

whatever you want :)

 
knt-kmrd писал(а) >>

So tell me, dummy (sorry in advance, didn't read the topic first, lots of text)

how is reading from a file different from reading from the history, or from calling a standard µl4-function?

you can put anything you want in the file

and the opening time, and the opening price, and the ticket number...

whatever you want :)

What if the file was lost? Or a failure occurred during the recording into the file, so the content and the orders did not correspond with the server? Or you have to log in from another company without the file? There are a lot of options where this information will be lost and if this loss is unintended algorithmically it may lead to serious financial consequences. I.e. this all adds a new link that can reduce the reliability of the system as a whole.

 
knt-kmrd >> :


So tell me, dummy (sorry in advance, didn't read the topic first, lots of text)

how is reading from a file different from reading from the history or calling standard µl4-function?

you can put anything you want in the file

You can set open time, open price and ticket number...

whatever you want :)


To the question how is it different, as well as on the earlier one about "implementation of two accounting systems and complexities".

There are no complications and certainly no increase in the distribution...

The question of accounting is in the plane of the most that is simple queries to the server's database.

I repeat: to the server database, i.e. wherever we are, from whatever terminal,

killed our file or not, proper operation is assured... as opposed to self-build...

 
In practice, a file can be killed without the possibility of reanimation in only one case:

if some "evil hacker" smashed a sledgehammer into a hard drive

and the file gets depressurized and the data on it gets lost.
But in this case, even MT4 will not save you, because the EA is dead.

In other cases, such as a sudden power outage,
the data on the disk (and hence in the file) is saved

---

there is, however, the possibility that some naughty program (e.g., another expert)

goes into the file and inadvertently erases the data

but it is not a question of the quality of the terminal but of the quality of the programmer :)

 
 
knt-kmrd писал(а) >>
In practice, a file can be killed without the possibility of reanimation in only one case:

if some "evil hacker" smashed a sledgehammer into a hard drive

and that one was depressurised with complete loss of the data stored on it
but in this case even MT4 won't save you because the Expert Advisor is dead

In other cases, such as a sudden power outage,
>> the data on the disk (and hence in the file) is saved.

---

there is, however, the possibility that some naughty program (e.g., another expert)

goes into that file and inadvertently erases the data.

but this is not a question of the quality of the terminal, but of the quality of programmer :)

You do not even have to kill the file, it is enough not to overwrite some information in case of a failure, for example.

Maintaining the positions is shifted to the user and can be an additional source of errors. Even purely logical when implementing this block.

Reason: