The future of automated trading - page 18

 

In the long run, if you can trade successfully, you can do it over the phone or from a web interface.

I have added buttons for quick trading, orders can be shifted from the chart - and that's OK).

The buttons for fast trading have been added and the chart orders can be rescheduled - that's fine.

 
Rosh:

Any accountant will tell you that there is a lack of data and it all depends on accounting policies.

But! Regardless of the accounting policy, when all the purchased sugar is sold, the financial result will be the same. Don't kid yourself.

1. You are right. But! ANY accountant uses an accounting and tax policy that is the most appropriate and the most convenient for them (within the laws of their country).

It makes sense when all questions of dispute are presented optionally, at trader's or broker's/exchange's choice. Is not it so?

2) What I will do with the remaining bag of sugar is my own business. Moreover, no one knows when and at what price I will get rid of it.

 
Manov:

:)))

That's your very big mistake ! Very, very big...

I'm sorry.

God will provide!
 
Interesting:

It makes sense when all sporting issues are presented optionally, at the choice of the trader or the BC/Exchange. Isn't it so?

All that remains is to find an exchange with lots. And while there are no such exchanges, this issue is absolutely clear and not controversial at all.
 
Interesting:

Doesn't this example seem a little absurd?

They bought a bag of sugar for 240 roubles. The price dropped to 140, so we bought another sack.

The price went up to 175 roubles, and we sold a sack at that price.

