Hareketli Ortalama (ve diğer göstergeler) değerlerinin ve hatanın karşılaştırılması - sayfa 4
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
Tabii ki tavsiyen için teşekkürler, ama ben kendim yardım okuyabilirim. Ve yine, hesaplamalı matematik belirli bir programlama diline bağlı değildir. Burada sadece uğraşmanız gereken hesaplama hataları var.
Sadece yardımı nasıl okuyacağınızı değil, aynı zamanda anlıyorsanız, o zaman aşağılayıcı bir ruhla normalleşme ve uygulama olasılıkları hakkında inatla konuşmaya devam ederek bilinçli demagoji yürütüyorsunuz. Kullanımının tehlikeleri hakkında bilinçli demagoji dahil.
Ve zeki değilim, ama karşı örnekler veriyorum (en sevdiğiniz normalleştirme dahil).
Demagoji vardı. Normalleşme konusunda karşı örnek yoktu.
Birinin onu doğru kullanmayabileceği gerçeğinin dışında.
Yani epsilonlar yanlış kullanılabilir. Evet ve zaten demagojiden bahsetmiştim.
P./S.: Gönderi normalleşme ile ilgili, bu yüzden hareketli ortalamalardan bahsetmiyorum.
Evet ve MA kullanan danışmanlara göre Artyom'un zor anlarınızda size benden daha iyi yardımcı olabileceğini düşünüyorum.
Her işarette kavşakları arayın. Sorun ne?
İki gerçek sayıyı karşılaştırırken hiçbir şeyi normalleştirmeniz gerekmez.
Sayılar gerçekten eşitse, aynı şekilde bellekte saklanırlar . Tam da bu özelliğinden dolayı bilgisayarların varlığı mümkündür.
Buradan if(a<b) veya if(a==b) formunun karşılaştırmalarının her durumda doğru olduğu ve normalleştirmenin gerekli olmadığı sonucu çıkar.
Araştırmacının meraklı zihni yine de bu kurala aykırı bulursa, ya makinesi çalışmıyordur ya da zihni. İkide bir.
Tabii ki, en azından bazen referansları ve belgeleri okumanız gerekir (bunlar da bizim gibi insansılar tarafından yazılmıştır), ancak aynı zamanda kendi sağlam muhakemenizin olması gerekir.
Sadece yardımı nasıl okuyacağınızı değil, aynı zamanda anlıyorsanız, o zaman aşağılayıcı bir ruhla normalleşme ve uygulama olasılıkları hakkında inatla konuşmaya devam ederek bilinçli demagoji yürütüyorsunuz. Kullanımının tehlikeleri hakkında bilinçli demagoji dahil.
Demagoji vardı. Normalleşme konusunda karşı örnek yoktu.
Birinin onu doğru kullanmayabileceği gerçeğinin dışında.
Yani epsilonlar yanlış kullanılabilir. Evet ve zaten demagojiden bahsetmiştim.
Karşı örnekler vardı (her halükarda normalleşme açısından burada dile getirildiği gibi farklılıklar da var). Tekrar ediyorum: normalleştirme, karmaşıklıklara dalmak istemeyenler için en kolay yoldur. Belgeleri okudu ve tüm bunlara kesinlikle inanıyor. Tekrar ediyorum, hesaplamalı matematik çerçevesinde programlama dilinin önemi yoktur. Yardımda bu tür tavsiyeler yazılmışsa, bu bunun doğru olduğu anlamına gelmez (aksi takdirde çok sevmediğiniz hesaplamalı matematik ve epsilon sorunları olmazdı). Çitin üzerinde de pek çok şey yazılıdır, ancak bu, bunun nihai gerçek olduğu anlamına gelmez. Yardım seçeneğinden memnunsunuz, bunu yapmaya hakkınız var. Ama bu senin kişisel tercihin. Ve bu, burada aktarmaya çalıştığım tüm sorunları çözdüğü anlamına gelmez. Ve demagojiyi anlamak istemediğiniz bir şey olarak düşünmek (yine bu sizin hakkınız), bunun demagojinin kendisi olduğu anlamına gelmez. Burada hayatın anlamı hakkında retorik sorular sormuyorum (cevapları sadece demagojidir), sadece henüz karşılaşmadığım şeyi anlamaya çalışıyorum. Tekrar ediyorum, hesap yapmadığınızda değerler hep aynı olsa ne güzel olurdu. Orada aynı hesaplamalı matematikten bir şeyler çizmek mümkün olurdu. Ancak değerler de farklı olduğunda - en azından burada bir mega-guru olun - evrensel bir algoritma hayal edemezsiniz.
Ayrıca, robot keneler üzerinde çalışmazsa, o zaman bir çubuğun içinde çoklu bir kesişme elde etmenin temelde imkansız olduğunu anladığımdan emin olmak istiyorum, değil mi? Bu zaten tamamen mql'nin inceliklerine atfedilebilir.
PS Birisiyle temelsizce tartışmaya çalışmıyorum, kendimi her zaman sağcı bir dahi olarak görmüyorum. Akıllı olmaya ve hiçbir şeyi düzgün okumadan bir şeyler yazmaya çalıştıklarında hoşuma gitmiyor. Kişisel olarak sizin için hiç geçerli değil. Bu konudaki yardımlarınız ve düşünceleriniz için teşekkür ederim. Ama yine de, IMHO, belgelerin sadece bir bakış açısında ısrar ettiğinizde (ki buna kesinlikle inanıyorsunuz ve herhangi bir alternatif görüş ve örneği kabul etmiyorsunuz) ve epsilonları sevmiyorsanız, sabır hakkında bir şeyler yazmanız yanlış. Umarım Artyom daha önce dipnotta yazdıklarımı anlar. Cevaplarınız için hepinize teşekkür ederim ve bir yerde biraz sinirlendiysem kusura bakmayın.
Belirli bir ondalık basamağa PPS Normalleştirme, aslında, aynı işaretin sırasına göre epsilon girişinin bir analogudur.
PPPS Böyle hararetli bir tartışmamız olursa, bu konudaki deneyiminizi paylaşırsanız çok minnettar olurum, çünkü uygun cevaplar alamadım (özellikle beni ilgilendiren 2. ve 3. noktalara). Halihazırda birçok forumdan geçmiş olmama rağmen, pratikte evet, 2. noktanın imkansız olduğu sonucuna vardım. Burada, mql geliştiricileri bunu düşünebilir ve daha fazla esneklik sağlayabilirdi, çünkü çok elverişsizdir (başka herhangi bir programlama dilinde program arayüzünü dinamik olarak değiştirmek mümkündür, ancak burada olmadığı ortaya çıkıyor ((())
Karşı örnekler vardı (her halükarda normalleşme açısından burada dile getirildiği gibi farklılıklar da var). Tekrar ediyorum: normalleştirme, karmaşıklıklara dalmak istemeyenler için en kolay yoldur. Belgeleri okudu ve tüm bunlara kesinlikle inanıyor. Tekrar ediyorum, hesaplamalı matematik çerçevesinde programlama dilinin önemi yoktur. Yardımda bu tür tavsiyeler yazılmışsa, bu bunun doğru olduğu anlamına gelmez (aksi takdirde çok sevmediğiniz hesaplamalı matematik ve epsilon sorunları olmazdı). Çitin üzerinde de pek çok şey yazılıdır, ancak bu, bunun nihai gerçek olduğu anlamına gelmez. Yardım seçeneğinden memnunsunuz, bunu yapmaya hakkınız var. Ama bu senin kişisel tercihin. Ve bu, burada aktarmaya çalıştığım tüm sorunları çözdüğü anlamına gelmez. Ve demagojiyi anlamak istemediğiniz bir şey olarak düşünmek (yine bu sizin hakkınız), bunun demagojinin kendisi olduğu anlamına gelmez. Burada hayatın anlamı hakkında retorik sorular sormuyorum (cevapları sadece demagojidir), sadece henüz karşılaşmadığım şeyi anlamaya çalışıyorum. Tekrar ediyorum, hesap yapmadığınızda değerler hep aynı olsa ne güzel olurdu. Orada aynı hesaplamalı matematikten bir şeyler çıkarmak mümkün olabilirdi. Ancak değerler de farklı olduğunda - en azından burada bir mega-guru olun - evrensel bir algoritma hayal edemezsiniz.
Ayrıca, robot keneler üzerinde çalışmazsa, o zaman bir çubuğun içinde çoklu bir kesişme elde etmenin temelde imkansız olduğunu anladığımdan emin olmak istiyorum, değil mi? Bu zaten tamamen mql'nin inceliklerine atfedilebilir.
PS Birisiyle temelsizce tartışmaya çalışmıyorum, kendimi her zaman sağcı bir dahi olarak görmüyorum. Sadece akıllı olmaya ve hiçbir şeyi düzgün okumadan bir şeyler yazmaya çalıştıklarında hoşuma gitmiyor. Kişisel olarak sizin için hiç geçerli değil. Bu konudaki yardımlarınız ve düşünceleriniz için teşekkür ederim. Ama yine de, IMHO, belgelerin sadece bir bakış açısında ısrar ettiğinizde (ki buna kesinlikle inanıyorsunuz ve herhangi bir alternatif görüş ve örneği kabul etmiyorsunuz) ve epsilonları sevmiyorsanız, sabır hakkında bir şeyler yazmanız yanlış. Umarım Artyom daha önce dipnotta yazdıklarımı anlar. Cevaplarınız için hepinize teşekkür ederim ve bir yerde biraz sinirlendiysem kusura bakmayın.
Belirli bir ondalık basamağa PPS Normalleştirme, aslında, aynı işaretin sırasına göre epsilon girişinin bir analogudur.
PPPS Böyle hararetli bir tartışmamız olursa, bu konudaki deneyiminizi paylaşırsanız çok minnettar olurum, çünkü uygun cevaplar alamadım (özellikle beni ilgilendiren 2. ve 3. noktalara). Halihazırda birçok forumdan geçmiş olmama rağmen, pratikte evet, 2. noktanın imkansız olduğu sonucuna vardım. Burada, mql geliştiricileri bunu düşünebilir ve daha fazla esneklik sağlayabilirdi, çünkü bu çok elverişsizdir (başka herhangi bir programlama dilinde program arayüzünü dinamik olarak değiştirmek mümkündür, ancak burada göründüğü gibi değil ((())
Benim için, double türündeki sayıları karşılaştırırken NormalizeDouble işlevini kullanarak veri dönüştürmenin kullanılması, kodda belirli koşullar reçete edilirken program koşullarının tam olarak nerede ve nasıl amaçlandığı şekilde tetiklenmesini sağlamak için Belgelerde belirtilen iki yoldan biridir. Daha önce bahsettiğim şey buydu. Buna göre, bu sadece herhangi bir hatanın ortadan kaldırılması değildir. Bu ve verileri herhangi bir koşulu yerine getirmek için dönüştürmek için iyi düşünülmüş çeşitli seçenekler.
Size bundan bahsetmiştim ve bundan yeni öğrenmeye başladığınız programlama dilindeki kişisel pratik deneyimime dayanarak konuşuyorum. Bu nedenle ve bu başlıkta defalarca önerilen bu pratik yöntemi kullanın.
Geçerken, kısmen sizinle aynı fikirde olduğumu söyleyeceğim, bu işlevi kullanarak normalleştirmenin gerçek türden verileri dönüştürmek açısından herhangi bir görev için en kolay yol olabileceğini tartışmayacağım.
Ancak, gerçek türdeki verileri dönüştürürken Belgelerde önerilen iki yöntemden hangisinin uygulanacağını herkes kendisi seçer.
Ve bu yöntemlerden herhangi birinin seçimi, bir kişinin gerekli incelikleri bulmaya çalışan veya denemeyenlerden biri olduğu gerçeğinin tanımlayıcı kriterleri için geçerli değildir.
Epsilonları sevmiyorum, benim açımdan hiçbir kelime yoktu. Herhangi bir yöntem kullanmamak mutlaka sevmek/sevmemek değildir. Evet ve ikisinin sadece ikinci yönteminin kullanımı konusunda ısrar etmedi.
Çift tip sayılarla çalışma özelliklerinin pratik uygulaması açısından gerçek sözlerim:
P./S.: Öyle oldu ki, Dokümantasyondaki ilk yöntemin, kural olarak kendim için çözdüğüm görevler de dahil olmak üzere benim için daha az uygun olduğu ortaya çıktı. Buna göre, ilk yöntemde çok fazla birikmiş deneyimim yok.
Ancak ikinci yöntemi uygularken (yani, koşullu operatörün ifadesinde iki gerçek sayının normalleştirilmiş farkını sıfır değeriyle karşılaştırırken ), açık bir şekilde herhangi bir sorun ortaya çıkmadı.
Ancak normalleştirilmemiş sayıların karşılaştırmalarını yaptıysam (burada demek istediğim, ilk yöntemi kullanmadan da dahil), o zaman evet, çift sayıların karşılaştırmalarına dayalı koşulların yanlış tetiklendiğini ortaya çıkardı.
Ayrıca, bu açıklama aşağıdakilere yol açtı :
P./S.: Aynı zamanda, her ihtimale karşı, burada listelenen ikisinden ilk şekilde gerçek sayıları karşılaştırmayı, sayıların farkını küçük bir değerle karşılaştırarak, yapabileceğimi bir kez daha açıklığa kavuşturacağım. Karşılaştırma seviyesini ayarlamanız gerektiğinde normalleştirmeyi kullanmaktan daha kötü bir isim (ikinci yöntemin benim için daha uygun olduğu ortaya çıktığından, birincisi pratik uygulama için kendim için daha ayrıntılı olarak düşünmedi).
Yani, çift veriyi dönüştürürken normalleştirme açısından ilk yönteme ihtiyacım yoktu. Çeşitli sorunları çözerken (yalnızca karşılaştırma yaparken değil) NormalizeDouble işlevini kullanmanın benim için rahatlığı nedeniyle.
Site büyük bir birikmiş bilgi tabanına sahiptir.
İnsanlar MQL4 dilini kullanarak çeşitli karmaşıklık düzeylerindeki sorunları çözdüler ve çözüyorlar.
MQL4 dili MQL5'e yaklaştırıldıktan sonra, MQL5'in olanakları daha da arttı.
Bu programlama dilini daha iyi tanımanız ve buradaki sitelerde biriken bilgi birikimini ihmal etmemeniz gerektiğini düşünüyorum. Pratik uygulama deneyiminizi biriktirin. Ve ancak o zaman, bu programlama dilindeki herhangi bir uygulama ve yetenekleri açısından bir şey güvenle beyan edilebilir.
Gerçek şu ki, farklı bir TK'm var) Ve yine, kenelerde hangi sorunların olduğunu zaten yazdım. Grafikte kesişimi görmüyorsa, müşteriye robotun neden anlaşmaya girdiğini hiçbir şekilde açıklamayacaksınız.
Her bir kene üzerindeki sıfır ve ilk çubuklardaki MA değerlerini alın - o zaman ve ancak o zaman, sıfır çubuğunda MA geçitlerini bulabileceksiniz. Sıfırın açılması sırasında onları ilk çubuktan alırsınız - ve orada MA'ların değerleri, oluşum anında değil, ilk çubuğun kapatıldığı andaki değerlerdir. MA'ların değerlerini sadece geç okuyorsunuz ve bu nedenle kesişmelerini görmüyorsunuz. Normalleşmenin bununla hiçbir ilgisi yok. Ve bu arada, MA'lar fiyat değerlerini gösterdiğinden, değerleri _Digits olarak normalleştirmeniz ve hangi değer normalleştirmesinin gerekli olduğunu tahmin etmemeniz gerekir...
Forumun değerli katılımcıları. Lütfen forumda demonte etmeyi bırakmayın. Sadece konu başlığında.
Bence konu kapatılabilir. Açıklamaların yazarları (konu değil) bir fikir birliğine varmadı. Hoş karşılanmayan bazı şovenizm anları oldu.
Ancak ne biri ne de ikincisi davalarını kanıtlayamadı. Bu yüzden konuyu kapatıyorum. Daha fazla tartışma cezalandırılabilir (maksimum günlük yasak).
Normal kanıtlar sunulsa da memnuniyetle karşılanır.
Volodya ve ben yargıç olacağız.
Bu tartışılmıyor.
Burada olan her şeyi görmedim, bu yüzden konu çerçevesinde hangi argümanların verildiğini bilmiyorum. Ancak, Artyom'un bu gönderideki (ve burada daha önce) konumuyla uyumlu olarak, konumumun kanıtlarından bahsettiğimize inandığım için, aşağıdaki sayılarla örneklerden birini vereceğim. gerçek sayılarla çalışırken genel olarak normalleştirmeyi şu veya bu şekilde uygulamak gerekir.
Ekran görüntüleri ve test kodunun bir çeşidi ile.
Artyom yukarıdaki gönderide şunları yazdı:
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
Ve ben de (birçoğu gibi, sanırım diğerleri gibi) bunun en yaygın görev alanlarında basit ve etkili bir yol olduğuna inandığımdan, kendimden sadece küçük bir ekleme yapacağım:
MA satırını kaç ondalık basamakla veya sadece herhangi bir sayıda ondalık basamağa dayalı hesaplamalar (aynı karşılaştırmalar), o kadar çok ondalık basamak ve normalleştirme (belirli bir ondalık basamağa yuvarlama) ile gösterilir.
/* Bazı bireysel görevler için "istisnalar" olabilir ve istediğiniz sonucu elde etmek için değişiklik yapabilirsiniz, örneğin, daha düşük ondalıklı bir değeri daha yüksek ondalıklı bir değerle karşılaştırmak. Ancak, görevleri çözmek için bu gerekliyse, o zaman, benim açımdan, gerekirse, yukarıdaki yöntemin yanı sıra, elde edilen değerlerin yazdırılması ve elde edilen değerlerin görsel olarak karşılaştırılması da önerilebilir. grafikte görüntülenen işleme. */
Çift değerleri metin olarak (Yazdır, Yorum, OBJ_LABEL vb. aracılığıyla) görüntülemeniz gerekiyorsa, sayı metne dönüştürüldüğünden DoubleToString kullanılmalıdır.
Şimdi giriş açıklamasından netliğe:
Ekran görüntülerinde:
Test komut dosyası verileri, iMA işlevi kullanılarak elde edilen MA değerleridir (Dokümantasyonda gerçek türlerle çalışmak için açıklanan işlevleri kullanarak ve dönüştürme olmadan veri dönüştürme ile).
Veri penceresinde ve grafikte, daha küçük ondalık işaretli satırların, mevcut olanı saymadan, grafiğin üçüncü çubuğundaki değerlerde eşitlendiğini görebilirsiniz. Ayrıca grafiğin ondalık basamaklarıyla çizilen standart setten terminale MA değerlerinin eşit olmadığı ve grafikte biraz daha erken görsel olarak eşitlendiği de görülebilir.
Yani ekran görüntülerini büyütürseniz veya deneylerinizi ekteki test scriptini veya kendi kodlarınızı kullanarak yaparsanız, MA satırlarının grafikte olduğu gibi ondalık basamak sayısı ile biraz daha erken kesiştiğini göreceksiniz.
Ve bu anlaşılabilir. Bir benzetme yaparsak, ondalık basamakları birden küçük olan satırlar iki basamaklı tırnak üzerine kurulmuş satırlardır. grafikte üç basamaklı tırnak işaretleri ile. Bu, uçbirimlerdeki üç-beş basamaklı alıntıların henüz yaygınlaşmadığı zamanların "eski" noktalarında onları net bir şekilde görmenizi ve aynı zamanda tırnakların avantajlarının ondalık basamaklarda genişletilmesini sağlar. ticaret işlemleri (daha küçük bir spread dahil) .
Yani, daha az ondalık basamaklı değerler üzerine inşa edilen satırlarda daha az "gürültü" vardır.
Ancak, değerlerin yuvarlanması uygulanmazsa (bu durumda, normalleştirme işlevini kullanarak), belirli bir ondalık nokta ile açıkça sınırlı bir sayının elde edilmesi daha sorunlu olacaktır.
Veya sadece sayılarla ise:
123.4561 ve 123.4556 eşit değildir. Ve onların farkı sıfır değil.
Ancak, yuvarlanırlarsa, hem birinci hem de ikinci sayılar aynı ve 123.456'ya eşit olacaktır. Buna göre, aralarındaki fark 0'a eşit olacaktır.
Ortaya çıkan değerlerin hangi ondalık basamağa yuvarlanacağı, çözülmekte olan görevlere bağlıdır.
Ve ekran görüntülerinde "Uzmanlar" dergisinde, iMA kullanılarak elde edilen MA değerlerini Belgeler'de açıklanan dönüşümlerle ve elde edilen değerlerin dönüşümleri olmadan görebilirsiniz. Test komut dosyasındaki MA ayarları, tablodaki göstergelerin ayarlarına eşittir.
İkinci ekran, dönüşümlü ve dönüşümsüz olarak türetilen iki MA'nın değerleri arasındaki deltaları gösterir.Aşağıda, belirtildiği gibi, küçük bir test kodu. Optimize edilmemiştir, ancak herhangi bir parametreyi değiştirmek de dahil olmak üzere MA değerleriyle bazı farklı deneyler yapmanıza olanak tanır.
İçindeki çubuk sayısı bu satırda belirlenir:
P./S.: Ekli test komut dosyası değiştirildi. Bu seçenek, gönderiye yayınıma girmedi. Biri değil. Afedersiniz.
Daha önce eklenen ekran görüntülerini değiştirmek gerekli değildir, bu yüzden onları aynı bırakıyorum.