From theory to practice - page 855

New comment
 
Aleksey Nikolayev:

Unfortunately, it is not that simple. There is the problem of "infinite drawdown". Any (however large) drawdown will be reached in infinite time with probability one.

so we won't be trading "infinite time" )
 
Maxim Kuznetsov:


PS. in most abstract "infinity games" there is a huge flaw - the criterion for losing is defined (reached 0) and there is no winning.

But do people set themselves a winning criterion?

 
Alexander_K:

Aaaaaa.... On the minutes.... Nah, I walked away from that - didn't find anything. Some crucial information is lost, can't say which, but something is lost forever - that's a fact.

A tick is a minute - it's how much the price moved in 1 minute (speed). A tick is the minimal change in price. 10 ticks - 10 price changes. you don't know how long they took. the drawback of ticks is that they don't take into account the intensity of trading.
 
multiplicator:
So we won't trade "infinite time" )

Of course we won't - after a big enough drawdown we will decide that the game has become a losing one. The point of the "infinite drawdown" statement is that it is inevitable.

 
multiplicator:
The drawback of ticks is that they don't show speed. a minute is how much price moved in 1 minute (speed). a tick is a minimum price change. 10 ticks - 10 price changes. you don't know how long they took. the drawback of ticks is that they don't take into account the intensity of trading.

Absolutely right.

Generally speaking, although the market is reasonably well described, under certain constraints, by models of stochastic processes, the problem of data acquisition and processing is cornerstone.

Recall that the classical way to observe the motion of a Brownian particle is to collect data at regular intervals - after 30 sec. (as Perrin did), or after 10 sec. (as they do now in chemistry labs).

However, the fundamental difference between Brownian motion and price motion is that molecules move continuously (continuous time), while prices have gaps in motion (discrete time).

So there has to be some balance between the chosen time interval of data reception and the possibility of losing important HIGH/LOW data.

A certain Bass, having eaten potatoes, recommends taking data every 1 second and whether it was a new tick or not.

But he, being under anesthesia from eating root vegetables, forgets that in this case the distribution of increments will have a "false" peak at zero due to pseudo-quotes and all the power of statistical studies goes to hell.

Thus, the most correct way is either to work with every tick, or a compromise solution - to read every 3-5 seconds, depending on the DC.

The problem of finding the Grail is certainly very complex and the method of data reception/processing is one of the key ones.

And not without reason, some neural-networkers, like Alexey the Younger or Warlock, keep these methods in absolute secrecy, and some people even pay for receiving tick quotes without brokerage filters. Can you imagine? It's crazy.

 
Alexander_K:....... and some pay money to accept tick quotes without DC filters. Can you imagine? It is crazy.

Traders don't pay for a quote, they pay to rent space on the quotation side.

Dealers pay for a quote so they don't win from him.

 
multiplicator:
The disadvantage of ticks is that they don't show speed. a minute is how much price has passed in 1 minute (speed). and a tick is the minimum change in price. 10 ticks are 10 price changes. You don't know how long they took.
How can you account for velocity if it is distributed exponentially, just like the increments themselves, it is a process without consequence. Is it possible to calculate the speed of a bus by the way you stand at a bus stop waiting for one, when the time gaps between the arrival of the next one are distributed exponentially? There is no dependency.
 
Novaja:
How can you account for speed if it is distributed exponentially, as well as the increments themselves, it is a process without an afterthought. Is it possible to calculate the speed of a bus by the way you stand at a bus stop waiting for one, when the time gaps between the arrival of the next one, are distributed exponentially? There is no relationship.

Oh, it's elementary.

Take a 15-minute bar for example and look at the terminal volume iVolume

and inside each tick iVolume=1, if there was any price change, otherwise 0 (zero)

velocity = path/time = volume/time

Therefore, reading ticks by exponent or once per second doesn't make sense physically.

The meaning is only the reading of ticks with changed price, i.e. we are interested in a single vector

Forum on trading, automated trading systems and trading strategies testing

Bugs and improvements to CopyTicks() and CopyTicksRange() after build 1485.

Alexey Volchanskiy, 2016.12.01 02:57

I think it's just a bug in the Web documentation, it's really empty in ME yet. Or the function is still in development. Second, you're requesting data from somewhere from 1970 and wonder why ticks from the last century aren't giving back ))!!! What are you smoking there?

That's how it works.

void OnStart()
{
    datetime dt1 = D'2016.11.28 00:00:00', dt2 = D'2016.11.30 00:00:00';
    MqlTick ticks[];
    ulong start, msc;
    //--- Замеряем время старта перед получением тиков
    start=GetMicrosecondCount();
    int copied = CopyTicksRange( _Symbol, ticks, COPY_TICKS_ALL, dt1*1000, dt2*1000);
//--- Рассчитаем, за сколько мс получена история
    msc=GetMicrosecondCount()-start;
    Print("copied=", copied, "   msc=", msc);
    return;
}

// вывод
2016.12.01 04:52:08.134 TestCopyTicks (EURUSD.m,M15)    copied=333081   msc=1294871
2016.12.01 04:52:16.877 TestCopyTicks (EURUSD.m,M15)    copied=333081   msc=318596

***

In this code, change COPY_TICKS_ALL into COPY_TICKS_INFO
Ticks will be loaded into the ticks array
 
The problem with minutes is that you can't calculate the absolute amount of increments within a bar. iVolume won't help, because the tick can be different.
 
Evgeniy Chumakov:
The problem with minute bars is that you can not count the absolute sum of increments inside the bar. iVolume will not help, because the tick may be different.

Do not get into the thick of it, because I was interested in the speed.

however a one minute bar does not form every minute

that's why I suggested M15.

in addition, the testing shows that the doll is almost harmless from H4 and above

1...848849850851852853854855856857858859860861862...1981
New comment
Reason: