Errors, bugs, questions - page 686

 
abolk:
Another option is to consider the opening price to be the price that was formed in the previous price range. The example of opening markets has shown that this is incorrect.

Don't attribute this nonsense to me. I repeat:

The proposal is elementary: form the bars according to a time model when the opening price equals the ACTUAL price at the time of formation of the minute. ACTUAL (actually existing bid price), not the closing price of the previous bar!

The market for each FI opens at the moment when the offer price for that FI appears. In the same FOREX the market does not open for all FI at once.

 
abolk:

You yourself have derived the rule: "No price, no bar".

If the market was open, but there was no liquidity (sellers or buyers), there was no price. There was either "ask price" or "bid price", but in the absence of one of the parties of the deal - the price was absent, there was only the price of the previous period.

And it is correct, when the decision about the price in case of multi-currency synchronization is made by the TS itself, not by the terminal. Because the question of what is the price in case of absence of the price is an ambiguous one.

OK, Andrew, you've almost convinced me.

Then let the terminal fill the bars missed by the growler with NAN - I agree! But it does not remove them from the time series irreversibly (by standard means). All I need is a standard synchronization tool. I will decide for myself what to fill the "undefined" bars with. Even (at least) I am ready to agree to not display the missed bars, although it does not allow me to visually compare the charts of different instruments.But I need synchronized (by bar number) quotes for calculations. So my question is - am I the only original developer or does anyone else need them? What percentage of those in need? Does this percentage grow or shrink? And finally, which compiler generates faster code - MQL5 or C++?

 
The task is simple, to make the tester give as few inaccuracies as possible. At the moment, the tester almost always lies, saying that at the moment of formation of the minute the price was equal to the open price of the bar. This is the reason why arbitrage always occurs at open prices in the tester, while there is no arbitrage at close prices. And, as a consequence of using the potic model of bar forming, TC will have to spend its computing resources on synchronizing several FI on bar closing prices. The developers save on matches to let users waste a lot of computing resources on stupid synchronization every time they run in the tester. They don't let them do this synchronization before running optimization.
 
hrenfx:

The market for each FI opens when there is a supply price for that FI. In FOREX, the market does not open for all FIs at once.

Well, then the only thing to do is to force all market participants to act exclusively at the same time.

One of the questions of multicurrency strategies is whether it is correct to consider at a given moment in time the last price that took place so and so long ago to be adequate.

 
abolk:

One of the issues with multi-currency strategies is whether or not it is correct to consider at this point in time the last price that took place so long ago to be adequate.

Absolutely correct as long as the past price relates to the current trading session. Again, take the pricing of potatoes.
Документация по MQL5: Получение рыночной информации / SymbolInfoSessionQuote
Документация по MQL5: Получение рыночной информации / SymbolInfoSessionQuote
  • www.mql5.com
Получение рыночной информации / SymbolInfoSessionQuote - Документация по MQL5
 
hrenfx:
Absolutely correct if the past price refers to the current trading session. Take potato pricing again.
Correct if you take the past price into account when making decisions in the current session, but attributing the past price to the current session is incorrect. The definition of price I gave above. We must distinguish between "the price of the act of buying/selling", "the price of demand" and "the price of supply". We "don't know the bid price". A trading session is based on its "buy/sell price". You, on the other hand, propose to base the trading session on the "act of buying/selling" prices of the previous period. Why transfer these prices to the current period, if they were formed in the last period and are already known and can be obtained.
 
abolk:
Correct when you take the past price into account when making decisions in the current session, but it is incorrect to relate the past session price to the current session.

Isn't that what it says here?

hrenfx:
Absolutely correct when you relate the past price to the current trading session. Again, take the pricing of potatoes.

Tell me one flaw in this bar formation model:

A new minute arrives - a bar is formed, the opening price of which is the bid price at the time of the new minute. In this case, if the offer price is not available at the moment of the new minute (opening of a trading session), a bar is not formed, or is formed with the value NAN (for the opening price, as High, Low and Close can already be). Bars during a closed trading session are not formed.

 
hrenfx:

Tell me one flaw in this model of bar formation:

A new minute comes - a bar is formed, the opening price of which is the bid price at the time of the new minute. In this case, if the offer price is not available at the moment of a new minute (opening of a trading session), the bar is not formed, or is formed with the value of NAN. Bars during a closed trading session are not formed.

Highlighted is incorrect based on the definition of price. You constantly equatethe "price of the last trade" with the "price of a trade that has not yet taken place". Not only that, but we have already made one questionable assumption when we equate "last trade price" with "bid price". Do you keep starting to build the bar on "bid prices"? What are these prices? How do we know them?
 
abolk:
Highlighted is incorrect based on the definition of price. You constantly equate"price of the last transaction" with "price of a transaction that has not yet taken place". Not only that, we have already made one questionable assumption when we equate "price of last deal" with "offer price". Do you keep starting to build the bar on "bid prices"? What are these prices? How do we know them?

You keep attributing some nonsense to me, which you read between the lines. Here is a concrete example of the implementation of my suggestion

  1. 00:59:58 - EURUSD price comes in at 1.2301.
  2. 00:01:00 - the price of 1.2301 has been valid for 2 seconds, which is why the opening price of the 00:01 bar is equal to it - 1.2301.

Another example:

  1. Opening of the trading session at 00:00:00.
  2. The first price appears at 00:02:34 - 1.2301. Then within a minute the price changes within the range of 1.2290 - 1.2310. And at the end of 00:02:02 minutes it becomes 1.2305.

For this example, we have three bars:

  • 00:00 - {NAN, NAN, NAN, NAN} (OHLC);
  • 00:01 - {NAN, NAN, NAN, NAN} (OHLC);
  • 00:02 - {NAN, 1.2310, 1.2290, 1.2305} (OHLC);

Where is the flaw?

 
MetaDriver:

OK, Andrew, you've almost convinced me.

Then let the terminal fill the bars missed by the growler with NAN value - I agree!!! But it does not remove them from the time series irrevocably (by standard means). All I need is a standard synchronization tool. I will decide myself what to fill the "undefined" bars with.I can even (at least) agree to not display the missed bars, although it deprives me of the possibility to visually compare the charts of different instruments. But for calculations, I need synchronized (by bar number) quotes.

I cannot say anything about the presence or absence of "failed" bars - it is not critical for me. Also, I don't know about the implementation problems. Maybe they are essential and the current solution is a compromise for now. If it is so important and it is not present in the terminal, the "drawing" of "failed" bars can be implemented manually.
Reason: