OOP'nin bir uygulaması hakkında - sayfa 2
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
Ana şey, daha sonra kullanımın nasıl uygun olduğudur. Farklı girişleri denemek için giriş kurulum numarasına göre toplu olarak yapabilirsiniz. Onlar. giriş kurulumlarının bir koleksiyonu var. Uygunsa, bir dizi fonksiyon olarak. En basitleri piyasada koşulsuz alım veya satımdır. Veya koşullu)) Sonra optimize ediciyi çalıştırır ve farklı giriş kurulumlarını yineleriz
Evet hala böyle bir şey görülüyor, stratejinin sayısını belirlediğimiz ayarlarda, optimize edicide sayılarla optimize ediyoruz. Ancak bu ilk kez, uzun zamandır kendi kendine optimizasyonu anında yapmak için bir rüya oldu.
bu kendi kendini iyileştirmenin (nesnel işlev) amacı nedir?
Amaç belli. İlk olarak, test cihazındaki optimize edici mevcut gün için yeterli değil, en azından MT4'te kesin. Ve MT4 için yapıyorum.
İkincisi - piyasa gün içinde ve herhangi bir sebep olmaksızın (haberler) önemli ölçüde değişebilir. Muhtemelen durgun bir dairenin devam ettiğini fark ettiniz ... bir daire ve aniden herkes kuyruğun altına hardal bulaşmış gibi görünüyor, alıntılar yırtılmaya başlıyor. Ya da geniş bir daire, hatta tam bir kaos var.
Bu tür durumları sınıflandırmanın ve bunları tanımlarken stratejinin istenen değişikliğini dahil etmenin mümkün olduğunu düşünüyorum. Nasıl yapılır? Yapay zeka yarat İnce bir bağırsağım var. Ancak optimizasyon yöntemi dolaylı olarak durumu belirleyebilir.
Şimdiye kadar, bunlar sadece denenmemiş düşünceler.
Evet hala böyle bir şey görülüyor, stratejinin sayısını belirlediğimiz ayarlarda, optimize edicide sayılarla optimize ediyoruz. Ancak bu ilk kez, uzun zamandır kendi kendine optimizasyonu anında yapmak için bir rüya oldu.
Müşteriniz, anladığım kadarıyla, bildiği tüm stratejileri tek bir uzmanda toplamak istiyor. Bir strateji listeniz olana kadar bu görevi tamamlayamazsınız. Ortaklaşa bir TOR hazırlamanızı tavsiye ederim.
Bu stratejiler listesinin bir ARTI kendi kendine optimizasyon konusuna değindiyse, ona bir sinir ağı yazın , tekerleği yeniden icat etmeyin ve müşteriyi programlamanın temelleri hakkında bilgiyle kandırmayın. Sizden tam olarak bunu istiyor.
Bir "zashiba" örneği verebilir misiniz?
İşte buradasın. Standart kitaplıkta ticaret sınıfı hiyerarşisi:
Bundan , para yönetimi modülünün bir uzman olduğu anlaşılmaktadır. İzleyen durdurma da bir uzmandır. Bir uzman diğer uzmanları içerir. Bu tutarsız miras, hem takip hem de para yönetiminin temeldeki EA'nın bazı özel verilerine ve yöntemlerine erişim gerektirmesinden kaynaklanır.
Bunun ötesinde, uzun miras çelenkleri vardır. CIndicators, sırayla üst yöntemlerini çağıran CIndicatorBuffer'ı kullanır. Sonuç olarak, gösterge değerini elde etmenin basit bir şekilde izlenmesi, son derece kafa karıştırıcı bir görev haline gelir. Üç özyinelemeli çağrıdan sonra, nereden geldiğine dair anlayış tamamen kaybolur.
Ve bu, başarısız kalıtımın sadece bir örneğidir. Aslında, mirasa dayalı herhangi bir az çok büyük sınıf hiyerarşisi neredeyse her zaman tutarsız, kafa karıştırıcı ve özyinelemeli hale gelir. Bu, hata ayıklama ve daha fazla geliştirme sürecini son derece karmaşık hale getirir.
Kalıtım derinliğinin 1-2 seviye ile sınırlandırılması gerektiği görülüyor. Ayrıca, birinci seviye, sıfır seviyeli CObject'in (her şey bir nesnedir) global ve evrensel tanımından miras alınmalı ve belirli bir varlık "Uzman", "Gösterge", "Sondaki durdurma" uygulanmalıdır. İkinci seviyeler, "MACD-tabanlı Uzman Danışman", "SMA göstergesi", "Sondaki takip durdurma" vb. özel uygulamalarını zaten uygulamalıdır. Ancak üçüncü seviyenin kullanımı için, mümkün olan her şekilde ciddi şekilde cezalandırmanız ve kovuşturmanız gerekir.
Onlar. sınıflandırmanın gerçekten değerli bir araç olduğu ancak şu durumlarda ortaya çıkıyor:
Müşteriniz, anladığım kadarıyla, bildiği tüm stratejileri tek bir uzmanda toplamak istiyor . Bir strateji listeniz olana kadar bu görevi tamamlayamazsınız. Ortaklaşa bir TOR hazırlamanızı tavsiye ederim.
Bu stratejiler listesinin ARTı, kendi kendine optimizasyon sorunuysa, ona bir sinir ağı yazın, tekerleği yeniden icat etmeyin ve müşteriyi programlamanın temelleri hakkında bilgiyle kandırmayın . Sizden tam olarak bunu istiyor.
İşte buradasın. Standart kitaplıkta ticaret sınıfı hiyerarşisi:
Bundan , para yönetimi modülünün bir uzman olduğu anlaşılmaktadır. Takip eden durdurma da bir uzmandır. Bir uzman diğer uzmanları içerir. Bu tutarsız miras, hem takip hem de para yönetiminin temeldeki EA'nın bazı özel verilerine ve yöntemlerine erişim gerektirmesinden kaynaklanır.
Bunun ötesinde, uzun miras çelenkleri vardır. CIndicators, sırayla üst yöntemlerini çağıran CIndicatorBuffer'ı kullanır. Sonuç olarak, gösterge değerini elde etmenin basit bir şekilde izlenmesi, son derece kafa karıştırıcı bir görev haline gelir. Üç özyinelemeli çağrıdan sonra, nereden geldiğine dair anlayış tamamen kaybolur.
Ve bu, başarısız kalıtımın sadece bir örneğidir. Aslında, mirasa dayalı herhangi bir az çok büyük sınıf hiyerarşisi neredeyse her zaman tutarsız, kafa karıştırıcı ve özyinelemeli hale gelir. Bu, hata ayıklama ve daha fazla geliştirme sürecini son derece karmaşık hale getirir.
Kalıtım derinliğinin 1-2 seviye ile sınırlandırılması gerektiği görülüyor. Ayrıca, birinci seviye, sıfır seviye CObject'in (her şey bir nesnedir) global ve evrensel tanımından miras alınmalı ve belirli bir varlık "Uzman", "Gösterge", "Sondaki durdurma" uygulanmalıdır . İkinci seviyeler, "MACD-tabanlı Uzman Danışman", "SMA göstergesi", "Sondaki takip durdurma" vb. özel uygulamalarını zaten uygulamalıdır. Ancak üçüncü seviyenin kullanımı için, mümkün olan her şekilde ciddi şekilde cezalandırmanız ve kovuşturmanız gerekir.
Şimdi fikir açık. Bu arada benim için robotlarımda da aynen bu şekilde yapılıyor, vurguladığım gibi basit bir şekilde. Sadece isimler farklı.
Not: Böyle bir grafik neyden oluşuyordu? Doxygen gibi bir şey mi?
İşte buradasın. Standart kitaplıkta ticaret sınıfı hiyerarşisi:
Bundan , para yönetimi modülünün bir uzman olduğu anlaşılmaktadır. İzleyen durdurma da bir uzmandır. Bir uzman diğer uzmanları içerir. Bu tutarsız miras, hem takip hem de para yönetiminin temeldeki EA'nın bazı özel verilerine ve yöntemlerine erişim gerektirmesinden kaynaklanır.
Bunun ötesinde, uzun miras çelenkleri vardır. CIndicators, sırayla üst yöntemlerini çağıran CIndicatorBuffer'ı kullanır. Sonuç olarak, gösterge değerini elde etmenin basit bir şekilde izlenmesi, son derece kafa karıştırıcı bir görev haline gelir. Üç özyinelemeli çağrıdan sonra, nereden geldiğine dair anlayış tamamen kaybolur.
Ve bu, başarısız kalıtımın sadece bir örneğidir. Aslında, mirasa dayalı herhangi bir az çok büyük sınıf hiyerarşisi neredeyse her zaman tutarsız , kafa karıştırıcı ve özyinelemeli hale gelir. Bu, hata ayıklama ve daha fazla geliştirme sürecini son derece karmaşık hale getirir.
Kalıtım derinliğinin 1-2 seviye ile sınırlandırılması gerektiği görülüyor. Ayrıca, birinci seviye, sıfır seviyeli CObject'in (her şey bir nesnedir) global ve evrensel tanımından miras alınmalı ve belirli bir varlık "Uzman", "Gösterge", "Sondaki durdurma" uygulanmalıdır. İkinci seviyeler, "MACD-tabanlı Uzman Danışman", "SMA göstergesi", "Sondaki takip durdurma" vb. özel uygulamalarını zaten uygulamalıdır. Ancak üçüncü seviyenin kullanımı için, mümkün olan her şekilde ciddi şekilde cezalandırmanız ve kovuşturmanız gerekir.
Onlar. sınıflandırmanın gerçekten değerli bir araç olduğu ancak şu durumlarda ortaya çıkıyor:
+ çok doğru düşünceler.
Not: Böyle bir grafik neyden oluşuyordu? Doxygen gibi bir şey mi?
Evet, eğer ;) Karpel SnagIt'te yaklaşık bir saat bunun üzerine. Yazım için özel olarak hazırlanmıştır.