Oh, my goodness - as a result of the work done, we made a loss (even though it's clear to everyone that there has to be a profit)...

Don't you think that the result of all the work, so to speak, translated into the market we are interested in, should be a bag of sugar at, say, 205 roubles?

Roughly speaking, in human terms, there is detailed accounting and there is average accounting. Detailed accounting is if assets are accounted by combining on some detailed attributes say ten bags are bought in one transaction and they are accounted as belonging to one transaction, and then we buy five more bags and they will be accounted separately from the first. Or even singly, object-by-object, each bag at its own price. Both are detailed accounting. And if we add up all the bags of one asset from different deals and count the price as an arithmetic average, then this is generalized accounting, accounting at an average price.

There is a gravitational pull towards generalised and average-price accounting everywhere, as it is simpler to technically implement and understand. And only supervisory and controlling bodies and organizations insist on detailed accounting. This is the way it is in life.

And in MT5 detailed accounting would give more opportunities to develop strategies.

In our case, the developers chose generalized accounting and we don't have to choose here. They had their reasons.

But detailed accounting can be introduced in the product in parallel to the generalized one. It can be implemented in MT5 without breaking the current scheme. As an option. It would be a big plus. But maybe the developers didn't consider this situation from this angle.

In accounting it all has been discussed a hundredfold and worked out in detail. And both schemes work perfectly well in the same products.

 

By the way, it is not necessary to introduce an itemised accounting scheme at all. It would be enough to introduce the possibility of storing more user data on the server and then whoever needs to do the detailed accounting themselves. And the lockers would be happy.

I have already mentioned this before.

Say, if by the same scheme as warrants, the same commands could work with a limited amount of service records stored on the server, it would be quite a working solution.

 
timbo:

Because it's consistent with common sense. Because that's how every stock exchange in the world works. Because that's how the maths works.

Why shouldn't you have a loss if you're sitting on a bag of sugar that you paid 240 for and is only worth 175 today?

MT5 has brutally ruined the buzz for a lot of sixth point enthusiasts.

There may be a loss to be had, it's called a PROSAD. As far as I'm concerned if trading conditions allow I can hold a non sac of 20 (or even 200).

Some will say that's not reasonable, maybe. But ultimately it's up to me to choose what's reasonable in relation to my deposit.

I already understood that MT5 is BLOWING TRADERS HARD on certain issues, you don't have to be a great mathematician to foresee the joy of different DCs on such trivialities.

PS

Again, what I will do with the remaining bag is my own business. Not the DC, not the US legislator - my personal...

Renat:

You don't understand for exactly one reason - you haven't thought about the implementation and implications of a mixed model.

On the technical side of implementation this is complete suicide. I recommend that you spend a couple of days thinking deeply about the problem, with a compulsory table of trades and full transaction processing schemes. We spent a lot of time thinking about it, did two approaches in 2004 and 2007, and prudently declined.

Without calculated spreadsheets and schemes there is no point in even discussing this topic. As a dessert, think about the consequent duality of the models of any experts who go mad that there are two completely different models of how orders work.

I'm not asking for the plaques for nothing.

Symbol
Operation
Volume
Price
Average price
Profit
sugar
BUY
1
240240

BUY
1
140190

SELL
1
175190
-15





Here everything is correct - at an average buy price of 190 there was a sell at 175 which resulted in a loss of 15. Don't fool yourself by looking for a profitable matching order. The final financial result will not change.

First intelligible answer on the subject of my question. Thank you.

I was thinking about implementing both the MIXED model and both of these models separately. I came to the conclusion that I should use one of these models on a permanent basis (perhaps optionally for each group of instruments).

Maybe with this approach YOU as developers would have to write not 1.5 but 2.0 million lines of code (sorry, it sticks in my memory). Perhaps it would have complicated the work of the server in a certain way, above all the server. Perhaps certain things would still have to be done (which I and many others don't even know about).


But in the long run, it would probably be easier and more convenient than the approach where trades would be done in MT4, and analysis would be done in MT5.

And it will certainly be easier than developing all sorts of COSTELS designed to connect the two terminals.


I will of course calculate such things, and many others. As I did when moving from R2 to MT4. But in any case, with the current state of affairs, I will either have to give up trading on MT5 (apply it only for analysis) or accept these NOT VERY WANTED EXPENSES...

PS

If by some miracle, MT4 manages to survive and traders and brokerage companies want to introduce elements of OOP into it, will they do it or not?

 
timbo:
All that remains is to find an exchange with lots. Then it will be "so". And while there is no such exchanges, this issue is absolutely clear and not controversial.

And as I understand it, the exchange can't decide with or without locks? Or maybe they can make it optional?

By the way, let's see what else the API will give to the server.

timbo:
God will provide!

They already did - it's called MT4. I think that at least 50% of those who have real accounts in it (the real ones) will stay on it.

I do not exclude that in some cases, probably most of them, those who use MT4 will use MT5 for analysis or trading on exchanges...

Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
  • www.mql5.com
Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете - Документация по MQL5
 
gip:

Roughly speaking, in human terms, there is detailed accounting and there is average accounting. Detailed accounting is when assets are accounted by combining some detailed characteristics, say ten bags are bought in one transaction and they are accounted as belonging to one transaction, and then we buy five more and they are accounted separately from the first. Or even singly, object-by-object, each bag at its own price. Both are detailed accounting. And if we add up all the bags of one asset from different deals and count the price as an arithmetic average, then this is generalized accounting, accounting at an average price.

There is a gravitational pull towards generalised and average-price accounting everywhere, as it is simpler to technically implement and understand. And only supervisory and controlling bodies and organizations insist on detailed accounting. This is the way it is in life.

And in MT5 detailed accounting would give more opportunities to develop strategies.

In our case, the developers chose generalized accounting and we don't have to choose here. They had their reasons.

But detailed accounting can be introduced in the product in parallel to the generalized one. It can be implemented in MT5 without breaking the current scheme. As an option. It would be a big plus. But perhaps the developers didn't consider this situation from this angle.

In accounting it all has been discussed a hundredfold and worked out in detail. And both schemes work perfectly well in the same products.

This is important. It should also be noted that the financial results for both schemes will be the same.


Let's go back to the sugar sacks example.

1. Smoked 1 sack at 240 - sugar asset 1 sack totaling 240

2. Bought 1 sack at 140 - sugar asset 2 sacks for a total value of 380

3. Sold 1 sack of sugar at 175 - 1 sack with a total asset value of 205

4. so, in order to sell the residual sugar and not be at a loss, it has to be sold for 205.


If we calculate in detail, each sack separately.

1. Smoked 1 sack at 240 - sugar asset 1 sack at 240

2. Bought 1 sack at 140 - the sugar asset is 1 sack at 240 and 1 sack at 140

3. Sold 1 sack at 140 for 175 - asset 1 sack at 240 and 35 profit

4. thus, to sell the remaining sugar at 240, it has to be sold for 240. Or, put in a profit of 35 and then the breakeven would be 205 again.


In both =205, the price at which to sell the residuals to be at breakeven. So, as said before, 35 is an ethereal profit that doesn't really exist. It's just that in a generalised account it is where it should be, in the average price. And most importantly, this ethereal profit does not confuse the reporting.

The introduction of parallel reporting is seen by many authorities as an attempt at financial fraud.

 
gip:

Roughly speaking, in human terms, there is detailed accounting and there is average accounting. Detailed accounting is when assets are accounted by combining some detailed characteristics, say ten bags are bought in one transaction and they are accounted as belonging to one transaction, and then we buy five more and they are accounted separately from the first. Or even singly, object-by-object, each bag at its own price. Both are detailed accounting. And if we add up all the bags of one asset from different deals and count the price as an arithmetic average, then this is generalized accounting, accounting at an average price.

There is a gravitational pull towards generalised and average-price accounting everywhere, as it is simpler to technically implement and understand. And only supervisory and controlling bodies and organizations insist on detailed accounting. This is the way it is in life.

And in MT5 detailed accounting would give more opportunities to develop strategies.

In our case, the developers chose generalized accounting and we don't have to choose here. They had their reasons.

But detailed accounting can be introduced in the product in parallel to the generalized one. It can be implemented in MT5 without breaking the current scheme. As an option. It would be a big plus. But perhaps the developers didn't consider this situation from this angle.

In accounting it all has been discussed a hundredfold and worked out in detail. And both schemes work perfectly well in the same products.

That's what I mean...
Reason: