MQL4 ustaları için soru. Yine Çift Karşılaştırma hakkında. - sayfa 7
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
Bu konuşma sonsuza kadar devam edecek gibi görünüyor. Yeni bir kullanıcı uygun deneyimi ve bilgiyi elde edene kadar, kural olarak, birkaç kez normalleştirmeye girmeyi başarır.
Belki de, MT5'te, karşılaştırma işlemleri gerçekleştirirken gerçek sayıların doğruluğunu zorla sınırlamak mantıklıdır, örneğin, 8 ondalık basamakla (yani, NormalizeDouble () rakamı = 8 ile yürütülmeye zorlamak).
Karşılaştırma işlemi tekrar tekrar kullanılacaksa (tekrarlayan hesaplamalarda vb.), girişte 8 karaktere yuvarlanırken çıkıştaki hata 1 ile orantılı olabilir.
Bu deneyimi SmoothedAvarege hesaplamasıyla yaşadım ve bunu bir yıl önce uygulamamda hesapladım. Bundan sonra, çiftlerin bit derinliğine dokunmayan bu tür çalışma yöntemlerini seçmeye çalışıyorum.
Veya, Gravite001'in önerdiği gibi, INT'lere gidin (ki bilirsiniz, çok zahmetlidir).
Belki de, MT5'te, karşılaştırma işlemleri gerçekleştirirken gerçek sayıların doğruluğunu zorla, örneğin 8 ondalık basamakla sınırlamak mantıklıdır (yani, NormalizeDouble'ı () basamak=8 ile yürütülmeye zorlamak).
Ancak terminal, yalnızca kullanıcı tarafından ayarlanan işlemlerle değil, ondan gizlenen işlemlerle de yavaşlar. Bana öyle geliyor ki, ComparePrice işlevini dile basitçe tanıtmak tercih edilir. Bu arada, tıpkı Irtron gibi, Nokta / 2'yi doğal bir ölçü olarak görüyorum (Nokta * 0,5 muhtemelen daha iyidir). Her seferinde bölmek/çarpmamak için bu yarı önceden tanımlanmış bir değişken haline getirilebilir. Bu arada durum böyle değil, böyle bir değişkeni kendiniz girip ilk başladığınızda bir kere hesaplayabilirsiniz. Geliştiriciler belirli bir hassasiyetle, yani aynı şeyle, ancak Nokta / 2 yerine rakamlarla çift karşılaştırma işlevi yapabilmelerine rağmen.
Ödüllü... :)
Float karşılaştırması - fark modülünü küçük bir eşik ile karşılaştırarak yapılır.
dönüş (fabs(d1-d2) < 1e-10) örneğin.
Suları neden bulandırıyor... Güzel raporlar için NormalizeDouble (...) işlevi gereklidir, başka bir şey değil.
Ama meselenin özüne hakim olamamışsınız, daha dikkatli okumanız gerekiyor. Sorunun özü, genel olarak ve özel MT4 durumunda programlama stilidir.
Ödüllü... :)
Float karşılaştırması - fark modülünü küçük bir eşik ile karşılaştırarak yapılır.
örneğin dönüş (fabs(d1-d2) < 1e-10).
Suları neden bulandırıyor... Güzel raporlar için NormalizeDouble (...) işlevi gereklidir, başka bir şey değil.
Ama meselenin özüne hakim olamamışsınız, daha dikkatli okumanız gerekiyor. Sorunun özü, genel olarak ve özel MT4 durumunda programlama tarzıdır.
Ve meselenin özünün ne olduğunu söylerlerdi... Aksi takdirde, ipuçları - anlamıyorum! Anlıyorum :)
Hız hakkında konuşuyorsak, o zaman modern. yüzen işlemler işlemciler üzerinde gerçekleştirilir
neredeyse tamsayılar kadar hızlı. STİL'e gelince, üzgünüm, pragmatizm kuralları ...
ASHIPS etraftayken, o zaman hangi tarzdan bahsediyoruz ... Keşke işe yarasaydı. ..
Ve sonra iki sayıyı karşılaştırmaktan başka sorun yok :)))))))))
Valla ben senden bunu beklemiyordum Hiçbir şekilde!
Karşılaştırma işlemi tekrar tekrar kullanılacaksa (tekrarlayan hesaplamalarda vb.), girişte 8 karaktere yuvarlanırken çıkıştaki hata 1 ile orantılı olabilir.
Bu deneyimi SmoothedAvarege hesaplamasıyla yaşadım ve bir yıl önce uygulamamda hesapladım. Bundan sonra, çiftlerin bit derinliğine dokunmayan bu tür çalışma yöntemlerini seçmeye çalışıyorum.
Veya, Gravite001'in önerdiği gibi, INT'lere gidin (ki bilirsiniz, çok zahmetlidir).
Bir dakika bekle. Aceleci sonuçlara gerek yok.
Her şeyden önce. Gerçek değişkenin değerlerinin yuvarlanmaya zorlanmasını önermiyorum. Karşılaştırma işleminin sonucunu hesaplarken (varsayılan durum için) değişkenlerin karşılaştırılan değerlerinin (kopyalarının) zorunlu yuvarlanmasını öneriyorum. Ve elbette değişkenin gerçek değerine dokunulamaz. Bu durumda, hesaplanan başka hiçbir değer etkilenmeyecektir, çünkü. karşılaştırma işleminde kullanılan değişkenlerin ilk değerleri değerlerini korur ve döngüsel hesaplamalardaki hatalar birikmez.
İkincisi. Daha ciddi sonuçları olan hataları ortadan kaldırmak için bu şekilde gidebilirsiniz dedim. Bununla birlikte, daha da zorlu hesaplamalar sağlamak için, NormalizeDouble () işlevinin verilen parametrelerle düzenli kullanım olasılığını korumak gerekir.
Dolayısıyla benim teklifim dilin olanaklarını sınırlamaz, aksine genişletir.
Başka bir şey de, bu tür dönüşümleri bilmeyen şanssız bir kullanıcı, bu durumda, kendisi için anlaşılmaz bir sonuç da alabilir. Ancak, karşılaştırma işlemlerinin tipik olarak fiyat değerlerini (yani, basamak = 4) kullandığı göz önüne alındığında, çoğu durumda bu hata oluşmaz. Böylece, önerilen teknolojinin kullanımı, öngörülemeyen sonuçlara yol açan hataların sayısını azaltacaktır.
Bu arada durum böyle değil, böyle bir değişkeni kendiniz girip ilk başladığınızda bir kere hesaplayabilirsiniz.
Yasaktır.
Bunun yerine program satırları yazabilirsiniz, ancak hiç kimse (geliştiriciler dahil) bu değişkenin değerinin Expert Advisor'ın ömrü boyunca kesinlikle değişmeyeceğini garanti edemez. Buradaki nokta, program kodunun doğruluğu değil, hesaplamaların teknolojik özellikleri ve değişken değerleri depolamak için teknolojik kurallardır. Bunun için olmasaydı, o zaman soru ortaya çıkmayacaktı.
Ve mevcut durumda, 123.000000000000 değişkeninin hesaplamalarda kullanıldığı zamandaki başlangıç değeri 122.999999999999 olabilir. Ve bu, değişkenin keşfedilmesinden bu yana değerinin hiç değişmemesine, ancak program tarafından yalnızca diğer hesaplamalara katılması istenmesine rağmen.
Aslında, tüm yaygara bu yüzden. Bu nedenle NormalizeDouble () işlevini gerçek hesaplamaya mümkün olduğunca yakın, tercihen if, for, while ifadesinin koşulunda kullanmak gerekli hale geldi.
Bu arada durum böyle değil, böyle bir değişkeni kendiniz girip ilk başladığınızda bir kere hesaplayabilirsiniz.
Yasaktır.
Daha doğrusu, program satırları yazabilirsiniz, ancak hiç kimse (geliştiriciler dahil) bu değişkenin değerinin Expert Advisor'ın ömrü boyunca kesinlikle değişmeyeceğini garanti edemez. Buradaki nokta, program kodunun doğruluğu değil, hesaplamaların teknolojik özellikleri ve değişken değerleri depolamak için teknolojik kurallardır. Bunun için olmasaydı, o zaman soru ortaya çıkmayacaktı.
Ve mevcut durumda, 123.000000000000 değişkeninin hesaplamalarda kullanıldığı zamandaki başlangıç değeri 122.999999999999 olabilir. Ve bu, değişkenin keşfedildiği andan itibaren değerinin hiç değişmemesine, sadece program tarafından diğer hesaplamalara katılması istenmesine rağmen.
Aslında, tüm yaygara bu yüzden. Bu nedenle NormalizeDouble () işlevini gerçek hesaplamaya mümkün olduğunca yakın, tercihen if, for, while ifadesinin koşulunda kullanmak gerekli hale geldi.
Köknar ağaçları, bütün çarşının ne için olduğunu anlamaya başlıyor gibiyim...
Sonuç olarak, bir şey icat etmeye gerek olduğunu düşünmüyorum. Çünkü her şey ÖZEL duruma bağlıdır. Amaç ne? İki sayı, 0.1'lik bir mantis ile farklıysa ve KRİTİK ise, bir patiska. önemli değilse - başka. Birbiriyle karşılaştırmak için arıyorsunuz. Ancak NORMAL bir derleyicinin fırfırlar olmadan verdiği ESNEKLİK YETERLİ ve gerekli bir şeydir, IMHO.
:)
Köknar ağaçları, bütün çarşının ne için olduğunu anlamaya başlıyor gibiyim...
Sonuç olarak, bir şey icat etmeye gerek olduğunu düşünmüyorum. Çünkü her şey ÖZEL duruma bağlıdır. Amaç ne? İki sayı, 0.1'lik bir mantis ile farklıysa ve KRİTİK ise, bir patiska. önemli değilse - başka. Birbiriyle karşılaştırmak için arıyorsunuz. Ancak NORMAL bir derleyicinin fırfırlar olmadan verdiği ESNEKLİK YETERLİ ve gerekli bir şeydir, IMHO.
:)
"İcat etme" konusuna ise cevap veremem. Görünüşe göre ne düşündüğüne bağlı :)
Örneğin, Point/2 türündeki buluşlar gerçekten de birçok durumda belirli bir kesinlik ile hesaplamaların yapılmasını mümkün kılmaktadır. Bununla birlikte, geliştiricilerin tavsiyesini kullanmak daha iyidir, yani bir kez ve herkes için (yeni belgelere kadar) karşılaştırma işlemlerini hesaplarken standart NormalizeDouble () işlevini kullanmayı bir kural haline getirin.
NormalizeDouble () kullanırsanız oynamaz. Ve eğer kullanmazsan, o zaman ne kadar şanslısın.