Sistem Karşılaştırma 2

[3c1a]

https://twitter.com/erhanacikgoz1/st...308322304?s=20

Erhan hocam videonu buyuk saskinla izledim. Anlattigin yaklasimin neredeyse birebir aynisi uzerinde son 1 haftadir yogun sekilde calisiyorum . Videonda bahsettigin rakamlar optimizasyonla ulastigim en iyi sonuc veren degerlere cok yakin. Yarim yamalak kod bilgimle bu yaklasimi koda dokmeyi basardim. Kendi sistemim uzerinde yaptigim testlerde anormal bir sonuc ile karsilasmadim ancak kodumda bazi eksik acik noktalar olabilir. Ben bu satirlari yazarken @Tiberius ustadin ayni yaklasimi belki de dakikalar icinde koda dokup twitterdan sonucunu paylasmis bile. Acikcasi ustadin kodunu gormek isterim.

Su ana kadar ulastigim sonuclar heycan verici. Uygulamam su sekilde: Ham sistemin getiri egrisi 9000 puan drawdown'a ulastigi zaman devereye gir girdigin noktadan itibaren ham getiri 11,000 puan artarsa devreden cik ve bir daha ki 9000 puanlik sarkmaya kadar flat bekle.


Getiri: Ham sistemin getiri egrisi.
Gmax: Ham sistem getirisi yeni zirve gordukce artan ve bunu saklayan liste.
DD: DrawDown, Gmax ile anlik Getiri egrisi arasindaki fark.
YeniGetiri: Sadece filtrelenmis islemlerin getirisini gosteren egri. (35 puan kayma+kom dusulmus)

13 yillik veriyle ulastigim sonuclardan bahsedeyim. Yukarda gorulen ham sistemin 35 puan kayma+kom dusulmus MaxDD degeri 13,750 puan. Bunu baz alip 9,000 getiri sarkmasinda (DrawDown) devreye giren turev sistemin kayma+kom dusulmus MaxDD degeri ise 7,490 gibi benim su ana kadar gorup gorebildigim ulasabildigim en dusuk MaxDD degeri. Bunlar olurken islem sayisi 4 te 1 e Getiri ise 3 te 1 e inmis. Bu iki sistemi esit lot paylastirarak kullanmak istesem birlesik MaxDD 9,248 puana iniyor. Bu sonuclar burada defalarca tekrar ettigimiz kaldiraci artirmak icin MaxDD yakin bir getiri sarkmasini beklemeli tezinin de dogrulugunu gosteriyor.

Saf puan yerine VIOP un kapanis degerine gore dinamik DrawDown testlerim de oldu, bir nevi % sel DrawDown. Bugunun 9,000 puan DrawDown parametresi VIOP30 50,000 iken 4,500 e dusuyor. Bu durumda islem sayisi artiyor ve MaxDD biraz yukseliyor, ozellikle 2012 de cok uzun bir sure aktif kalma durumu olustu.

Bu yaklasim her sistemde ayni sonucu vermeyebilir. Ham sistemin getiri egrisinin lineere yakin olmasi verimi artiriyor.

Daha once eski forumda yine erhan hocamin mimarlarindan oldugu getirisi egrisinde toma uygulama yaklasimini ve benzerlerini denemis ancak maxdd degerinde kayda deger bir iyilesme gorememistim.

Bu yaklasimi farkli kilan bence su; getiri egresinin yonunu ne zaman asagi cevirecegini tahmin edemeyiz bu piyasanin yukselisini veya dususunun ne zaman sonlandiracagini tahmin etmeye benzer. Ancak egrideki sarkma MaxDD degerine yaklastikca KZdeki yukari donusu cok daha dusuk bir risk ve yuksek bir yuzdeyle tahmin etmek mumkun.

[kenten]

birsürü insanın aklına aynı şeylerin gelmesinin insan psikolojisiyle ilgili olduğunu düşündünüzmü?
genel geçer ve çok bilinen bir kavramdır.
kazandıkça kazancı kaybetme korkusu sarar ve sınırlamaya başlarız ama kayıpta kaybı sınırlamayı düşünmez birebir noktasına gelmeyi bekleriz. üzerinde bolca akedemiden trader dünyasından kafa patlatılmış konudur
merak eden "loss aversion" prospect theory" "overnight test" "martingale bet" falan arayabilir

[Hector Salamanca]

iyi işleyen bir kayıp kaçış stratejisi yazmak çok önemli ama bunu kz eğrisine bakarak yazmak bana göre tam bir saçmalık

neden kulağımızı tersten tutalım? evet piyasanın saçma sapan hareketleri olabilir, fiyata bakarak stratejisini yazar beklersin ama bunu kz eğrisine bakarak yapmak için fiyata ve asıl sinyallere göre işleyen asıl stratejilerde aciz kalmak gerekir. yani pes edenlerin son umudu olabilir sadece.

[oguzvortex19]

Merhabalar bu sayfayı yeni gördüm güzel paylaşımlar var cepten 2500sayfanın 1500 sayfasını okudum.
Erhan beyi UVY topiğinden tanırım çalışkanlığı ve azmi hala devam ediyor,

