MQL4 ustaları için soru. Yine Çift Karşılaştırma hakkında. - sayfa 10

Yeni yorum
 
Simca :
SK. (a) yazdı:

Her yeni kullanıcıya aynı şeyi 1000 defa açıklamak zorunda kalan geliştiricilere en içten taziyelerimi sunarım..



Zaten açık bir soygun...
Kabul ediyorum. SK olmasına rağmen. forumda otorite ama "belirli bilgisayar teknolojileri" bende de şüphe uyandırıyor.
Gerçek sayıların bellekte saklanması ders kitaplarında yazılıdır ve değişkenlerin kendi kendine değişebileceğine dair orada hiçbir şey söylenmez. Bu forumda sadece SK'den duymadım.
Bu nedenle, her yeni kullanıcıyı 1000 kez yanılttıysanız, şimdi onları bulmanız ve sözleriniz için özür dilemeniz gerekir!

Simca'ya katılıyorum. Aritmetik işlemleri gerçekleştirirken kusurlar mümkündür, ancak depolama, yazma veya okuma sırasında hariç tutulurlar!

Bu yüzden NormalizeDouble() işlevinin algoritmasını sordum, belki de hataya yol açan aritmetik işlemleri de vardır?
Sence ne düşünüyorsun ?
 

TAMAM. Bu konuda o kadar emin konuşuyorsun ki, sözlerimden şüphelendim bile.

Bir süreye kadar 256MB RAM'li eski bir bilgisayarda çalışmak zorunda kaldım. Birkaç program yüklenirken, işletim sistemi verilerin bir kısmını diske boşalttı ve ardından yeniden yükledi. Kodu değiştirdiğimden (karşılaştırma operatöründe normalleştirmeyi gösterir), hata görünmeyi bıraktı. Ama sözlerinden sonra, zaten şüphelendim - ya orada bir şeyi gerçekten düzelttiysem ve fark etmediysem.

Şimdi bilmiyorum - özür dilemek ya da değil.. Eğer yanılıyorsam 1000 kullanıcı beni affetsin.

(ama yine de, karşılaştırma işlemini hesaplarken doğrudan normalleştirmek daha iyidir :)

 
gravity001 :
Gerçek sayıların bellekte saklanması ders kitaplarında yazılıdır ve değişkenlerin kendi kendine değişebileceğine dair orada hiçbir şey söylenmez. Bu forumda sadece SK'den duymadım.
Depolandığında , kendi içinde hiçbir şey değişmez . Ancak gerçek sayıların bilgisayar belleğinde temsil edilme şekli, saklanan değerlerin doğruluğunu (rakam kapasitesini) etkiler. Gerçek sayılarla aritmetik işlemlerde, sonuç genellikle "yeterince kesin değildir" (insan bakış açısından), bu nedenle bazen işlemin sonucunu normalleştirmek gerekir. Eşitlik için sonraki karşılaştırma sırasında işlemlerin sonucunu kesinlikle normalleştirmek gerekir (genellikle > , < için de). Ayrıca gerekli sabit kodlanmış bit derinliğine sahip değerlerle çalışıyorsanız (örneğin fiyatlar ) sonucu normalleştirmeniz gerekir. Kendi başlarına, gerçek sayılarla ara hesaplamalar, kural olarak, normalleştirme gerektirmez.
Ancak, tüm bunlar hesaplamalara atıfta bulunur, ancak değerler normalleştirilmiş olsun ya da olmasın, bellekte değişmeden saklanır.
yerçekimi001 :
Bu yüzden NormalizeDouble () fonksiyonunun algoritmasını sordum, belki hataya yol açan aritmetik işlemleri de vardır?
Sence ne düşünüyorsun ?
NormalizeDouble işlevinin algoritması hakkında, kim olmadığımı geliştiricilere sormanız gerekiyor. :) Ayrıca, NormalizeDouble işlevi tamamen aynı bir uygulamada her iki kod parçasında da göründüğü için bu, anlaşmazlığın konusu için geçerli değildir. Tek fark, iki normalleştirmenin sonuçlarının doğrudan karşılaştırılması, bu sonuçların değişkenlere önceden yazılması ve ardından değişkenlerin değerlerinin karşılaştırılmasıydı. NormalizeDouble işlevi tarafından döndürülen değerin türü, depolama için kullanılan değişkenin türüyle çakıştığından, yukarıdaki parçalar arasında hiçbir fark olmayacağını fark ettim. Şimdi, NormalizeDouble işlevi, yerleştirildiği değişkenden daha büyük bir bit derinliğinde bir değer döndürürse, fark görünebilir ve kesinlikle kimlik hakkında konuşmak imkansız olurdu . Ancak MetaEditor'un HELP veri tipine göre her iki durumda da karar verin double , bu nedenle NormalizeDouble işlevinin nasıl uygulandığına bakılmaksızın herhangi bir fark olmamalıdır .
 
