"Python ve MQL5'te bir robot geliştirme (Bölüm 2): Model seçimi, oluşturulması ve eğitimi, özel Python sınayıcısı" makalesi için tartışma - sayfa 2

Yeni yorum
[Silindi]  

Yine de sıra fiyatları en iyi çipler olarak ortaya çıkıyor.

Eskiden durağan olmamaları nedeniyle şüpheciydim. Ancak bazı manipülasyonlardan sonra bu özellikler üzerinde iyi modeller çıkarmaya başladım.

Yani cehaletten bilgi, bilgiden de cehalet doğuyor :)

 
Ivan Butko #:
Sonuçlar olduğunda iyi bir motivasyon!
Ve fark ettiğim gibi, bu bir hafta değil, bir ay değil, normal bir yıllık çalışma

Çok teşekkür ederim! Evet, bu beni çok motive ediyor! Araştırmaya devam edeceğim) Yine gece oldu, yanımda bir fincan kahve ve kod fikirleri var)))))

 
Maxim Dmitrievsky #:

Genel olarak, sıra fiyatları en iyi cipsler olarak ortaya çıkıyor.

Eskiden durağan olmamaları nedeniyle şüpheciydim. Ancak bazı manipülasyonlardan sonra bu özellikler üzerinde iyi modeller çıkarmaya da başladım.

Yani cehaletten bilgi, bilgiden de cehalet doğar :)

İşte böyle denenmiş bir tür, kayınvalidem 15+ yıllık deneyime sahip bir tüccar, hacimlerde fiş yapmak gerektiğini söyleyip duruyor))) https://www.mql5.com/tr/code/50133

Индикатор Price / Volume
Индикатор Price / Volume
  • www.mql5.com
Одна из простых фич для машинного обучения
[Silindi]  
Yevgeniy Koshtenko #:

Bu benim denediğim türden bir şey, kayınvalidem 15+ yıllık deneyime sahip bir tüccar, hacimlerde fiş yapmamız gerektiğini söyleyip duruyor))) https://www.mql5.com/tr/code/50133

Evet, daha sık volatilite eklendiği doğrudur (örneğin std göstergesi), ancak fazla bir şey vermez. Veya artışlar oynaklığa bölünür.

 

Eugene, makalelerinizden ML'yi ticaretle ilgili olarak incelemeye başladım, bunun için çok teşekkür ederim.

Aşağıdaki noktaları açıklayabilir misiniz?

label_data işlevi verileri işledikten sonra, hacmi önemli ölçüde azalır (işlevin koşullarını karşılayan rastgele bir çubuk kümesi elde ederiz). Daha sonra veri birkaç fonksiyondan geçer ve biz onu eğitme ve test örneklerine böleriz. Model, eğitim örneği üzerinde eğitilir. Bundan sonra, ['labels'] sütunları test örneğinden çıkarılır ve modeli tahmin etmek için değerlerini tahmin etmeye çalışırız. Test verilerinde kavram ikamesi yok mu? Sonuçta, testler için label_data işlevini geçen verileri kullanıyoruz (yani gelecekteki verileri dikkate alan bir işlev tarafından önceden seçilen sıralı olmayan çubuklar kümesi). Ve sonra test cihazında, anladığım kadarıyla, anlaşmanın kaç çubukla kapatılacağından sorumlu olması gereken 10 parametresi var, ancak sıralı olmayan bir çubuk setimiz olduğundan, ne elde ettiğimiz net değil.

Aşağıdaki sorular ortaya çıkıyor: Nerede yanlış yapıyorum? Neden tüm çubuklar >= FORWARD testler için kullanılmıyor? Ve tüm çubukları >= FORWARD kullanmazsak, geleceği bilmeden tahmin için gerekli çubukları nasıl seçebiliriz?

Teşekkürler.

 
Harika bir çalışma, çok ilginç, pratik ve gerçekçi. Sonuçları olmayan sadece teoriden ibaret olmayan, gerçek örneklerle bu kadar iyi bir makale görmek zor. Çalışmalarınız ve paylaşımlarınız için çok teşekkür ederim, bu seriyi takip ediyor ve dört gözle bekliyor olacağım.
 
Eric Ruvalcaba #:
Harika bir çalışma, çok ilginç, pratik ve gerçekçi. Sonuçları olmayan sadece teoriden ibaret olmayan, gerçek örneklerle bu kadar iyi bir makale görmek zor. Çalışmalarınız ve paylaşımlarınız için çok teşekkür ederim, bu seriyi takip ediyor ve dört gözle bekliyor olacağım.

Çok teşekkürler! Evet, bu makalenin ONNX'e çevrilerek genişletilmesi de dahil olmak üzere, önümüzde hala birçok fikir uygulaması var)

 
Özellik seçimi için RandomForestClassifier ve model sınıflandırması için XGBclassifier kullanmanın özel bir nedeni var mı?
 

Kritik kusurlar:

  1. Veri sızıntısını önleme ile ilgili sorunlar:
    • augment_data() işlevi, eğitim ve test setleri arasında ciddi veri sızıntısı sorunları yaratır
    • Artırım, farklı zaman dilimlerinden gelen verileri karıştırır
  2. Performans değerlendirme metodolojisindeki hatalar:
    • Model testi gerçek piyasa koşullarını dikkate almaz
    • Model gelecekteki veriler üzerinde eğitilir ve kabul edilemez olan geçmiş veriler üzerinde test edilir
  3. Koddaki teknik sorunlar:
    • generate_new_features() işlevi özellikleri oluşturur ancak bunları döndürmez (orijinal verileri döndürür)
    • test_model() X_test.iloc[i]['close'] kullanır, ancak özellikler dönüştürüldükten sonra 'close' eksik olabilir
  4. Tutarsız veri işleme:
    • Veriler farklı şekillerde iki kez etiketlenir ( markup_data() ve label_data() )
    • Kümeleme sonuçları (küme) daha fazla eğitimde kullanılmaz
  5. Ticaret stratejisinde metodolojik sorunlar:
    • Uyarlanabilir strateji yerine 10 çubuktan sonra statik çıkış
    • Risk yönetimi yok (basit bir stop-loss dışında)
    • İşlem maliyetleri dikkate alınmaz (basit spread dışında)
  6. Etkin olmayan doğrulama:
    • Modelin zaman yapısı dikkate alınarak geçmiş veriler üzerinde doğrulanmaması (ileriye dönük analiz)
    • Çapraz doğrulama, zaman serisi özgüllüğü dikkate alınmadan zaman serilerine uygulanır

İyileştirme için öneriler:

  1. Veri sızıntısını ortadan kaldırın - verileri zaman içinde kesin olarak ayırın
  2. Uygun ileri yürüme doğrulaması uygulayın
  3. Kayma ve komisyonları dikkate alarak daha gerçekçi testler uygulayın
  4. Giriş/çıkış pozisyonlarının mantığını kesinleştirin
  5. Zaman serisine özel yöntemler kullanın
12
Yeni yorum