Hareketli Ortalama (ve diğer göstergeler) değerlerinin ve hatanın karşılaştırılması - sayfa 2
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Burada mql'nin prensipte bununla hiçbir ilgisi yoktur. Soyut bir programlama dili alın. Verdiğim bu özel örnekte asıl sorun, aynı çubuktaki hareketlerin farkı değerlerinin eşit olmamasıdır (ilk hesaplamada 2e-16 ve ikinci hesaplamada tam olarak 0). Bu durumda genel olarak bu kavşak hiçbir şekilde belirlenemez. Mql'ye dönersek, normalleştirme sayıyı yuvarlamak anlamına gelir (daha doğrusu, C kat işlevine benzer şekilde belirli bir işaretten sonra tüm sayıları atmak, yalnızca ondalık noktadan sonra belirli bir işarete kadar). Peki hangi sayıya normalleştirileceğini nasıl belirlersiniz? Yanlış sayıyı seçerseniz, tüm değerler DAİMA tam olarak 0'a yuvarlanabilir. Bu nedenle, normalleştirme burada tehlikelidir ve genellikle sorunu çözmez.
Alexey Lebedev'in yazdıklarına gelince. Evet, bu doğrultuda düşünüyordum. Ancak her iki farkı 0'dan büyük veya 0'a eşit olarak karşılaştırırsak, yanlış bir sinyal alma olasılığı vardır (örneğin, komşu çubuklar arasında hareket ederken teorik olarak olası bir durum tamamen aynı değerlerle gelir). O zaman farklılıkları, olduğu gibi, işareti değiştirmez (kavşak yoktur), ancak kavşağa giden sinyal programlı olarak belirlenir. Önerdiğiniz gibi, büyüktür veya eşittir üzerine yalnızca bir karşılaştırma yapmak mümkündür. Ancak o zaman bütün sorun şu ki, bu durumda hesaplarken, ilk başta 0'a (2e-16) eşit olmayacak ve bir sonraki çubukta zaten tam olarak 0 olacak, ancak zaten katı bir karşılaştırma olacak.
Burada, farklı çubuklar üzerinde hesaplandığında aynı farkın neden aynı sonucu VERMİYOR olduğunu anlamak önemlidir??? Sonuç aynı olsaydı, sorunun her zaman katı olmayan bir karşılaştırma yaparak çözüleceği anlaşılıyordu.
Normalleştirirken - evet, belirli bir ondalık basamağa yuvarlama var. Belirli bir işaretten sonra tüm sayıları atmamak, yani yuvarlama.
Sizi tam olarak kastettiğiniz bağlamda anlarsam (hem ekranlı ilk gönderinizi hem de ikinci gönderiyi dikkate alıyorum), o zaman bu yöntemle çeşitli deneyler , yazdırırken DoubleToString'i hesaba katarak, sanırım hala yapabilirler sana yardım etmek. Rosomah'ın benden önce size bahsettiği şey budur.
Özellikle, herhangi bir görev için hangi rakamın normalleştirileceğini veya herhangi bir durumda normalleştirmenin gerekip gerekmediğini belirlemeye yardımcı olmak için (şüphe durumunda, programın daha sonra yapabileceği de dahil olmak üzere ilgili faktörlerin bir kombinasyonu nedeniyle başvuru veya başvuru yapılmaması). farklı DC'lerde uygulanabilir ve buna bağlı olarak elde edilen hesaplanan değerler farklılık gösterebilir).
Benim açımdan, çözülmekte olan görevlere bağlı olarak yanlış olarak kabul edilebilecek sinyallerin alınması tehlikesi, tam olarak normalizasyon uygulanmadığında (veya küçük bir değer nedeniyle ilk şekilde karşılaştırma yapılmadığında) olabilir. zarar vermez.
Ek olarak, yazdırma sırasında DoubleToString kullanılmazsa, aynı farkın veya aynı değerlerin farklı bir sonucunda hatalı korkular olabilir.
/* Her ihtimale karşı, double türündeki sayıları yazdırırken DoubleToString kullanmanız gerektiğini bir kez daha belirteceğim, çünkü yazdırırken sayısal bir değer metin değerine dönüştürülür. Buna göre, bu fonksiyon kullanılmazsa, gerçekte orada olmayan hatalar görünebilir.
Bu fonksiyondaki ondalık basamak sayısı, elbette, en az normalleştirilmiş değerler kadar ondalık basamakla. Ve normalleştirilmemiş olanlar için - daha fazlası. */
Büyük olasılıkla, iMA işlevinin hesaplanması optimize edilmiştir. İlk değer = toplam(kapat)/N, ikinci = MA+(yeni yakın eski kapanış)/N'nin önceki değeri.
Yani, aynı çubuk için genel durumda iMA, farklı çağrı sürelerinde iki hareketli ortalamanın farklı değerlerini verebilir mi?
Normalleştirirken - evet, belirli bir ondalık basamağa yuvarlama var. Belirli bir işaretten sonra tüm sayıları atmamak, yani yuvarlama.
Sizi tam olarak kastettiğiniz bağlamda anlarsam (hem ekranlı ilk gönderinizi hem de ikinci gönderiyi dikkate alıyorum), o zaman bu yöntemle çeşitli deneyler , yazdırırken DoubleToString'i hesaba katarak, sanırım hala yapabilirler sana yardım etmek.
Özellikle, herhangi bir görev için hangi rakamın normalleştirileceğini veya herhangi bir durumda normalleştirmenin gerekip gerekmediğini belirlemeye yardımcı olmak için (şüphe durumunda, programın daha sonra yapabileceği de dahil olmak üzere ilgili faktörlerin bir kombinasyonu nedeniyle başvuru veya başvuru yapılmaması). farklı DC'lerde uygulanabilir ve buna bağlı olarak elde edilen hesaplanan değerler farklılık gösterebilir).
Benim açımdan, çözülmekte olan görevlere bağlı olarak yanlış olarak kabul edilebilecek sinyallerin alınması tehlikesi, tam olarak normalizasyon uygulanmadığında (veya küçük bir değer nedeniyle ilk şekilde karşılaştırma yapılmadığında) olabilir. zarar vermez.
Ek olarak, yazdırma sırasında DoubleToString kullanılmazsa, aynı farkın veya aynı değerlerin farklı bir sonucunda hatalı korkular olabilir.
/* Her ihtimale karşı, double türündeki sayıları yazdırırken DoubleToString kullanmanız gerektiğini bir kez daha belirteceğim, çünkü yazdırırken sayısal bir değer metin değerine dönüştürülür. Buna göre bu fonksiyon kullanılmazsa hatalar görülebilir.
Bu fonksiyondaki ondalık basamak sayısı, elbette, en az normalleştirilmiş değerler kadar ondalık basamakla. Ve normalleştirilmemiş olanlar için - daha fazlası, daha fazlası. */
Son önemli işaretin yuvarlandığı açıktır. Ancak, örneğin, 0.000016 sayısı 5 basamakla normalleştirilirse, o zaman 0.00002 sayısı olacaktır ve daha az basamak varsa, o zaman her zaman 0'dır. Bu nedenle, belirli bir işarete yuvarlamak her zaman imkansızdır. MA değerleri yalnızca zaman çerçevesine değil, aynı zamanda çubukların kendisine de bağlı olacaktır. Bu nedenle, genel durumda, normalleştirme sırasında anlamlı basamak sayısının nasıl ayarlanacağı açık değildir.
Bu sonsuz küçük bir değerle ilgili, burada nasıl uygulanacağını anlayamıyorum. Gerçek bir sayıyı 0 ile karşılaştırmak için sonsuz küçük (hata) kullanılır. Farkı karşılaştırmam gerekiyor. Burada durum daha da kötü olabilir. Örneğin, bir çeşit epsilon koydum. Fark epsilon'dan daha büyük olduğunda, bunu olumlu buluyorum. Eksi epsilon'dan az olduğunda - negatif. Sınırlar dahilinde olduğunda - 0. Peki o zaman farkın işaretindeki değişiklik nasıl belirlenir? Örneğin, iki çubuk üzerindeki hareketli ortalamalar arasındaki fark epsilon dahilindedir. Ancak ilk durumda pozitiftir, ikincisinde negatiftir (yani, kesişme ZATEN olmuştur). Ve benimle, bir hatanın girişini dikkate alarak, farkın 0 olduğu kabul edilecektir. O zaman işareti değiştirme koşulu değiştirilmelidir. Geleneksel olarak, bu durumda iki MA'nın yukarıdan aşağıya kesişimiyle ilgili sinyal, tıpkı <0 (eski) ve >0 (oldu) ile =0 (önce) ve >0 (oldu) için bir karşılaştırma gibi olacaktır. . Ve en önemlisi, açıklanan durumda (farklı çağrılar için aynı noktadaki değerler farklı olduğunda), bu hatanın tanıtılması yardımcı olmaz. Bu fark her zaman öyle olabilir ki, hangi epsilon'u seçerseniz seçin, bir sinyal alamayacaksınız.
Son önemli işaretin yuvarlandığı açıktır. Ancak, örneğin, 0.000016 sayısı 5 basamakla normalleştirilirse, o zaman 0.00002 sayısı olacaktır ve daha az basamak varsa, o zaman her zaman 0'dır. Bu nedenle, belirli bir işarete yuvarlamak her zaman imkansızdır. MA değerleri yalnızca zaman çerçevesine değil, aynı zamanda çubukların kendisine de bağlı olacaktır. Bu nedenle, genel durumda, normalleştirme sırasında anlamlı basamak sayısının nasıl ayarlanacağı açık değildir.
Bu sonsuz küçük bir değerle ilgili, burada nasıl uygulanacağını anlayamıyorum. Gerçek bir sayıyı 0 ile karşılaştırmak için sonsuz küçük (hata) kullanılır. Farkı karşılaştırmam gerekiyor. Burada durum daha da kötü olabilir. Örneğin, bir çeşit epsilon koydum. Fark epsilon'dan daha büyük olduğunda, bunu olumlu buluyorum. Eksi epsilon'dan az olduğunda - negatif. Sınırlar dahilinde olduğunda - 0. Peki o zaman farkın işaretindeki değişiklik nasıl belirlenir? Örneğin, iki çubuk üzerindeki hareketli ortalamalar arasındaki fark epsilon dahilindedir. Ancak ilk durumda pozitiftir, ikincisinde negatiftir (yani, kesişme ZATEN olmuştur). Ve benimle, bir hatanın girişini dikkate alarak, farkın 0 olduğu kabul edilecektir. O zaman işareti değiştirme koşulu değiştirilmelidir. Geleneksel olarak, bu durumda iki MA'nın yukarıdan aşağıya kesişimiyle ilgili sinyal, tıpkı <0 (eski) ve >0 (oldu) ile =0 (önce) ve >0 (oldu) için bir karşılaştırma gibi olacaktır. . Ve en önemlisi, açıklanan durumda (farklı çağrılar için aynı noktadaki değerler farklı olduğunda), bu hatanın tanıtılması yardımcı olmaz. Bu fark her zaman öyle olabilir ki, hangi epsilon'u seçerseniz seçin, bir sinyal alamayacaksınız.
Herhangi bir özel problemi çözerken, ondalık anlamlı rakamların gösteriminin doğruluğundan da hareket edilebileceğini düşünüyorum. Double , Documentation'a göre 15 anlamlı basamağa sahiptir. Belgelere göre 0'dan 8'e normalleştirme sırasında hassas biçim . DoubleToString'in kendi hassas biçimleri vardır.
Ek olarak, iMA, benim açımdan, onunla birlikte kullanılan değerlerin farklı durumlarda ve farklı problemleri çözmek için kullanılacağı gerçeğini dikkate alan bir işlevdir. Buna göre, yardımı ile elde edilen değerler, belirli görevler de dahil olmak üzere farklı şekilde işlenebilir.
Ayrıca ortalamaların hesaplanması matematiksel bir hesaplamadır. Örneğin: (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333 ... Buna göre küçük yuvarlama veya genişletilmiş yuvarlama ile hesaplanan değerler, hesaplama uygulama seçeneklerini arttırır.
Bu arada, her ihtimale karşı, iMA yerine, diğer şeylerin yanı sıra terminalin standart teslimatına dahil olan MovingAverages kitaplığındaki işlevleri kullanabileceğinizi de belirteceğim. Veya bu kütüphanedekiler temelinde derlenen kendi işlevleri.
/*matematiksel hesaplamalar çift tip sayılarla çalışmanın özelliklerini gösterebilir */
Epsilonlar hakkında, geçiyorum.
P./S.: Yani, sanırım deneyler size yardımcı olabilir. Belirli görevler için pratik deneyler olmadan (büyük miktarda veri üzerinde) teorik akıl yürütme, hem kafa karıştırabilir hem de kabul edilebilir çözümlerden uzaklaşabilir.
Dina Paches :
...
Evet, kap. Mashki'yi üç yüz gün boyunca karşılaştırıyoruz ... Rakamlara normalleştirin ve endişelenmeyin ...
Değerleri doğrudan normalleştirmek mümkündür (fark - hiçbir durumda). Ancak yine, MA'yı karşılaştırmak için verilen referans kodunun değiştirilmesi gerekiyor ve her durumda katı olmayan bir eşitsizlik ortaya çıkıyor. Ayrıca, aynı çubuk üzerinde farklı MA değerleri sorunu, farklı zamanlarda hesaplandığında açık kalıyor. Bu daha fazla tekrarlanırsa, normalleştirmenin ve katı olmayan bir eşitsizliğin getirilmesinin bile sorunu tamamen çözeceği bir gerçek değildir. Ayrıca, bir çubuğun içinde hareket ederken iki kez kesişme durumu, kenelerle değil, yeni bir çubuğun açılmasıyla analiz ederseniz yakalanamaz. Deneyiminizi paylaşabilir misiniz, bu durumla nasıl başa çıkıyorsunuz?
Öncelikle normalize edilmiş iki değer arasındaki fark sonunda normalize edilmemiş bir değer verecektir. Normalleştirilmiş farkı kontrol etmeniz gerekir.
İkincisi, çubuğun içindeki geçişleri yakalamak istiyorsanız, sıfır ve ilk çubuklardaki tüm keneler için değerler alın - yakalayın ... anne-ağlama...
Bir çubuğun açılmasını test ediyorsanız, danışman yeni bir çubuğun açılışını açıkça izlemeli ve açıldıktan sonra kavşakları kontrol etmelidir.
İlk önce kendiniz karar verin - çubuğun açılışında veya her tikte işlem yapın, ardından kodu yazın. Ve buna göre, ayrıca test edin.
Dina, meleksi sabrına hayran kaldım...
Teşekkürler Artyom, ama ne yazık ki bunun da sınırları olabileceği ortaya çıktı.