SK. писал (а):

(ama yine de, karşılaştırma işlemini hesaplarken doğrudan normalleştirmek daha iyidir :)

Ancak bununla, her yeni kullanıcıya uygulandığında kesinlikle katılıyorum . Neyin ve nasıl çalıştığına dair net bir fikir yoksa, daha güvenli ve daha güvenilir bir yol izlemek en mantıklısı! Ama bu senin ve benim için geçerli değil. :)
Ve benim açımdan (sorunun özünü tam olarak anlamayanlar için), şunu da önerebilirim:

ama yine de, karşılaştırma işlemi (c) SK'yi hesaplarken doğrudan normalleştirmek daha iyidir.

 
SK. писал (а):

(ama yine de, ne zaman doğrudan normalleştirmek daha iyidir?
Karşılaştırma işleminin hesaplanması :)





Üzgünüz, ancak verimlilik açısından, normalleştirme gerektiren verileri karşılaştırmak için çok daha iyi uygulamalar var. Genel olarak, bu bir standarttır (karşılaştırma algoritması). Aradaki farkı ölçeğin boyutunun yarısı ile karşılaştırmak gerekir. Neden bahsediyorum: fiyatları karşılaştırmak için (farklı olsun ya da olmasın), farkı alıp 0,5*Roint değeriyle karşılaştırmanız gerekir (uzman\komut dosyası\göstergesinin başlatılması sırasında yalnızca bir kez hesaplanabilir) Bu, bir işlevi çağırmaktan çok daha verimlidir, hatta ikiden fazla ve hatta bir döngü içindeyse).

İyi şanlar.
 
mql4'te ÇİFTLERİN KARŞILAŞTIRILMASI ARAŞTIRMA ARAŞTIRMASI. İlk olarak, çiftlerle çalışmak tamamen derleyici hilesidir, bu nedenle esasen yorumlayıcılı bir komut dosyası olan mql4'ten kolaylık talep etmek yersizdir. Ana, geliştiriciler bir yol verdi, karşılaştırmanın doğru sonucunu GARANTİLİ, kalemlerle kontrol ettik, elbette dilbilgisi, ama ÇALIŞIYOR !!! Belgeler, "!=" veya "==" durumunda akımı normalleştirmeniz gerektiğini belirtse de, bağımsız uzman testlerimiz göstermiştir ki (a>b) bir dönüş durumunda doğru sonucu GARANTİ ETMEZ(!) b'ye eşit olacak! Hem a hem de b'yi KESİNLİKLE normalleştirmiş olsanız bile, sayılar eşitse sonuç tahmin edilemez. Ancak geliştiricilerin yapısı::: NormalizeDouble (ab, Digits)>0 güvenilir bir şekilde çalışıyor! Dut yoldaşların neden normalleştirme işlevinden hoşlanmadıklarını bilmiyorum ... Belki de (İÇERİDE) oldukça sempotik olarak şöyle yapılır: iki çift, bir çift doğrulukla bölünür ve aşağı (veya yukarı) yuvarlanır. Ve sonra - bütün sorunsuz.
 
