Distribution of price increments - page 8
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
In this case we are talking about approximating a probability distribution. My research suggests that the first approximation, the probability distribution of price increments is a Student's t2-distribution with the scale factor different for different currency pairs and not equal to the standard deviation. I think this is very important information. The only thing left to do is to understand how to apply this knowledge.
How to apply it?
I don't know what distribution you got, I haven't dealt with it, but it is worth considering a method to ignore the artificially high volatility retail brokers have as they use it to destroy their clients' accounts with their own stops2. Do you think if I now start reading quotes at time intervals that satisfy the exponential law, will it do anything? Because logically. I will get a Markovian process, with some pseudo-states of quotes when there was no trading, but the current state of Bid and Ask is considered to be an incoming tick.
Could you please provide a link to the theoretical justification for your assertion? I'm having trouble applying the "obviousness operator" in this particular case o_O
if you read the ticks not by their actual time of arrival, but at intervals distributed according to an exponential law, then the pricing process becomes Markovian.
Something is not right here...
Could you provide a link to the theoretical justification for your statement? I'm having trouble applying the "obviousness operator" in this particular case o_O
Something is not right here...
Check it out for yourself. In the attached files is the data I am currently collecting. Column A is the Bid price, column B is the Ask price.
I'm waiting for someone who would unambiguously and confidently say "yes it's clear even to a child that this data must be interpreted so-and-so ...".
Congratulations to fans of probability theory!
Indeed, if one reads ticks not by their real arrival time, but at intervals distributed according to the exponential law, then the pricing process becomes Markovian. Moreover, the distribution of increments taken modulo from it is not clear, it becomes geometrical with p=0.5.
It remains unclear how to apply this knowledge in practice, but the fact that we are on the right track is obvious.
I have family holidays, so very briefly: from practice and according to statistics the process is divided into two phases (if you include news disturbances - three), where main distributions and principles are different. While tick rate (dV/dT) is relatively low, we see a clear and beautiful random walk, with the growth at some threshold, it all takes on an exponential growth. And if think carefully, it should be so, if think that the market is a distributed LMS (system of mass service) and ticks that are registered in the terminal are only a result, and only one of parts. We should check the methodology used to select the initial data - the most common mistake here (on this resource, and in general) is data sampling.
Because you hook TWO processes, you get excessive "fat tails" (this is just a fancy word and from another topic, just a fancy one)
I have a family holiday, so very briefly: from practice and statistics, the process is divided into two phases (three if you include the news excitement-panic), where the basic distributions and principles are different. While tick rate (dV/dT) is relatively low, we see a clear and beautiful random walk, with the growth at some threshold, it all takes on an exponential growth. And if think carefully, it should be so, if think that the market is a distributed LMS (system of mass service) and ticks that are registered in the terminal are only a result, and only one of parts. You should check the methodology by which the initial data was selected - here (on this resource, as well as in general) the most common mistake is data sampling.
Because you hook TWO processes, you get excessive "fat tails" (this is just a fancy word and from another topic, just a fancy word)
Wouldn't it be like reinventing the wheel here, like RSI in another thread... complicated scientific paths :) and trying to reinvent another market model
Wouldn't it be like reinventing the wheel here, like RSI in another thread... complicated scientific paths :) and trying to reinvent another market model
Good evening Maxim!
I'm sort of yes - new to Forex, but sort of with some background in physics and practice relating to technological processes. And there are other processes in technology, too...
I don't know anything about trading, so please don't judge harshly.
For me it is important to understand the current process - then I will be programming. If traders-programmers, for example, already use the exponential frequency instead of the real tick rate and get some unusual results - I will be glad to hear their opinion.
The fact that we "detach" from the real frequency of ticks and bring them to an exponential law, doesn't that give us any additional advantage?
It doesn't. In order to derive something it is necessary to make sure that external conditions are the same or at least similar, otherwise it is "the average temperature in a hospital. Not even an annual average." Well one of the measurement scales has changed.
i.e. p1. determine which conditions are significant
External conditions for currencies change significantly at least 2 times a day. The market before London opens and after NY opens are two different markets.
The fact that we're "decoupling" from the actual frequency of ticks and bringing them to an exponential law, doesn't that give us any added benefit?
Another small addition - just a "tick" is largely a product of the server you connect to. With small counts, we are mainly measuring the characteristics of a particular server's queue. The result of how it handled incoming requests on the stack, passed through the send queue, delayed and partly thinned.