Prediction on "accelerator" and "fibo" - page 15
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
Great to work with a good tool! ... some of the predictions I sifted out as blatantly false and finished by hand. All in all it has turned out great!
I have made two entries on GBPJPY and EURUSD today:
GBPJPY M1 6.01.2010
EURUSD on 6.01.2010
2. the whole nastiness of MT is the lack of tick and volume work ... mt was made for sweepstakes, not for work ... i.e. server side was originally supposed to manage the default quote streams ... MT does not and will not exist as a platform from any serious broker or even more so bank, in countries where stock trading is developed, the provision of brokerage services requires a license with very strict requirements, so platforms like OEC, Ninja Trader, CQG ... and are designed, by default, without the ability to influence the flow of quotes towards the client ... that's why there are no restrictions on TP and SL ... no other idiotic restrictions ... there is only commission and a different approach to lending.
Nothing is going to change for the better at MT ... Metacquotes "tweak" their product to suit our "gamblers" and spending time perfecting a trade in this limited and, by default, created against you is rare "masochism" for gamblers, not working traders.
Ninja Trader has a built-in, in-house function for displaying price or volume bars ... they also have an application development environment ... there are volumes, how do you expect to draw conclusions about the forces involved in price moves without seeing the number of executed bids in trades ... how can you do bar analysis on a corrected tick history ...? How can you trust the oscillators, if a cow "licked" some ticks from a minute history and did everything to give you a wrong idea about the current market situation?
3. Don't write your own programming language and use third-party libraries to extend your functionality ... only if you have set yourself the task of reaching a scandal with another "kitchen".
I think about the platforms is not necessary to make religious wars, especially here, especially since MT de facto at the moment is the easiest and most convenient platform to start. (IMHO) Maybe there are others, but I have not found a Russian-speaking community like this. But soon it may be corrected, because, as they say, one of "our thieves" will take Ninja Trader and CQG and possibly develop the topic of programming for these platforms, though I doubt very much that this will make them better at delivering meat contracts to their customers, so it is unlikely the risks of supplying poor-quality information will change from the platform.
We should take mullions of green and go to Chicago, raise cows W)))
4. I understand that the speed is calculated with the previous bar ... that's what I don't like!!! ... imagine that Bar = 2, and the first bar is above or below "zero" and "second"??? such a speedometer can be safely given to lecturers for training "traders" ... but in a serious Trading System it should not be put ... that's why I suggest recalculating it by comparing it to the last formed top ZZ... and perform all calculations on minutes, as on minimal - available to us in MT price information ... Pay attention that when movement is measured and calm, the forecast is excellent, but as soon as the rate of price increase (trend development) is higher than average, even the "accelerator" has no time to return to zero ... there are several solutions:
a. Consider projections only on TFs older than M5, and use filtered "minutes" for speed and acceleration calculations ...
b....to use this now classic method - Bar0 is less (or more) than Bar1 --- there will be a lot of false predictions
в. ...
Now to the point.
Speed = distance / time and to calculate it from ZZ (as you suggested) is quite logical :
Distance = Value(LowestZZ or HighestZZ) - Value(estimated bar);
time = NoBar(LowestZZZ or HighestZZZ) - NoBar(design bar)
and acceleration would already be correctly counted as :
Acceleration = Velocity(design bar) - Velocity(design bar+1)
Я думаю по поводу платформ не стоит устраивать религиозных войн, тем более здесь, тем более, что МТ де-факто на данный момент является наиболее легкой и удобной платформой для старта.(Сугубо ИМХО) Может есть и другие, но я не нашел подобного русскоязычного сообщества, как здесь. Но скоро может все исправится, ибо, как пишут, один из "наших наперсточников" возьмет на вооружение Ninja Trader и CQG и возможно разовьет тему программирования под эти платформы, правда я сильно сомневаюсь, что от этого они начнут лучше поставлять мясные контракты своим клиентам, поэтому вряд ли риски от поставки некачественной информации изменятся от платформы.
Надо брать мульоны зелени и ехать в Чикаго, растить коров Ж))
So I have not communicated my point well. That's my flaw and I won't revisit it.
Quotes in Ninja Trader come from ZenFire, not from broker ...
By the time Broko develops the programming for Ninja and CQG I will be very old.
I have stated the basic idea and reasons also, I don't take part in arguments ... If you have an idea of how to improve the forecast, you are welcome! ...
А теперь по делу.
Скорость = расстояние / время и рассчитывать ее от ZZ (как вы предложили) вполне логично :
расстояние = Значение(LowestZZ или HighestZZ) - Значение(расчетного бара);
время = НомерБара(LowestZZ или HighestZZ) - НомерБара(расчетного бара)
а ускорение уже будет правильно считать как :
Ускорение = Скорость(расчетного бара) - Скорость(расчетного бара+1)
Yes, I totally agree!
A big request for nen to finalise the indicator :
1. Make price calculation for acceleration as above:
Скорость = расстояние / время и рассчитывать ее от ZZ (как вы предложили) вполне логично :
distance = Price(calculated bar) - Price(LowestZZZ or HighestZZZ); (swapped the places because I mixed up from the beginning)
time = Bar number(LowestZZZ or HighestZZZ) - Bar number(settlement bar)
Acceleration = Speed (estimated bar) - Speed (estimated bar+1)
2. Add (H+L+C+C)/4 to the definition of the initial price to be calculated
And most desirable to make it possible to view on the history of all arising situations that meet the conditions, even where the ZZ knee was redrawn (if there were conditions for the creation of Fiba)
Yes, totally agree!
So the velocity is relative to the zigzag extremum and the acceleration is relative to the adjacent bar? Right?
There is a question from colleagues:
wouldn't it be more logical for us to move the calculations to minute history altogether?! ... That is, we are mostly interested in forecasts older than M5, for me it's always been interesting in 5 and 15 min...
what to do - when you switch to a higher TF, change smoothing (filtering) for the minute values of speed and acceleration ... Since formation of bars in the older timeframe is done by OHLC, filtering (smoothing) when getting a calculated point of previous bars for comparison, appears to be too rough ... In fact, looking through the forecasts of all available TFs I came to a conclusion that settings from one TF are not appropriate for the others, as I understand it's all caused by a coarse bar structure ... I think it's more logical to use the smallest history unit - M1 bar and without switching to older TFs (over M30) build the forecasts on the basis of minute bars using only tougher filtering.
In fact the gradation itself M1, M5, M15 ... is farfetched ... I don't think it's the only way to make the forecasts for a long time.