"Sahte Kar" guzel bir tanimlama olmus. Vade degisimlerinde bazen zarar da olusabiliyor. Erhan hocam Matriksin bir sunum videosunu paylasmistiniz gecenlerde. Orada Kivanc bey tasarladigi sistemin vade degisimlerinde zarar yazmasini bir arti olarak gorurum diyordu. Bence bu bakis acisi yanlis. Esas sorun Matrikste yetersiz verilerle sistem gelistirmede israr etmek aslinda, herneyse. Vade degiminde flat olmayip, yeni vade fiyatini gapli acilmis gibi goren sistemlerin back test sonuclari guvenilmezdir.
VIP-X30 grafigi uzerinde yapilan back-testlerde sistemin muhakkak flata gecisi saglanmali. Bu en azindan sahte kar/zarar gormemizi engelleyecektir. Vade degisim etkilerinin tumunu kod kullanarak %100 ortadan kaldirmak pek kolay degil. Icinde bulundugumuz vade degisimi icin konusacak olursak VIP-X30 ile F_XU0301219 verilerine ayri ayri sahibiz. Her iki veri ile uretilen sinyallerin esitlendigi ana kadar sistemi beklemede (flat) tutmamiz mumkun. Ancak gecmis vadeler icin de aynisini yapabilmemiz, gecmis tum vadelerin grafik verilerine ayri ayri sahip olmamizla mumkun olabilir.
VIP-X030 gecmis verilerini kullanarak sistem tasarlamanin en buyuk handikabi bu. X30 spot verileri ile sistem tasarlansa bu sorunu asabiliriz gibi dursa da bunun nasil baska sorunlar yaratabilecegini 2018 Agustos ayinda spot vadeli makasina bakarak gorebiliriz.Eğer yeni vade grafiğine uyacak ve şort sinyalde devam edecekseniz. Bunu istatistiksel olarak geçmişe dönük her vade geçişinde hesapladınız mı ? belkide o şekilde bir uygulamada sisteminiz yıllık sadece 5000 puan üretiyordur ?
Vade sonu Flat, yeni/yakin vade sinyal esitligi vs gibi onlemler alinmadikca robotun VIP-X30 uzerinde calistirilmamasi gerektigini dusunuyorum. Bence vade degisiminde robot yeni vade uzerinden devam etmeli. Erhan hocamin vurguladigi sahte karlarin hatta sinyallerin etkileri gecmis tum vade degisimlerini tek tek incelenerek ortaya cikarilabilir. Ancak ne yaparsak yapalim vade degisim etkilerini %100 elimine etmek cok zor.
Yer İmleri