.FG писал (а):
mql4'te ÇİFTLERİN KARŞILAŞTIRILMASI ARAŞTIRMA ARAŞTIRMASI. İlk olarak, çiftlerle çalışmak tamamen derleyici hilesidir, bu nedenle esasen yorumlayıcılı bir komut dosyası olan mql4'ten kolaylık talep etmek yersizdir. Ana, geliştiriciler bir yol verdi, karşılaştırmanın doğru sonucunu GARANTİLİ, kalemlerle kontrol ettik, elbette dilbilgisi, ama ÇALIŞIYOR !!! Belgeler, "!=" veya "==" durumunda akımı normalleştirmeniz gerektiğini belirtse de, bağımsız uzman testlerimiz göstermiştir ki (a>b) bir dönüş durumunda doğru sonucu GARANTİ ETMEZ(!) b'ye eşit olacak! Hem a hem de b'yi KESİNLİKLE normalleştirmiş olsanız bile, sayılar eşitse sonuç tahmin edilemez. Ancak geliştiricilerin yapısı::: NormalizeDouble (ab, Digits)>0 güvenilir bir şekilde çalışıyor! Dut yoldaşların neden normalleştirme işlevinden hoşlanmadıklarını bilmiyorum ... Belki de (İÇERİDE) oldukça sempotik olarak şöyle yapılır: iki çift, bir çift doğrulukla bölünür ve aşağı (veya yukarı) yuvarlanır. Ve sonra - bütün sorunsuz.

Lütfen doğru Rusça yazın.

 
Bana geliştiricinin sitesine (Rusça) bir bağlantı verin ve SADECE YAZAR TANIMLARINI kullanacağıma söz veriyorum. :) Benim görüşüme göre senin dilin benimkinden daha doğru değil, ama KİŞİSEL OLARAK anlamıyorsan, falan filan uzman değerlendirmesinden ayıramazsan o zaman “Rosh için” çeviri yapacağım. Çünkü sana değil, 1001. yeni gelene yazdım. :)
 
.FG писал (а):
Bana geliştiricinin sitesine (Rusça) bir bağlantı verin ve SADECE YAZAR TANIMLARINI kullanacağıma söz veriyorum. :) Benim görüşüme göre senin dilin benimkinden daha doğru değil, ama KİŞİSEL OLARAK anlamıyorsan, falan filan uzman değerlendirmesinden ayıramazsan o zaman “Rosh için” çeviri yapacağım. Çünkü sana değil, 1001. yeni gelene yazdım. :)

Örneğin, www.gramota.ru

Forumun Albany bölümü yok. Ancak, Rusça olmayan bir sonraki mesajdan sonra oraya gönderileceksiniz. Lütfen büyük ve güçlü olanı çarpıtmayın.

 
Bu durumda, sen stringo, programlamada başarı için Cyril ve Methodius'a Onur Sertifikası ile gideceksin! :) Yoldaşların sürülerini tamir ediyorsun ama escho'dan memnun değiller. Tüm bu sorunları, uzun süredir mevcut sürümlerde uygun bir şekilde uygulanan ücretsiz DOS derleyicilerinde normalleştirme ile karşıladım. Bu nedenle, bazı programcılar neden böyle bir tufan öncesi çiftlerin kontrolünü anlamıyor. Kodlarını yeniden yazdıklarında, her yerde sıfıra kıyasla normolize yığdıklarında, kendi "C-mantık"larında hataların olmadığını ve baba-uygulayıcıların yetersiz okuryazar yorumlarını görünce şaşıracaklar. Optimizasyon ve diğer küçük şeyler, işe yaramaz istatistiksel tekniklerin resmileştirilmesi konusunda eğitim hakkında yüzünüzde mavi olana kadar burada yayınlayabilirsiniz, ancak temel hesaplamaların SONUÇLARI ile ilgili konular, birincil kapsama gerektiren temel taşı olarak kalacaktır. Ve beni ayrılmakla tehdit etmekle tehdit ederseniz, bazı CME'lere gideceğiz, onlardan FIX ve diğer çan ve ıslıklarla ALBANSKİ'deki belgeleri ve programı alacağız. :) Ve işsiz kalacaksın. Mq6 yap ve suda oturarak uyan ve en azından birisinin ürünlerini test etmesini istiyorsun, en azından Arnavutça, ama hayır, artık bizi uyandırmıyorlar ... Çünkü bizi sessizce yasakladın .. . :))))))))))))))))))))) 000
1...34567891011
Yeni yorum