Mas Willy,
CAR = Compounded Annual Return ... sepengertian saya logika nya seperti ini: Initial Capital plus minus profit loss = net capital.
Net capital ini terus diakumulasi dari hasil trade... semakin besar nilainya semakin banyak kesempatan sistem untuk open trade.
Dan kalau sistemnya menguntungkan maka net capital dan CAR nya akan semakin gede...
Jadi yang mempengaruhi CAR adalah besar net capital yang tersedia dan max open pos... cmiiw.
Regards,
ES
Pak Eco,
Terus terang saya juga wondering kenapa ya CAR nya bisa beda banget antara WF sama MOCA. Kalau MDD sih saya liat menurut saya masih cukup konsisten. Kurang lebih ya di situ2 saja. Yang luar biasa CAR nya. Maaf, saya ga bermaksud mempertanyakan ya Pak. Saya malah bertanya2 kepada diri saya sendiri. Gmn caranya bisa dpt CAR sampe setinggi yang di hasil WF itu. Saya msh bergulat terus Pak.
Salam,
Willy
On 22/06/2011 11:32, Eco Syariah wrote:Mas Wisnu,
Terlampir WF dan Moca Test yg saya omongin, Back Test sudah saya kirim kemarin.
Parameter yg dioptimasi memang hanya 3... MaxPos, PosSize dan Volume.
Mungkin ada tambahan masukan ? saya masih penasaran.
Thanks,
ES
On Wed, Jun 22, 2011 at 11:23 AM, Wisnu Mobile <wisnu.working@gmail.com> wrote:
1. Bisa didalam satu AFL, bisa diluar. Saya prefer hanya bekerja dengan satu AFL dalam satu waktu, jadi semua filter saya masukkan ke AFL yang sedang saya uji/kembangkan.
2. Intinya common sense plus preferensi. Ada yang memilih sedikit trade tapi sangat aman, ada yang memilih masuk ke lebih banyak opportunity, dengan risk naik. Jadi jawabannya sangat bergantung kepada strategi dan ekspektasi yang digunakan.
3. Tidak perlu sampai mempengaruhi confidence. Ingat preferensi tadi, sifatnya unik antara individu. Yang penting, lolos semua test, bias free, executable, mestinya fine-fine saja.
Salam.
On Wed, Jun 22, 2011 at 10:55 AM, Willy B. Winata <wbwinata@gmail.com> wrote:
Pak Wisnu,
1. Filter JKSE yang Bpk maksud, itu sudah termasuk di dalam AFL nya dong ya. Dalam arti tidak dibuat 2 AFL kan?
2. Sistem yang sedang saya kembangkan cenderung termasuk tipe EOD, bukan intraday. Sampai saat ini, hasil BT menunjukkan selama setahun frekuensi trading hanya kurang lebih 170 kali. Lebih parah dari punya pak Eco, Pak. Itu berpotensi masalah ga ya? Sejauh ini kalau saya cek satu2 trading nya sih, kelihatannya logis ya. Kelihatannya sistem saya ini memang suka banget let the profit run beberapa bulan.
3. Saya tergelitik dengan statement Bpk yang mengatakan untuk sistem Bpk kalau mau moca 10K iterasi bisa hitungannya days. Wah, saya jadi agak down juga Pak. Apa sistem saya terlalu amat sederhana ya? Soalnya saya moca 20000 iterasi paling makan belasan jam pak, ga sampe 20 jam.
Salam,
Willy
On 21/06/2011 20:09, Wisnu Wijayanta wrote:Jangan terlalu kuatir dengan CAR kecil, Pak Eco.
1. Itu relatif antara satu trader dengan lainnya.
2. CAR/MDD anda sudah bagus.
3. Bisa jadi memang isunya entry logicnya sangat stringent, sehingga sangat jarang masuk ke sebuah opportunity. Kalau mau dikembangkan, saran saya, arahnya melonggarkan logic entry. Kalau MDD naik banyak tidak proporsional, artinya ada problem dalam logika risk management nya.
4. Benchmark index macam JKSE, saya pakai jadi filter IN/OUT market. Dari backtest kita bisa mengamati market seperti apa sistem perform buruk, kemudian sesederhan, menutup semua posisi di kondisi seperti itu. Boleh dicari menggunakan optimize. WF test mestinya lolos2 saja.
Salam.
From: Eco Syariah <esyariah@gmail.com>Sender: amibroker-4-bei@yahoogroups.comDate: Tue, 21 Jun 2011 19:30:45 +0700ReplyTo: amibroker-4-bei@yahoogroups.comSubject: Re: [Komunitas AmiBroker] Re: [Saham_Syariah] Potensi Masalah DalamMembangun SistemMas Wisnu,
Terima kasih atas pencerahannya... sekarang mulai jelas antara sistem yg spesifik dan yang general.
Dan kebetulan sistem yg sedang saya bangun menggunakan pendekatan general, hanya saja langsung ke intraday (should be EOD dulu).
Lagi-lagi hasilnya fantastik... lulus 1 kali WF 2000-2011 dengan score 90% 10% (biasa thn 2008) dan 2 kali Moca Test dgn 1000 iterasi (sekarang lagi running moca test ke 3 dgn 10.000 iterasi): Max 4.8 Min 4.6... MaxSysDD 4.43, hasil Moca ini tidak jauh beda dgn Back Test, herannya CAR cuma 21,31 ? ... saya curiga ke setup modal awal yg kecil dan hasil optimasi position size yg terlalu ketat, sehingga banyak sinyal yg tidak dapat dieksekusi ?
Bagaimana pun hasil2 test di atas merupakan big surprise buat saya dan sekaligus curiga ada yg ndak beres, jangan2 ada Pitfalls di bawah yang dilanggar ?... tapi karena ini best result dari sekian puluh sistem yg ditest, maka saya putuskan untuk coba ke real trading, dan tadi dpt sinyal PrepToBuy2 di sesi 1 pd KLBF, karena sistem ini intraday, maka saya eksekusi di sesi 1... alhamdulillaah sore hari naik 2 tick... dan kalau nanti exit dari KLBF/sistem ini menguntungkan, saya akan lakukan beberapa test ke real trading lagi sebelum mewisuda sistem ini.
Periode/indikator yang spesifik biasanya saya lakukan ke JKSE... kenapa ? karena pernah nemu sistem general yg profitable tapi memble di JKSE... waktu saya cek ke basic indikator yg saya pakai, ternyata sifat JKSE sangat tidak cocok dgn indikator tsb, mungkin juga periodenya harus dioptimasi... jd saya berkesimpulan untuk memperlakukan sistem yg spesifik ke JKSE... Menurut saya JKSE harus punya sistem sendiri karena dia saya jadikan patokan untuk eksekusi sinyal apapun pd sistem general untuk saham. CMIIW
Ini just sharing proses belajar dan mudah2an bisa memotivasi teman2 yang sudah dan akan ikut QTSD.
Thanks,
ES
On Tue, Jun 21, 2011 at 6:13 PM, Wisnu Mobile <wisnu.working@gmail.com> wrote:
Contohnya,
Seorang trader membangun sistem X, dengan fokus pada saham A, sampai ketemu periode optimum P (periode ini hanya contoh, banyak konteks spesifik lain).
Ada banyak problem dengan situasi ini:
1. Trader ini MUNGKIN menggunakan waktu yang sama panjangnya dengan trader lain untuk membangun sistem yang UMUM.
2. Trader ini, akan end-up dengan BANYAK sistem spesifik. Dengan argumen yang sometime, rasanya SO COMPELLING, saham punya periodenya sendiri-sendiri.
3. Sistem X ini TIDAK bisa diuji baku dengan baik. Karena, begitu dihadapkan pada data random yang tidak mirip A, performance system jatuh.
Point 3 ada yang implisit tetapi sangat penting, meskipun kita BISA mendesign sistem SEMPURNA untuk following saham A, semua itu adalah HISTORICAL performance. Karena TIDAK BISA diuji random, maka pendekatan sains, TIDAK PUNYA cara untuk menguji future predictive value dari sistem X ini.
Itulah contoh dari pendekatan spesifik, Pak Eco.
Sementara pendekatan general, kebalikan dari itu semua, tidak sempurna mengikuti lika-liku satu atau dua saham, tetapi perform ACCEPTABLE, ketika dihadapkan pada situasi seperti apapun.
Salam.
On Tue, Jun 21, 2011 at 5:14 PM, Eco Syariah <esyariah@gmail.com> wrote:
Thanks atas sarannya mas Wisnu.
Selama ini saya pribadi silau dengan angka2 test yg fantastis, tapi setelah baca artikel itu, disarankan untuk curiga-tion... dan benar saja berulangkali hasil test sepertinya overfitting.
Ya... rata2 hasil test fantastis dari sistem intraday dan sistem EOD hasilnya biasa2 saja dan malah memble.
Yang mas Wisnu maksud dengan "sistem yg spesifik dan general" itu seperti apa ya ?
Thanks,
ES
On Tue, Jun 21, 2011 at 4:51 PM, Wisnu Wijayanta <wisnu.working@gmail.com> wrote:
Semuanya penting, Pak Eco.
Supaya tidak jadi menakutkan, saran saya untuk mengambil jalan yang robust, sejak dari awal. Secara tidak sengaja, cara ini akan menghindarkan kita dari banyak pitfalls.
Contoh, pendekatan awal robust: menolak membuat sistem yang spesifik, dan memilih sistem yang bersifat general. Memang untuk dapat membangun persepsi tadi, perlu modal. Bisa dari membaca, atau kuat konsep statistik terlebih dahulu.
Efeknya: terhindar dari overfitting.
Saran kedua, mulai dari sistem EOD. Lebih bias resisten. Setelah jadi reflex, bolehlah mulai bangun realtime..
Terakhir, ketika melihat semua entry barriers tadi, supaya tidak malah counterproductive, bangun persepsi, itu semua cuma sebuah constant improvement.. :)Date: Tue, 21 Jun 2011 16:02:01 +0700ReplyTo: Saham_Syariah@yahoogroups.comSubject: Re: [Komunitas AmiBroker] Re: [Saham_Syariah] Potensi Masalah Dalam Membangun SistemMas Wisnu,
Dari semua item itu... mana yg harus kita prioritaskan mas ?
Thanks,
ES
On Tue, Jun 21, 2011 at 3:44 PM, Wisnu Wijayanta <wisnu.working@gmail.com> wrote:
Artikel yang sangat baik, Pak Eco. Terima kasih.
Salam.
From: Eco Syariah <esyariah@gmail.com>Sender: Saham_Syariah@yahoogroups.comDate: Tue, 21 Jun 2011 15:21:04 +0700ReplyTo: Saham_Syariah@yahoogroups.comSubject: [Saham_Syariah] Potensi Masalah Dalam Membangun SistemDear AmiBroker Lovers,
Di bawah permasalahan yg harus kita perhatikan dalam membangun sistem.
Sebagian sudah kita bahas, sebagian sepertinya belum ?
Regards,
ES
//==============================
Sumber: http://www.amibroker.org/userkb/index.php?s=price+bound
July 21, 2007
System-Design Pitfalls
When you are designing a real-time trading system, many things can go wrong. This post is intended to alert you to some of the potential pitfalls. However, that is all it can do. Only experience can teach you how to prevent them. Be aware that even the most experienced designers will make some of these mistakes repeatedly.
Since documenting all potential pitfalls with coding examples would consume too much time and space, they are, for now, only briefly commented on. Most of them will trigger a user response of "Oh yeah, that happened to me!". If you need a more detailed explanation you can post questions in a comment to this post
No rules exist to prove that a trading system is free from coding or logical errors. However, two indicators are fairly reliable in suggesting you may have a problem:
1) Your profits are simply too good to be true. In this case you have no choice but to work through the code line by line, trying to find lines of code that look into the future. If that doesn't reveal any errors, then you would have to inspect the plotted signals and trade list trade by trade.
2) Your system is very profitable trading Long but not Short, or Short buy not Long. When this happens, you may have an error in either the Long or Short parts of your code, and comparing the two sections will often reveal the problem (this only works for reversal systems). However, it could also be that your code is correct but that your trading principle is overly trend sensitive. This would almost certainly get you in trouble when the trend reverses. In this case no other cure exists than to re-think the basic system.When designing high-frequency trading systems, i.e., those whose trade durations are in minutes, everything changes, and many traditional procedures fall apart. Internet delays, data delays, bad data (spikes), temporary system freezes (Windows sometimes has a mind of its own!), lagging status reports, TWS problems, etc., all become critical issues that will prevent you from obtaining a close match with the Backtester.
Many of these problems will only surface when you start trading real money. Hence, the final stages of developing a trading system should always involve trading real money. Here is where the Interactive Brokers account simulator (paper-trading account) may be an indispensable tool since you can test your system in real time without committing real dollars. But, since the market does not see your trades, even paper-trading results will differ from trading real money. In general, the faster you trade, the greater your real-trading results will deviate from your backtest results. You should also be aware that commissions play a much greater role on performance of high-frequency trading systems because trade profits are smaller.
No matter how you go about it, troubleshooting a complex trading system will almost always be a tedious and boring job that could keep you busy for several days or weeks. If you find that certain problems continue to resurface, they are likely related to your personal development style, and you may be able to write some code that checks for these specific problems. See the Debugging category for some ideas.
The list below, which is not exhaustive, is presented to caution you that many areas can lead to problems. Some are obvious, while others may be expanded on as needed and time allows.
- High/Low precedence (contrary to EOD where the Backtester is unable to determine which came first, the entry/exit or the high/low, in realtime there can be no ambiguity in price precedence).
- Data Delays (real-time data may be delayed for various reasons and time periods (Internet delays, lack of quotes, packets vs. ticks, etc.).
- Low Liquidity (there may be no-volume trading periods).
- Data Holes (bars with no trades).
- Data Spikes (high spikes without volume may trigger trades).
- Data Padding (a bar without data may be padded).
- Premature Padding (the last bar may be a padded bar).
- Data Accuracy (prices you receive aren't always accurate).
- Random Slippage (you will rarely get the expected price).
- Breakout slippage (you will rarely get the Breakout price of your system).
- Survivorship Bias (companies that didn't do well and stopped trading won't be in your database, i.e., you are working above average stocks).
- Lucky Trades (a series of lucky trades may look like good performance).
- Parameter Over-Optimizing (optimized parameters are rarely stable over time).
- Design Over-Optimizing (frequent testing is like running an optimization and may be leading to false conclusions).
- Out–of-Bound Prices (with PriceBoundChecking turned ON, AmiBroker forces the trade price within the High-Low range, this may hide pricing errors).
- Price Rounding (prices may be rounded or truncated by the broker).
- Wrong Use of >= and <= (when using both <= and >= in the same statement, only the first equal condition will ever be seen).
- Comparing Floating Point Numbers (calculated values can have many decimal places, either round values or use the AlmostEqual()).
- Chart Justification (make sure you are looking at the Last bar!).
- System Mortality (no system will work forever).
- Sharing Trading Systems (sharing systems with other traders may result in over-trading a system).
- Being Duped by a Trend (a rallying ticker may make your system look like the HG (holy grail).
- Tricking AmiBroker (AmiBroker has its limits; it is possible to write esoteric code that will produce wrong results).
- Order Visibility (placing your order for every trader to see may influence the orders they place).
- Making the Market (extreme example: if you place a MKT order during a no-trading period you will change the chart).
- Window/Pane Execution Order (when passing variables between panes or windows do not assume that they execute in a fixed order, more).
- Trading at the Open (order execution at the start/end of day is different from midday because of volatility and data delays).
- IB Data Snap Shots (snapshots are only representative of prices traded).
- Trade Delays (make sure you understand your trade delays when backtesting).
- EOD and Intraday Gaps (There is no time interval in RT gaps).
- Time Zones (make sure your computer and database timezones are properly set).
- Very Short Time-Frames (prices jump and are less contiguous).
- Setting LMT Prices (consider rounding for faster order executions).
- 24-Hour vs. RTH (Regular Trading Hour) Backtesting (extended hours can rarely be traded like RTH due to huge bid/ask spreads and low volume).
- Static Variables Naming (use unique names for your static variables).
- Incorrect Computer Time (computer time offset from market time can cause real problems).
- Look-Ahead Problems (not all look-ahead coding problems are obvious).
- Buy/Sell Precedence in a Loop (be aware that AB and custom AFL loops enforce a Buy/Sell priority).
- RT Candle Discrepancies (RT Candles may be different from later backfills, especially in the opening print).
- Bars Loaded (consider bars-loaded with respect to execution speed and loops).
- Signal lifetime (signal strength quickly decays over bars in high frequency trading).
- SameBarExits (Sell signals may act as a qualifier for Buy signals).
- Designing systems based on High and Low triggers (these may fill in the Backtester but not in real trading). more…
- Using the wrong CommissionMode and/or CommissionAmount can make any system look good, or bad…
- Using zero TradeDelays is OK if you code the delays in your system's code, else you may be looking into the future.Edited by Al Venosa
Filed by Herman at 6:25 pm under Real-Time System Design
April 28, 2007
Price Bound Checking
When you start to design your own trading system, you will soon realize the need to custom define the BuyPrice, SellPrice, ShortPrice, and CoverPrice. Similarly, you may want to set your trade delays using the in-code function SetTradeDelays(d,d,d,d). Such hard-coded definitions will override the default trade prices and delays set in the Automatic Analysis (AA) Settings, and this will prevent you from inadvertently using the default settings. The problem is that defining your own price arrays increases the risk of introducing pricing errors, such as Price Bound Errors.
AmiBroker provides a function called SetOption("PriceBoundChecking",TRUE/FALSE) to Enable/Disable Price Bound Checking. Enabling this option will adjust prices so that they fall within the High-Low range and mask your pricing errors. The problem, of course, is that in practical trading these prices are impossible to trade, and your Backtests will not reflect realistic conditions. The best way to handle this is to turn Off Price Bound Checking and write your own error detection code. The code below checks your trade prices for Out of Bounds errors, displays the number of errors it finds, and plots a red marker (bar) at the bottom of your chart where the error occurs.
SetOption("PriceBoundChecking",False); BuyError = ( BuyPrice > H OR BuyPrice < L ) AND Buy; SellError = ( SellPrice > H OR SellPrice < L ) AND Sell; ShortError = ( ShortPrice > H OR ShortPrice < L ) AND Short; CoverError = ( CoverPrice > H OR CoverPrice < L ) AND Cover; PricingErrors = BuyError OR SellError OR ShortError OR CoverError; Plot(PricingErrors ,"Bound Errors",colorRed,styleArea|styleOwnScale,0,10); Title = "# Price Bound Errors: "+NumToStr(Cum(PricingErrors),1.0,False)+"\n";Edited by Al venosa
__._,_.___
Apabila membutuhkan software AmiBroker, Realtime Intraday Data & Pelatihan silahkan kontak : Dendo Valentino | Cell : 08159304868 | e-mail: amibrokerfreak{at}yahoo.co.id | YM id : dendov | http://www.facebook.com/dendo.amibrokerfreak | http://www.amibroker-4-bei.org
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
Posts
No comments:
Post a Comment