Hatalar, hatalar, sorular - sayfa 257
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
Evet, öyle görünmüyor.
Her ikisi de satın alma için olan yalnızca 2 (45 üzerinden) kaybetme işlemi olduğu ortaya çıktı.
Belki de yanlış yere bakıyorum?
Kırmızı ile işaretlenmiştir: Kısa pozisyonlar 45 üzerinden 5'tir. Diyelim ki 40, %95'tir. Soru - Neden 5 = %100, varsaymak mantıklıdır - %5.
Bana öyle gelse de, bu durumda 5 (% 11.11) ve 40 (% 88.89) olmalıdır.
Önbelleği temizlemeyi deneyin. Farklı seçenekler, farklı tarayıcılar denendi - ekleme başarılı oldu.
Ne de olsa resmi bir saldırı olarak değil, doğrudan yoruma mı ekliyorsunuz?
Kırmızı ile işaretlenmiştir: Kısa pozisyonlar 45 üzerinden 5'tir. Diyelim ki 40, %95'tir. Soru - Neden 5 = %100, %5 olduğunu varsaymak mantıklıdır.
Bana öyle gelse de, bu durumda 5 (% 11.11) ve 40 (% 88.89) olmalıdır.
Toplam 45 işlem:
aldığımız toplam
Satış anlaşmaları -% 100'ü kazanan (karsız değil) (yani hepsi kârlıydı)
38'i kazanan, yani 38*100%/40=%95 olmak üzere 40 satın alma anlaşması var.
Daha ileri
Karlı işlemler - 45 üzerinden 43, yani 43*%100/45 = %95,56
İşlemleri kaybetme - 45 üzerinden 2, yani 2*100%/45 = %4.44
Toplam 45 işlem:
aldığımız toplam
Satış anlaşmaları -% 100'ü kazanan (karsız değil) (yani hepsi kârlıydı)
38'i kazanan, yani 38*100%/40=%95 olmak üzere 40 satın alma anlaşması var.
Daha ileri
Karlı işlemler - 45 üzerinden 43, yani 43*%100/45 = %95,56
İşlemleri kaybetme - 45 üzerinden 2, yani 2*100%/45 = %4.44
Bu etkiyi fark etti. Göstergeyi grafiğe eklerken (ayrı bir pencerede), ana şamdan grafiğinin güncellenmesi durur (fiyat donar), ancak teklif penceresinde her şey yolundadır - fiyat kırmızıdan yeşile döner. Ve gösterge sadece bir enstrümanın penceresine eklense de, fiyat diğer pencerede de donuyor. Göstergenin başlatılması ve hesaplanması gövdenin içindedir: if(prev_calculated==0). Bir önceki günden başlamayan kapanış fiyatları hesaplamaya dahil edilir (mevcut kapanış katılmaz). Gösterge hesaplaması bittikten sonra fiyat ekranı tekrar hareket etmeye başlar ve pencere ile senkron olarak değişir.
Resimde görülen:
Bu etkiyi fark etti. Göstergeyi grafiğe eklerken (ayrı bir pencerede), ana şamdan grafiğinin güncellenmesi durur (fiyat donar), ancak teklif penceresinde her şey yolundadır - fiyat kırmızıdan yeşile döner. Ve gösterge sadece bir enstrümanın penceresine eklense de, fiyat diğer pencerede de donuyor. Göstergenin başlatılması ve hesaplanması gövdenin içindedir: if(prev_calculated==0). Bir önceki günden başlamayan kapanış fiyatları hesaplamaya dahil edilir (mevcut kapanış katılmaz). Gösterge hesaplaması bittikten sonra fiyat ekranı tekrar hareket etmeye başlar ve pencere ile senkron olarak değişir.
Resimde görülen:
İlk hesaplamanın çok kaynak yoğun olduğu ortaya çıktı. Gösterge kodunun en uygun şekilde yazılmadığını kontrol edin.
İlk hesaplama çok kaynak yoğun. Gösterge kodunun en uygun şekilde yazılmadığını kontrol edin.
Ayrı bir program dizisinde bir şamdan grafiğindeki alıntıların güncellenmesi ile başka bir programda gösterge hesaplamalarının yüklenmesi arasında bir şekilde ayrım yapmanın mümkün olduğunu kastetmiştim.
Grafikteki tekliflerin güncellenmesi, göstergelerin de hesaplandığı terminal teklifleri veritabanının veri durumunun yalnızca bir görüntüsüdür. Kaynakları kaydetmek için, göstergeye giriş verileri olarak iletilen terminal veritabanı verileridir, yani. gösterge hesaplamasının sonuna kadar değiştirilemezler.
Sayın alexvd , ne yazık ki, şimdi göstergede 20'den fazla sınıftan oluşan 3000'den fazla kod satırı var ve kodu optimize etmek oldukça zor (döngülerde birkaç yüz milyar hesaplama işlemi) ve bu sayı büyüyebilir yaklaşık 10.000'e kadar. Ayrı bir program dizisinde bir şamdan grafiğindeki alıntıların güncellenmesi ile başka bir programda gösterge hesaplamalarının yüklenmesi arasında bir şekilde ayrım yapmanın mümkün olduğunu kastetmiştim. Doğruyu söylemek gerekirse, işe yeni başladığımda, bir masaüstü bilgisayarda hız konusunun bu kadar akut olacağını düşünmemiştim ama aynı zamanda küçük bir dizüstü bilgisayar kullanmak istiyorum.
Göstergeyi optimize etmeye çalışın, burada nesne ve satır sayısı önemli değil. Büyük ihtimalle mevcut hindiyi (3000 hatta) istenilen hızda çalıştırmak mümkündür.
Tüm kaynak yoğun hesaplamalar bir zamanlayıcıya yerleştirilirse (mümkün olduğu ortaya çıkarsa) ilginç bir değişken elde edilir, o zaman bu hesaplamalar her onayda yapılmayacaktır.
Ve hesap makinesi bloğunu mümkün olduğunca optimize edin (makul koridorlara kadar).
Göstergeyi optimize etmeye çalışın, burada nesne ve satır sayısı önemli değil. Büyük ihtimalle mevcut hindiyi (3000 hatta) istenilen hızda çalıştırmak mümkündür.
Tüm kaynak yoğun hesaplamalar bir zamanlayıcıya yerleştirilirse (mümkün olduğu ortaya çıkarsa) ilginç bir değişken elde edilir, o zaman bu hesaplamalar her onayda yapılmayacaktır.
Ve hesap makinesi bloğunu mümkün olduğunca optimize edin (makul koridorlara kadar).
Prensip olarak, işi biraz optimize etmek mümkündür, çünkü. bazı özdeş veriler, farklı sınıfların nesnelerinde dikkate alınır - yani. birden fazla. Ancak, burada başka bir sorun ortaya çıkıyor, yani, her biri hata ayıklanabilen ve bundan emin olabilen birçok kara kutu kavramını bırakmak (yani, her nesne tamamen özerk bir bloktur ve eğer bazı ara verilerin hesaplanması, hangi farklı nesneler için aynıdır, onları nesnelerden çıkarın, daha sonra özerklik kaybolur, bu da her sınıfın ayrı ayrı hata ayıklamasına izin verir. Bu özenle, programın yapısı kaybolacak, yani ben kendim ne yazdığımı anlamayacağım, ve en ufak bir hata artık yakalanmayacak Hata ayıklama hızı da çok artacaktır çünkü bir parça değil tüm algoritmayı çalıştırmak gerekli olacaktır. Bu şekilde nesne sayısı bende var ve hızı etkiliyor.
Bu nedenle, bana öyle geliyor ki, gösterge tamamen oluşturulduğunda, hata ayıklandığında ve test edildiğinde finalde zaten böyle bir optimizasyon yapmaya çalışmak mümkün olacak ve ne yazık ki hala bu andan uzakta (şu anda çalışıyorum). yaklaşık 4 ay boyunca ilk aşama, çünkü Ekonometri, Matematik kitaplarında, her şey farklı kitaplardaki parçalara dağılmış (malzemenin ayrıntılı olarak birleşik sunumları yoktur), yazarların terimler ve algoritmalarda hatalar ve tutarsızlıklar vardır. yeni başlayanlar tarafından yalnızca ansiklopedik sözlüklere atıfta bulunurken bulunan teorik bilgiler, pratik uygulama olasılıkları ile çelişir, yani. sayısal yöntemler şeklinde uygulama ve sayısal yöntemlerin kendileri, yazılım ortamının işlevselliğine gereksinimler getirir), süreç uzun, sıkıcı ve viskozdur.
Hesaplama mantığına göre, her mumun oluşumundan sonra gerçekleşmelidir, bu nedenle başlangıçta "yeni çubuk" işlevinin gövdesine yerleştirilmesi gerekiyordu, ancak zamanının bu aralığı geçebilmesi beni zorladı. if(prev_calculated=) function =0) gövdesinin içine yerleştirin, böylece şimdi, hata ayıklama aşamasında yalnızca bir kez geçer. Zamanlayıcı önerinizi düşüneceğim, teşekkürler.