Kendime geleyim 1yıldan biraz fazla önce bende sistem kurmaya başladım ağustos ayından itibarende gerçek işlemler yapmaya başladım.
Formülü matrikste değil tradingviewde yazmıştım ve spot xu30a göre kurmuştum faiz yürütmesini formulle ekleyerek viopda işlem yapıyordum.
Tabi tradingview üzerinden işlem yapacak platform olmadığı için işlemleri manual yapıyorum, saatlik barda sinyal verdiği için ayda 1 sinyal verdiğide oluyordu günde 1 de , o yüzden sorun olmuyordu. Yine de otomatike geçsin diye matriks teknik servisden destek aldım 2 3 defa görüştük belki ben anlatamadım belki yazılım dili farklı geldi bir türlü otomatiğe dönüştüremedik.

Bu yüzden Ağustostan beri manual işlem yapıyorum işlemler 5er kontratla.
Burada daha çok dakikalık 5 10 15dklık sinyaller olduğu için kaplumbağa sıtayla kalıyorum yanınızda.



Sistem geliştirirken yapılan hatalara değinmek istiyorum.

Different time frameden sinyal alırsanız çok dikkatli olun ister istemez repaint olabiliyor.

Backtestte yüksek kar çıkması için sinyalleri düzeltmek ileride karlılığı törpüleyebiliyor onun yerine mantığınıza uydurarak sistem kurmaya çalışın. Geçmişr göre getiri düşsede sapmayı azaltır sürdürebilir olur.

Benim sinyali saatlik oluşturmamdaki sebeblerden biri buydu.
Böylece bir pozu 3000 puan eksi ile kapatırsam bunu bile mantıklı olarak kapattığımı kabul edebiliyorum.


YTD

[mossin]

uzun zamandır girmiyordum foruma, kendimi tanıtayım, twitter da mossin nagant , gerçek ismim ise Tufan.
Metastock-V11, matriks ve ideal tecrübelerim oldu. 2 senedir ideal kullanıyorum.

dün akşam Erhan bey ile konuşurken bana ideal sistem karşılaştırma sayfasını okuyun dedi,
sabaha kadar okudum, saat 3 gibi yattım , 15 dk sonra dayanamayıp kalkıp yine okudum.
Mükemmel bilgiler var, bazılarını okurken kendimi geri zekalı gibi hissettim, neden ben düşünemedim diye.

1-hisse üzerinde sistem tasarlayıp al sat yaptırıyordum, ama okuduklarıma istinaden tek taraflı piyasada bunun gerçekten bir anlamı yokmuş onu anladım.

2-Tiberius ve erhan hocamın tweeterda ki mesajlarını okudum, sonra viob için bir sistem yapayım dedim. çok da başarılı görüyordum taa ki Erhan hocam kayma faktörünü ve bileşik getiri eğrisinde hesap yaptırıncaya kadar.

3- olaylara bakış açım bütünüyle değişti, yüksek işlemli sistemlerden güzel getiriler elde ediyordum sanıyordum ama işin rengi öyle değilmiş.

4-Fiziksel olarak işlemlerde bir başarısızlık olmasa da henüz başlamadığım viop sisteminin mantığının boşa gittiğini düşününce mental olarak ciddi manada kendimi başarısız hissediyorum.

5-Sn Tiberius hocam, tweeter da butterworth filtresi ile sinyali gürültüden arındırmak şeklinde bir paylaşımınız var, ben gürültüleri bu şekilde arındırıyorum, benzer bir yöntem ile, fakat bu yükselen piyasada iştah kaybolduğunda fiyat yükselmeye devam etmesine rağmen bu osilatör sistemleri direk salınıma başlıyor, sistem salınım ihtiyacı duyuyor. bunu engelleyemedim. buda benim çok işlem yapmama sebep oluyor. bir öneriniz var mıdır?

6- tecrübe yediğimiz kazıklardır diye biliriz ve ben kendimi yeterince kazık yedim sanıyordum, yanılmışım, gerçekten çok daha fazla çabalayıp, çok daha fazla uğraşıp, total de daha fazla kazık yiyip bugüne başarı ile gelmiş tüm arkadaşlarımı hocalarımı tebrik ediyorum.

7- sistem konusunda tavsiyesi olan varsa dinlerim.

8- İYİ Kİ VARSINIZ.

[Hector Salamanca]

Different time frameden sinyal alırsanız çok dikkatli olun ister istemez repaint olabiliyor.

Different time frame ile kullanılan time frame arasında repaint açısından hiç bir kullanım farkı yoktur.
canlı bar üzerinden hesaplanan indikatörler nasıl repaint yapıyorsa aynısı Different time frame içinde geçerlidir.
yani doğru kullanılırsa hiç bir zaman repaint'e sebep olmaz! canlı üst frame barını kullanırsanız repaint yapar elbette.
doğru kullanımı şudur; üst frame bar tarihleri eşitlemesi yapmadan önce 1 bar kaydırılarak yeni listeye atılmalı tarih eşleştirme bundan sonra yapılmalıdır. tüm platformlar için doğru kullanımı budur.

