eklemdım hocamOriginally Posted by siradanhisseler
başarılı bir sistem tüm perıyotlarda düzenli getiri üretmeli kısmına katılıyorum genel anlamda öyledir fakat sistemler artık biraz daha gelişmiş çoğu zaman aynı sıstemın bır kopyasını 1 dakıkalık perıyota gıydırıp test edemıyorsunuz. periyotu 1 e indirmek iç taraftakı matematiği bozuyor. ancak dediğim gibi ne kadar düşük periyot bence avantajın o derece artması demektir. bu 20 dakıkalık sistemin daha kötü oldugunu göstermez. 20 kdaıkalıktada 30 dakıkalıktada harika sıstemler üretilebilir. Parada kazandırır. Bendede var kazandırıyorlarda ben potansıyelden bahsettim. sistemin hareket aralığını arttırıyorsunuz daha düşük periyotlar da.
sistemin resmini attığım kısımın kz bölümünde işlem maliyetleri dahil yazıyor pf oranı ancak ne kadar doğru hesapladı ölçmedim. Pf oranı önemli bir değer iken bunun yorumlanmasının da en az oran kadar önemli oldugunu düşünüyorum az işlem sistemlerin pf oranı genelde yüksek ilerleyen yıllarda düşer bu oran örneğin:
10 yıllık veri var elimizde ve yavas bir sistem yarattık toplam işlemi 100 olsun pf oranıda 5 çıksın. başarılı işlem %30 olsun.
aynı veri ile hızlı sistem yarattık 1000 adet işlemi var pf oranı 1,50 olsun başarılı işlemde %30 olsun.
Şimdi baktığımız zaman yavaş sistem daha iyi görünür pf si 5 işlem maliyetleri düşük tutar az işlemli oldugundan.
Fakat veriyi uzat ve yavas sistemi toplamda 1000 adet işlem açacak sekılde veriyi uzat pf oranı büyük ihtimalle 1,5 seviyesine kadar inecektir. işlem sayıları eşiit iken pf oranını ölçmeliyiz. aynı şekilde çok işlemli sistemin ilk 100 işlemini baz aldıgınız da da pf oranı mevcut orandan daha büyük çıkacaktır.
Bu durumları test ettim bu arada veri ne kadar çok ise ve açılan işlem ne kadar fazla ise istatistiklerin sapma ihtimali okadar düşüyor. TÜm istatistikler pf oranı karlı işlem % si üretlilen ortalama puan ne kadarlık bir verinin ve ne kadar çok işlemin yeterli istatistikleri verdiği ise henüz ben bilmiyorum. Bildiğim tek şey olabildiğince fazla veri ve olabildiğince çok işlemle sistem yaratmak. Tabi maliyet unsurunu düşünerek.
Sizde bu konudakı deneyımlerınızı aktarın böylece yeni deneyimlerde kazanabılırız. Yani bunun doğrusu şudur derken arkasına sıgındıgınız doneyı araştırmayı deneyımı bıze aktarın bu yanlıstır dıyıp çekilmeyin de mesela anlatın bıze neden oyle oldugunu olması gerektıgını.
Size katılıyorum fakat optimizasyona bakış açım farklı benım. aslında tüm sistemler optimizedir back test yapıyoruz cunku back test ne demek parametrelerı yazıp koyuyoruz geçmişe bakıyoruz iyi görünüyorsa kullanıyoruz bunun optimizasyondan farkı ne ? ha elle optımıze etmışım ha bilgisayara optimize ettirmişim. belkide tesadufen yazdıgım parametreler bilgisayara optimize ettirsemde en iyi değerlere denk gelmiş olabilir. Yani tesadufen en iyi değerleri yazıp kullanmış olabilir halbukı bılgısayara optımıze ettirmemiştim. rasgele parametre girdim ve iyi sonuc verdi diye kullandım. Bir optimizasyon söz konusu değil ama nerden bılıyorsun ? belkide seçtiğin parametreler en iyi optimizasyon parametresi. O sebeple ben tüm back testi yapılan sistemlerin optimize sistemler oldugunu düşünüyorum. kafanda bir strateji vardır bunu kurup back testine hiç bakmadan kullanacaksan ozman optimze etmemiş olursun bu kezde sisteminin ne kadar sağlıklı calıstıgı konusunda hiçbir fikrin olmaz. Aynı zmanda yazdıgın stratejının en optimize değerlerini kullanıyor olma ihtimalin herzman var olacaktır. Optimizasyon cok geniş çaplı bir konu burada anlatmak ıcın aslında.
Sizi tanımıyorum bu sebeple çok büyük konuşmaktan çekiniyorum. Sistem olayı ciddi tecrübeler barındıran bır yer her türlü tecrübeye açık olmayı gerektiriyor. Bence biraz kendınızden bahsedın sistemcilik işinde ne kadar süredir varsınız bu işte ne kadar vakit geçirdiniz ne tür badireler atlattınız kaç yıllık veri ile sistem geliştiriyorsunuz hangi platformu kullanıyorsunuz. Birazdaha kendiniz hakkında bilgi verebilirseniz taşlar daha çok yerine oturacaktır.
Alıntı yaparak yanıtla
Yer İmleri