Interesting topic for many: what's new in MetaTrader 4 and MQL4 - big changes on the way - page 50

 
MetaDriver:

I don't think seeking to understand without judgement is the gravest of my sins. ;)

Thinking - in terms of the gravity of the sin, of course - is the greater. I agree.
 
hrenfx:
Thinking, in terms of gravity of sin, of course, is stronger. I agree.

I'm glad you got that right. So you better get yourself a cauldron next to mine. It'll give us plenty of time for chitchat. No parole.

;)

 
MetaDriver:

Are you sure that MQ bars M1 are stored unpacked?

Then how come there are delays in getting history (small but present), but reapplying (like to the cache) is faster.

Apparently in the history file bars are stored as changes from synchrobar, those in compressed form.

So your count of 52 bytes is a count of unpacked history.

 
Urain:

Are you sure that MQ bars M1 are stored unpacked?

Then how come there are delays in getting the history (small but there are), but reapplying (like to the cache) is faster.

Apparently in the history file bars are stored as changes from synchrobar, those in compressed form.

So your calculation about 52 bytes is a calculation of unpacked history.

I did not say anything about that, not only that - I'm sure there is packaging. The format is not declared to the public, and I did not try to "crack" it.

So everything is correct, I have described only unpacked format. It's taken from documentation.

 
MetaDriver:

I didn't say anything about that, not only that, I'm sure it's packed. The format is not publicly announced and I didn't try to "crack" it.

So that's right, I only have the unpacked format described. It's taken from the documentation.

That's right, but you're trying to show that the new format will be economical, while comparing unpacked current format and partially packaged new one.
 
Urain:
That's right, but you're trying to show that the new format will be economical, while comparing the current unpacked format and the partially packaged new one.
I'm not comparing economy, you're imagining it. Only informative. There is no economy, my unpacked format is bigger == 88 bytes {Open, High, Low, Close} and == 72 bytes {High, Low, Close}.
 
MetaDriver:
I'm not comparing economy, you imagined, only informativity. No economy, my unpacked format is more == 88 bytes {Open, High, Low, Close} and == 72 bytes {High, Low, Close}.

Well, you shouldn't have got the cancer by the stone. Would have suggested just doubling the informativeness instead of 52 bytes 88.

The same from the start hrenfx suggested.

 

Why is there a format with so much data at all? I.e. it is necessary to define the limitations of this tick filter (this format), when it does not differ the result from pure tick history.

At a glance, a simple tick filter HighBid+LowAsk is not much worse than the smart one (according to the amount of data).

Close-data is good only for multicurrency synchronization.

Maybe, it is easier to switch to a smaller timeframe instead of doing that. For example, S20 requires only 48 bytes for the same minute in HighBid+LowAsk format (maybe even less, if 4 bytes per price is more than enough). In my tester, I do everything via long int - very fast). And in terms of accuracy, 100% will beat your minute filter by 88 bytes.

P.S. Function Error(Freq, DataSize) = Full - Freq * DataSize tends to zero, when increasing Freq,

where Error is loss of information.

Full - full market information.

Freq * DataSize is a "multiplication" function: the amount of information that can be recovered with Freq quantisation frequency, and information content(DataSize) for each quantisation term.

 
hrenfx:

Why is there a format with so much data at all? I.e. it is necessary to define the limitations of this tick filter (this format), when it does not differ the result from pure tick history.

At a glance, a simple tick filter HighBid+LowAsk is not much worse than the smart one (according to the amount of data).

Close-data is good only for multicurrency synchronization.

Maybe, it is easier to switch to a smaller timeframe instead of doing that. For example, S20 requires only 48 bytes for the same minute in HighBid+LowAsk format (maybe even less, if 4 bytes per price is more than enough. In my tester, I do everything via long int - very fast). In terms of accuracy, it will beat your 88-byte minute filter by 100%.

Forum on trading, automated trading systems and strategy testing

An interesting topic for many: What's new in MetaTrader 4 and MQL4 - big changes are coming

Avals, 2013.08.11 15:43

If you do not know what to do with this, you may forget that it is a half-measure. We need a proper tick tester.

p.s. if it will be widespread and in the chips, then that's good)


 

Don't worry, there is bound to be (not everyone) an MT5 tester with as much accuracy as possible for the M1, with the Cloud option available in-house.

There is no way that the MT5 developers can exacerbate such a scenario.