FR H-uçuculuk - sayfa 40
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
Evet, tam da bunu umuyordum. Hala x ekseninin nasıl ölçekleneceğinin anlaşılması gerekiyor.
Peki ya Bars*TpB - Ticks , TpB - bar başına ortalama tick sayısını hesaplarsak? Daha doğrusu, orijindeki belirsizlikten kurtulmak için bu miktarın türevi. Eş hacimli çubuklar yapmaktan kaçınmak istiyorum.
Biraz daha kesin olarak pliz biraz anlamadı. Resimde eş hacim çubukları yok. Kırmızı çizgi, Y ve X eksenleri boyunca OLASI kenelerdir.Güçlü tutarsızlıklar görülebilir, ancak böyle görünmemesi gerekir (önde gelen + daha pürüzsüz bir görünüm, öyle görünüyor). Veya bir DC'nin alıntılarını hiç kullanmamanın, ancak kendiniz analiz etmenin (farklı kaynaklardan toplayın) daha iyi olduğu sonucuna varmalısınız. Ardından, tahminimizin DC'nin alıntılarına (filtrelerine) bağımlılığından uzaklaşıyoruz. Ne mümkün ve daha iyi.
Hayır Prival keneleri sadece paralı askerlik amaçlı kullanıyorsanız çalıştığınız DC'den almanız gerekir. Ve diğer DC'lerin işaretlerinin analizi, yalnızca DC'lerden bağımsız olan kararlı kalıpları aramak içindir.
2 Samimi: Tabii ki ilginç bir düşünce. Ama yine de, özellikle eş hacimli çubuklarla ilgili tüm olasılıkları tüketmediğimi düşünüyorum. İlginç olan şudur: çubuk sayısındaki bu kadar önemli bir yerel farklılığa rağmen, tüm tarihte fark minimumdur. Biraz önce H4 için resimler yayınladım. Sahip olduğum tüm geçmişi alırsak (1999'dan beri), o zaman H4 çubuklarının sayısı, eşdeğer olanların sayısından yaklaşık% 0.1 farklıydı.
Hayır, Prival , özellikle ticari bir amaç için tırnak kullanıyorsanız, çalıştığınız DC'den almanız gerekir. Ve diğer DC'lerin alıntılarının analizi, yalnızca DC'lerden bağımsız olan kararlı kalıpları aramak içindir.
Ve tam tersine, sadece ticari ((Fransız ve İtalyan tüccardan - ticari, bencil), aşırı sağduyu, hilekarlık; kişisel çıkar.) düşüncelerinden düşündüm ve DC alıntılarından uzaklaşmak gerekiyor. Diğer teklif sağlayıcıların verilerini kullanırsam, hareketin başlangıcını daha hızlı tahmin edeceğim (Diyelim ki DC filtresinin gecikmesi var), o zaman benim için daha karlı + örnekleme oranı daha yüksek, bu nedenle daha küçük dalgalanmaları takip edebiliyorum. Bu, büyük olmasa da bir istatistik avantajıdır, ancak biraz vardır ve biraz vardır, belki bir ekmek kabuğuna kazınır :-). Basitçe DC teklifleriyle anlaşma yapmak, evet, ondan kaçamazsınız, ancak analizde sadece alıntılarını kullanmak zorunda değilim.
Biraz daha kesin olarak pliz biraz anlamadı. Resimde eş hacim çubukları yok. Kırmızı çizgi, Y ve X eksenleri boyunca OLASI kenelerdir.Güçlü tutarsızlıklar görülebilir, ancak böyle görünmemesi gerekir (önde gelen + daha pürüzsüz bir görünüm, öyle görünüyor).
2 Matematik : Pekala, yukarıda son derece sınırlı hedefler peşinde koştuğumu yazmıştım. Bu arada, bir zamanlar, yaklaşık olarak aynı amaç için hacimce uzun ve kısa ortalamalar arasındaki farkı aldığımı hatırladım, ancak sonunda, uzun vadeli istikrarı düşündüğüm için kene hacmini kullanma girişimlerini bıraktım. bu bilgi kaynağı yetersiz. Periyodun büyümesiyle bar sayısındaki farkın azalmasına gelince, bunun nihayetinde günlük (seans) döngüselliğine döndüğünü düşünüyorum. Genel olarak, tarihi sıradan çubuklar şeklinde temsil ederek, zamansal bilgileri nispeten basit bir şekilde ve keneler şeklinde daha karmaşık bir şekilde yok ederiz. Ancak zaman aralığı ne kadar yüksek olursa, sonuç o kadar yakın görünüyor :). "Kene" dönüşümü hakkında sevmediğim şey, kısa zamanlarda, eğer genelliği hakkında (yani, herhangi bir an için tekdüzelik hakkında) konuşmak mümkünse, o zaman büyük zorluklarla olmasıdır. Ve uzun vadeli sonuçlarda, çalışmanıza bakılırsa, zaman ekseninin çok daha basit ve daha evrensel bir "çubuk" dönüşümüne yakın oldukları ortaya çıkıyor.
Ne inşa ettiğimi hiçbir şekilde açıklayamıyorum ve burada istedim ( 'İşletme süresindeki fiyatı yansıtan bir göstergeye ihtiyacımız var.' ), ama yanlış yazıyorum gibi görünüyor. Rakamlarla açıklamaya çalışacağım.
Diyelim ki her biri kendi t1, t2, t3, t4, t5 zamanında gelen 5 tik (5 sayı Y=Bid+(Ask-Bid)/2) var. (bunlar da sayılardır). MTPL'yi fiyatlara göre (bu Y koordinatıdır) ve MTPL'yi zamana göre (X koordinatı) hesaplarız. Bu noktayı ekrana koyun (X,Y). Bir sonraki kene gelir, işlem tekrarlanır, bir sonraki nokta çizilir. Sıradan Mashka, daha anlaşılır olabilir, sadece Fiyatın ortalaması değil, aynı zamanda Varış Zamanı da (sadece ortalamayı saymakla kalmayıp ÇUŞ'a göre daha kesin hale getirebilirsiniz).
Ve tablo üst üste bindirilmiş, ilki keneler (kırmızı) ile hesapladığım şey. 2. aynı süre için (mavi) alpari ile dakikadır. Hesaplamalarda hata yapmadıysam, grafiklerin başlangıcı ve bitişi tam olarak zaman içinde çakışmalıdır.
Farklı kaynaklardan almak zorunda kaldım çünkü. Alpari kene geçmişim yok, sadece bir dakikalık bir geçmişim var. Herhangi biri varsa, lütfen bana bildirin, hesaplamaları tekrarlayacağım. Aynı süre için 1 dakikalık 2 dosyaya ve ikinci onay işaretine ihtiyacımız var. (en az bir hafta).
ZY "Eşit hacimli tek tik :) çubuklarının" ne olduğunu hala çözemiyorum.
ZY "Eşit hacimli tek tik :) çubuklarının" ne olduğunu hala çözemiyorum.
Evet, programınızı hatırlıyorum. Ama aslında, 5 tikli çubuğun belirli bir örneği için eşdeğer hacimli bir çubuğun ortalama fiyatından bahsediyoruz. Bana öyle geliyor ki, bu temelde hiçbir şeyi değiştirmemeli (basit eş hacimli çubuklara kıyasla)
ZY "Eşit hacimli tek tik :) çubuklarının" ne olduğunu hala çözemiyorum.
Evet, programınızı hatırlıyorum. Ama aslında, 5 tikli çubuğun belirli bir örneği için eşdeğer hacimli bir çubuğun ortalama fiyatından bahsediyoruz. Bana öyle geliyor ki, bu temelde hiçbir şeyi değiştirmemeli (basit eş hacimli çubuklara kıyasla)
Ve bence var. Hatırlarsanız örnekleme oranı hakkında yazmıştım. Dakikada 1 değer alırsak, algılama süresi için çok zaman harcanır. Bu zikzak için de önemlidir. (varoluş süresini 300 dakika ile karşılaştırmamız iyi olur). Zigzagdan mümkün olduğunca çok şey kapmak için en kısa sürede (zamanında) dönüm noktasını belirlemek önemlidir.
Benimki gibi bir yapı ile veri alma sıklığı daha fazladır. Belki bu, algılama süresi açısından bir miktar avantaj sağlayacaktır + eğriler daha pürüzsüz + ileride görünüyor.
Düzenlemek. Çizimimde bir şeyler berbat olsa da, neyin ve nerede olduğunu anlayamıyorum. DC'ler arasında bu kadar büyük bir fark olmamalı (tabii bunlar mutfak değilse). İçlerinden biri uzun zaman önce ölmüş olmalıydı çünkü. saf tahkim.
Ve bence var. Hatırlarsanız örnekleme oranı hakkında yazmıştım. Dakikada 1 değer alırsak, algılama süresi için çok zaman harcanır. Bu zikzak için de önemlidir. (Varlık süresini 300 dakika ile karşılaştırmamız iyi olur). Zigzagdan mümkün olduğunca çok şey kapmak için en kısa sürede (zamanında) dönüm noktasını belirlemek önemlidir.
Genel olarak, gerçek zamanlıya katılıyorum, kendim de benzer bir yere bakıyorum. Ancak gerçekte, sonuç (örneğin aynı zikzak kırılması hakkında) az çok istatistiksel olarak güvence altına alınması gerektiğinden, kazanç umulduğu kadar büyük değildir. Dakika başı çalışmak iyidir çünkü iyi bir "tepki hızı"na sahip olarak, gerçeklere çok yakın koşullarda algoritmayı geçmiş üzerinde test edebiliriz.
Not Bu arada, bir zamanlar "sürgülü çubuk" kavramını kullandığımı hatırlıyorum :)
Not Bu arada, bir zamanlar "sürgülü çubuk" kavramını kullandığımı hatırlıyorum :)
Farklı kaynaklardan almak zorunda kaldım çünkü. Alpari kene geçmişim yok, sadece bir dakikalık bir geçmişim var. Herhangi biri varsa, lütfen bana bildirin, hesaplamaları tekrarlayacağım. Aynı süre için 1 dakikalık 2 dosyaya ve ikinci onay işaretine ihtiyacımız var. (en az bir hafta).
Tutmak. Alpari ile bu yıl ağustos ayı için dakika ve kene cinsinden euro-dolar.
Bu arada, hiç kimse EUR/GBP çifti için keneleri ve gerçek zamanlı olarak elde edilen sentetik seri kenelerini, EUR/JPY kotasyonlarının kenelerinin GBP/JPY'ye oranıyla karşılaştırmaya çalışmadı. EUR/GBP çiftinin dakika çubuklarının hacmi ortalama 5 sayım/dk ise, sentetik seri (SR) için bilgi varış hızı ortalama 20 sayı/dk iken, bu iki BP'nin mutlak değerleri çakışır. Bir noktaya kadar! Onlar. SR'yi analiz ederek, bize ADVANCE'de beklenen EUR/GBP fiyatını gösteren bir araç elde ederiz.