Servicedesk. Complaints, suggestions. - page 16

 
Alexey Viktorov:

No, I got into it and got it right.

It's all about the position. If you want to get the price of additional position volume, you should ask for the transaction price, not the position price.

I know. But my error message is in the CPositionInfo description.

 
Francuz:
Administration, at least write something about my previous message. I have the impression that I went to the wrong place and the message was ignored.

We did. You got it right, others will get it too.

 
Francuz:

An error in the description of the standard library

Specifically in the description of CPositionInfo, PriceOpen() command

https://www.mql5.com/ru/docs/standardlibrary/tradeclasses/cpositioninfo/cpositioninfopriceopen

The returned value is not "open price" but"weighted average open price".

Yes, on a netting it is the weighted average opening price (on a hedge it is equal to the opening price).

Furthermore, even on a hedge in the position history (GUI), the closing price is also the weighted average.


The weighted average price does not correspond to the opening/closing price of the symbol. Therefore, even on a hedge, the trade history visualizers usually do not work correctly.

 
fxsaber:

Yes, on a netting it is the weighted average opening price (on a hedge it is the opening price).

Furthermore, even on a hedge in the position history (GUI), the closing price is also the weighted average.


The weighted average price does not correspond to the opening/closing price of the symbol. Therefore, even on a hedge, the trade history visualizers usually do not work correctly.

You get the point right away. But the weighted average openingprice problem has deeper implications. The matter is that if the position is increased, pennies begin to be divided, and they are lost when rounding. And as a result, the balance does not add up at the end. All transactions are made in whole rubles, and the final balance does not add up because of the lost kopecks.

 
Francuz:

You get the point straight away. But the weighted average openingprice problem has deeper implications. The thing is that if you increase the position even further, the pennies start to be divided, and they are lost in rounding. And as a result, the balance does not add up at the end. All transactions are executed in whole rubles, and the final balance does not converge because of the lost kopecks.

Is this in the terminal or in your code?

You haven't made any extra rounding?

 
Francuz:

You get the point straight away. But the weighted average openingprice problem has deeper implications. The thing is that if you increase the position even further, the pennies start to be divided, and they are lost in rounding. As the result, the balance does not converge in the end. All transactions are executed in real rubles, and the final balance doesn't add up because of the lost kopecks.

Sounds like an accusation of complete incompetence on the part of the developers of the trading platform.

 
Andrey Khatimlianskii:

Is it in the terminal or in your code?

Have you made any unnecessary rounds?

Why shake the air with words when you can check? FORTS ruble-dollar futures, the balance is calculated with the loss of kopecks.

 

A pattern of reproducing the error with a penny loss in the balance sheet, even when trading manually.

Buy 1 lot at an even price, buy 1 lot at an odd price, buy 1 lot at an even price, sell 1 lot, sell 1 lot, sell 1 lot.

 
Francuz:

Scheme to reproduce the mistake of losing a penny in the balance, even when trading manually.

Give investment access to this account.

 
fxsaber:

Give me investment access to this account.

I opened a demo account for an experiment. There is no investment access on it.

Reason: