"Hızlandırıcı" ve "fibo" ile ilgili tahmin - sayfa 15
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
İyi bir aletle çalışmak harika! ... bazı tahminleri açıkça yanlış olarak eliyorum ve elle bitiriyorum. Ama genel olarak harika çıktı!
Bugün GBPJPY ve EURUSD'ye iki giriş yaptım:
GBPJPY M1 01/06/2010
01/06/2010 itibariyle EURUSD
2. MT'nin tüm pisliği, keneler ve hacimlerle çalışma eksikliğinde yatıyor ... MT, çekilişler için yapıldı, iş için değil ... yani, başlangıçta sunucu tarafının teklif akışını yöneteceği varsayıldı. varsayılan olarak ... MT, borsa ticaretinin geliştirildiği ülkelerde, bir banka şöyle dursun, hiçbir ciddi brokerin platformları gibi değildir ve olmayacaktır, aracılık hizmetlerinin sağlanması çok katı gereksinimleri olan bir lisans gerektirir, bu nedenle OEC gibi platformlar, Ninja Trader, CQG ... varsayılan olarak, müşteriye yönelik teklif akışını etkileme yeteneği olmadan geliştirildi ... bu nedenle, TP ve SL'de herhangi bir kısıtlama yok ... başka aptalca kısıtlama yok .. Sadece bir komisyon ve borç vermede farklı bir yaklaşım var.
MT'de hiçbir şey daha iyisi için değişmeyecek... Meta alıntılar, "yüksükçülerimiz" için ürünlerini "keskinleştirir" ve bu sınırlı ve varsayılan olarak size karşı oluşturulan ortamda ticareti geliştirmek için zaman harcar, bu kumarbazların nadir görülen bir "mazoşizmidir" ve işsiz tüccarlar.
Ninja Trader, fiyatlara veya hacimlere göre aralık çubuklarını görüntülemek için yerleşik, düzenli bir işleve sahiptir ... ayrıca uygulama geliştirmek için bir ortamları vardır ... ayrıca hacimleri vardır, ama beni nasıl affedin, hakkında sonuçlar çıkarmayı düşünüyor musunuz? Tamamlanan tekliflerin miktarını görmeden fiyat hareketine dahil olan güçler? ... bir düzeltme kene geçmişi üzerinde nasıl çubuk analizi yapabilirsiniz? ... eğer bir inek bir dakika geçmişinden bazı keneleri yaladıysa ve piyasanın mevcut durumu hakkında size yanlış bir fikir vermek için her şeyi yaptıysa, osilatörlere nasıl güvenebilirsiniz?
3. Kendi programlama dilinizi yazmamalı ve işlevselliği üçüncü taraf kütüphanelerle genişletmemelisiniz... ancak kendinize başka bir "mutfak" ile bir skandala ulaşma görevini verirseniz.
Bence platformlar hakkında din savaşları başlatmamalısın hele hele burada hele hele MT şu an için fiilen en kolay ve en uygun platform olduğu için.(Tamamen IMHO) Başkaları da olabilir ama ben benzerini bulamadım. Buradaki gibi Rusça konuşan topluluklar. Ancak yakında her şey düzeltilebilir, çünkü dedikleri gibi, "yüksük yapımcılarımızdan" biri Ninja Trader ve CQG'yi benimseyecek ve muhtemelen bu platformlar için programlama konusunu geliştirecek, ancak bunun onları daha iyi et tedarik edeceğinden kesinlikle şüpheliyim. bu nedenle, düşük kaliteli bilgi tedarikinden kaynaklanan risklerin platformdan platforma değişmesi olası değildir.
Milyonlarca yeşillik alıp Chicago'ya gitmemiz, inek yetiştirmemiz gerekiyor F))
4. Hız hesaplamasının önceki çubukla yapıldığını anlıyorum ... bana uymayan bu!!! ... Bar = 2 olduğunu ve ilk çubuğun "sıfır" ve "ikinci"nin üstünde veya altında olduğunu hayal edin??? böyle bir hız göstergesi "tüccarlar" eğitimi için öğretim görevlilerine güvenle verilebilir ... . ve tüm hesaplamaları MT'de bizim için mevcut olan minimum fiyat bilgisinde olduğu gibi dakikalar içinde yapın ... Hareket ölçüldüğünde ve sakin olduğunda, fiyat artış hızı (trend gelişimi) için tahminin mükemmel olduğunu lütfen unutmayın. ortalamanın üzerinde, "hızlandırıcının" bile sıfıra dönme zamanı yok... burada birkaç çözüm var:
a. sadece M5'ten daha eski zaman dilimleri için tahminleri dikkate alın ve hız ve ivmeyi hesaplamak için filtrelenmiş "dakikaları" kullanın ...
b. zaten klasik olan yöntemi kullanın - Bar0, Bar1'den daha az (veya daha fazla) --- bir sürü yanlış tahmin olacak
içinde. ...
Ve şimdi konuya.
Hız \u003d mesafe / zaman ve bunu ZZ'den hesaplamak oldukça mantıklı (önerdiğiniz gibi):
mesafe = Değer(DüşükZZ veya En YüksekZZ) - Değer(hesaplanan çubuk);
time = BarNumber(LowestZZ veya HighestZZ) - BarNumber(tahmini çubuk)
ve ivme zaten şu şekilde doğru bir şekilde hesaplanacaktır:
İvme = Hız(hesaplanan bar) - Hız(hesaplanan bar+1)
Bence platformlar hakkında din savaşları başlatmamalısın hele hele burada hele hele MT şu an için fiilen en kolay ve en uygun platform olduğu için.(Tamamen IMHO) Başkaları da olabilir ama ben benzerini bulamadım. Buradaki gibi Rusça konuşan topluluklar. Ancak yakında her şey düzeltilebilir, çünkü dedikleri gibi, "yüksük yapımcılarımızdan" biri Ninja Trader ve CQG'yi benimseyecek ve muhtemelen bu platformlar için programlama konusunu geliştirecek, ancak bunun onları daha iyi et tedarik edeceğinden kesinlikle şüpheliyim. bu nedenle, düşük kaliteli bilgi tedarikinden kaynaklanan risklerin platformdan platforma değişmesi olası değildir.
Milyonlarca yeşillik alıp Chicago'ya gitmemiz, inek yetiştirmemiz gerekiyor F))
Yani amacımı yanlış anladım. Bu benim eksikliğim ve bu konuya geri dönmeyeceğim.
Ninja Trader'daki alıntılar bir komisyoncu değil, ZenFire'dan gelir...
Broco, Ninja ve CQG programlamayı geliştirdiğinde ben çok yaşlanacağım.
Ana fikri ve nedenlerini de belirttim, anlaşmazlıklara katılmıyorum ... tahminin nasıl iyileştirileceğine dair fikirler var - rica ederim! ...
Ve şimdi konuya.
Hız \u003d mesafe / zaman ve bunu ZZ'den hesaplamak oldukça mantıklı (önerdiğiniz gibi):
mesafe = Değer(DüşükZZ veya En YüksekZZ) - Değer(hesaplanan çubuk);
time = BarNumber(LowestZZ veya HighestZZ) - BarNumber(tahmini çubuk)
ve ivme zaten şu şekilde doğru bir şekilde hesaplanacaktır:
İvme = Hız(hesaplanan bar) - Hız(hesaplanan bar+1)
Evet, kesinlikle katılıyorum!
Göstergeyi tamamlamak için büyük bir istek:
1. Hızlanma için yukarıda belirtildiği gibi bir fiyat hesaplaması yapın:
Скорость = расстояние / время и рассчитывать ее от ZZ (как вы предложили) вполне логично :
mesafe = Fiyat(yerleşim çubuğu) - Fiyat(DüşükZZ veya En YüksekZZ); (baştan karıştırdığım için yer değiştirdim)
time = BarNumber(LowestZZ veya HighestZZ) - BarNumber(tahmini çubuk)
İvme = Hız(hesaplanan bar) - Hız(hesaplanan bar+1)
2. Hesaplama için başlangıç fiyatının tanımına ekleyin (H+L+C+C)/4
3. Ve en çok arzu edilen şey, ZZ dizinin yeniden çizildiği yerlerde bile (FIBA'yı kurmak için koşullar varsa) koşulları karşılayan tüm durumların geçmişini görmeyi mümkün kılmaktır.
Evet, kesinlikle katılıyorum!
Yani hız zikzak uç noktasına göre hesaplanır ve ivme komşu çubuğa göre mi? Böyle?
Bir meslektaşımızın sorusu:
hesabı genel olarak bir dakikalık tarihe aktarmamız daha mantıklı olmaz mı?! ...yani daha çok M5'ten daha eski tahminlerle ilgileniyoruz, benim için 5 ve 15 dakikalık tahminler her zaman ilgimi çekmiştir...
ne yapmalı - eski zaman dilimine geçerken, hız ve ivmenin dakika değerleri için yumuşatmayı (filtrelemeyi) değiştirin ... çünkü eski zaman diliminin çubuklarının oluşumu OHLC'ye göre gerçekleştiğinden, filtreleme (yumuşatma) karşılaştırma için önceki çubukların hesaplanan noktasını elde ederken çok kaba olduğu ortaya çıkıyor ... aslında, mevcut tüm zaman dilimleri için tahminlere bakarak, bir zaman dilimindeki ayarların diğerleri için uygun olmadığı sonucuna vardım , anladığım kadarıyla, tüm bunlara kaba bir çubuk yapısından kaynaklanıyor ... bence, minimum tarihsel birim - M1 çubuğu kullanmak ve daha yüksek zaman dilimlerine (M30'un üzerinde) geçmeden, tahminleri temel alarak oluşturmak daha mantıklı dakikalar sadece daha katı filtreleme kullanarak.
Ne de olsa, M1, M5, M15'in derecelendirilmesi kendi içinde ... çok zorlandı ... en azından BAR gibi bir filtrenin basitleştirilmesi nedeniyle tahminlerin çarpıtılması bence açık.