ideal için örnek vermek gerekirse:

//Günlük WaveTrend ve Ortalaması
var WaveTrendG = User.WT(Sistem, V_G, 10 ,21 );
var WaveTrendGMA= Sistem.MA(WaveTrendG , "Simple", 4 );

//1 Kaydırma ve kesişme kontrolünü yapıp sonucu döndürme
var WaveTrendG_1 = Sistem.Liste(WaveTrendG.Count, 0);for (int i = 1; i < WaveTrendG.Count; i++){ WaveTrendG_1[i] = (WaveTrendG[i-1] > WaveTrendGMA[i-1] && WaveTrendG[i-1] > WaveTrendG[i-2] ? 1:0); }

//Tarih eşitleme
var WTG = Sistem.DonemCevir(Sistem.GrafikVerileri, V_G, WaveTrendG_1);


ve artık istenilen alt bar grafikde if(WTG[i]==1) şeklinde repaint ihtimali olmadan kullanılabilir.

[mk4588]

Different time frame ile kullanılan time frame arasında repaint açısından hiç bir kullanım farkı yoktur.
canlı bar üzerinden hesaplanan indikatörler nasıl repaint yapıyorsa aynısı Different time frame içinde geçerlidir.
yani doğru kullanılırsa hiç bir zaman repaint'e sebep olmaz! canlı üst frame barını kullanırsanız repaint yapar elbette.
doğru kullanımı şudur; üst frame bar tarihleri eşitlemesi yapmadan önce 1 bar kaydırılarak yeni listeye atılmalı tarih eşleştirme bundan sonra yapılmalıdır. tüm platformlar için doğru kullanımı budur.

ideal için örnek vermek gerekirse:

//Günlük WaveTrend ve Ortalaması
var WaveTrendG = User.WT(Sistem, V_G, 10 ,21 );
var WaveTrendGMA= Sistem.MA(WaveTrendG , "Simple", 4 );

//1 Kaydırma ve kesişme kontrolünü yapıp sonucu döndürme
var WaveTrendG_1 = Sistem.Liste(WaveTrendG.Count, 0);for (int i = 1; i < WaveTrendG.Count; i++){ WaveTrendG_1[i] = (WaveTrendG[i-1] > WaveTrendGMA[i-1] && WaveTrendG[i-1] > WaveTrendG[i-2] ? 1:0); }

//Tarih eşitleme
var WTG = Sistem.DonemCevir(Sistem.GrafikVerileri, V_G, WaveTrendG_1);


ve artık istenilen alt bar grafikde if(WTG[i]==1) şeklinde repaint ihtimali olmadan kullanılabilir.

Birkaç yerde daha different time frame lerle işlem yapanları gördüm. Hakikaten mantıklı mı merak ediyordum hep? Tabi herkesin ona uygun bir kurgusu vardır illa ki ama...

[oguzvortex19]

Different time frame ile kullanılan time frame arasında repaint açısından hiç bir kullanım farkı yoktur.
canlı bar üzerinden hesaplanan indikatörler nasıl repaint yapıyorsa aynısı Different time frame içinde geçerlidir.
yani doğru kullanılırsa hiç bir zaman repaint'e sebep olmaz! canlı üst frame barını kullanırsanız repaint yapar elbette.
doğru kullanımı şudur; üst frame bar tarihleri eşitlemesi yapmadan önce 1 bar kaydırılarak yeni listeye atılmalı tarih eşleştirme bundan sonra yapılmalıdır. tüm platformlar için doğru kullanımı budur.

ideal için örnek vermek gerekirse:

//Günlük WaveTrend ve Ortalaması
var WaveTrendG = User.WT(Sistem, V_G, 10 ,21 );
var WaveTrendGMA= Sistem.MA(WaveTrendG , "Simple", 4 );

//1 Kaydırma ve kesişme kontrolünü yapıp sonucu döndürme
var WaveTrendG_1 = Sistem.Liste(WaveTrendG.Count, 0);for (int i = 1; i < WaveTrendG.Count; i++){ WaveTrendG_1[i] = (WaveTrendG[i-1] > WaveTrendGMA[i-1] && WaveTrendG[i-1] > WaveTrendG[i-2] ? 1:0); }

//Tarih eşitleme
var WTG = Sistem.DonemCevir(Sistem.GrafikVerileri, V_G, WaveTrendG_1);


ve artık istenilen alt bar grafikde if(WTG[i]==1) şeklinde repaint ihtimali olmadan kullanılabilir.

Teşekkürler bilgi için sayın hector.

Ben bar kapanışından sonrakini kullandım canlı bar kullanmadım, Benim yaptıklarımda repaint oldu ben ondan dolayı dtfi bıraktım 1hlikte işlemmyaparken 3 saatlikten aldığın sinyalle onayla deyince 1 bar kaydırmak yine de kurtarmaz diye düşünüyorum belki 3 bar gerekir o da verimli olmaz. tradingview üzerinde yapmıstım.