Technische Analyse Terug naar discussie overzicht

prt backtesting trailing stop

1. [verwijderd] 31 augustus 2012 15:46

   auteur info

   • [verwijderd]

     Lid sinds: 01 jan 0001

     Laatste bezoek: 01 jan 0001

   • Aanbevelingen

     Ontvangen: 0

     Gegeven: 0

   •    Aantal posts: 0

   Iets wat me al langer dwars zit bij ProRealTime;
   
   Als ik een trailing stop wil gebruiken in een backtest, dan komen er veel te goede resultaten naar voren. Als ik vervolgens de trades langsloop zie ik al snel dat dit komt omdat de backtest niet ziet wat er binnen een bar is gebeurd. Het komt bijvoorbeeld best vaak voor dat de backtest een positieve trade noteert terwijl als je intraday goed gaat kijken naar het koersverloop dat het juist een verlies zou zijn omdat het koersverloop in eerste instantie de verkeerde kant op gaat.
   
   Nu kan dit wel deels voorkomen door pas op het einde van de bar te laten triggeren maar ik vind dit geen oplossing. Kan je niet op een slinkse wijze op tick/tick basis die trailing stop laten controleren? Bij andere software lijkt dit namelijk wel te kunnen.
2. novital 4 september 2012 19:10

   auteur info

   • novital

     Lid sinds: 15 nov 2004

     Laatste bezoek: 15 okt 2024

   • Aanbevelingen

     Ontvangen: 161

     Gegeven: 62

   •    Aantal posts: 1.494

   Zo werkt PRT nu eenmaal. Je kunt er slechts mee handelen op de tijdsgrenzen van de bars, open of slot. Ik zie dat niet als een groot bezwaar.
   Met welke frequentie werk je eigenlijk? Dag, uur, kwartier? Als een stop getriggerd wordt tijdens een bar, dan wordt daarop pas actie ondernomen bij het einde van die bar of bij het begin van een nieuwe. Een stop kan afgaan binnen een barperiode, maar de koers kan ook weer opveren en zo kan die zelfde bar toch boven een long stop sluiten.
   
   Je zegt ‘veel te goede’ resultaten. Komt dat alleen door het bovenstaande fenomeen? Dat lijkt me overdreven. ‘Veel te goede’ resultaten kun je door over-optimalisatie en te strakke curve fitting redelijk makkelijk genereren op in-sample perioden. Om die reden mag je handelssystemen enkel en alleen beoordelen door middel van objectieve (o.a. statistische) toetsen op je out-of-sample resultaten.
   
3. [verwijderd] 4 september 2012 22:00

   auteur info

   • [verwijderd]

     Lid sinds: 01 jan 0001

     Laatste bezoek: 01 jan 0001

   • Aanbevelingen

     Ontvangen: 0

     Gegeven: 0

   •    Aantal posts: 0

   quote:

   schreef:

   Als een stop getriggerd wordt tijdens een bar, dan wordt daarop pas actie ondernomen bij het einde van die bar of bij het begin van een nieuwe
   

   Dit is niet helemaal waar.
   Als je kiest voor "direct wanneer getriggerd" wordt direct verkocht, IN de bar.
   Je kan inderdaad kiezen voor "op slotkoers huidige bar" dan wordt pas gecontroleerd op het einde van de bar.
   Maar hoe realistisch is dat? Een trailing stop of een stoploss laat je (ik wel) meestal realtime meelopen. Wordt deze geraakt, verkoop je.
   
   Het fenomeen doet zich altijd voor, welk timeframe je ook gebruikt. Wel gebeurt het alleen als je een relatief kleine (trailing) stop gebruikt waarbij het risico aanzienlijk is dat deze binnen de bar zal worden geraakt.
   
   Ik heb niets geoptimaliseerd. Als ik normaal een winstgevend systeem (932%) heb met een drawdown van 20.000 euro (wat ik veel te hoog vind) en een max winsttoename van 99.000, daarna een trailing stop inzet voor 200 euro, krijg ik (totaalwinst 268%) opeens een drawdown van slechts 1030 en een max winsttoename van 26.000??? Zo wil ik ook wel geld verdienen maar dit is dus nep.
   
   www.uploadplaatjes.nl/img/n/676480.png
   
   www.uploadplaatjes.nl/img/n/676478.png
4. novital 4 september 2012 22:17

   auteur info

   • novital

     Lid sinds: 15 nov 2004

     Laatste bezoek: 15 okt 2024

   • Aanbevelingen

     Ontvangen: 161

     Gegeven: 62

   •    Aantal posts: 1.494

   quote:

   Psylo schreef op 4 september 2012 22:00:

   [...]
   
   Dit is niet helemaal waar.
   Als je kiest voor "direct wanneer getriggerd" wordt direct verkocht, IN de bar.
   

   Je hebt gelijk. Ik vind het onder de button 'Stops'.
   Ik maak geen gebruik van die PRT stops en was het bestaan ervan alweer lang vergeten. Ik definieer mijn stops altijd zelf in de script.
   
   verder schrijf je:
   
   "Ik heb niets geoptimaliseerd. Als ik normaal een winstgevend systeem (932%) heb met een drawdown van 20.000 euro (wat ik veel te hoog vind) en een max winsttoename van 99.000, daarna een trailing stop inzet voor 200 euro, krijg ik (totaalwinst 268%) opeens een drawdown van slechts 1030 en een max winsttoename van 26.000??? Zo wil ik ook wel geld verdienen maar dit is dus nep."
   
   Ik kan dit niet volgen. Heb zelf zoiets nog niet gezien/meegemaakt.
   Is het nep, begrijp je het niet of doe je misschien iets verkeerds.
   
   Hoe verkrijg je die equity curves in die plaatjes. Je maakt daarvoor toch een backtest met of zonder optimalisatie?
   De gladde curve oogt perfect, wat het ook verdacht maakt, tenzij je natuurlijk een geniale vondst gedaan hebt :)
   
   
5. [verwijderd] 5 september 2012 11:25

   auteur info

   • [verwijderd]

     Lid sinds: 01 jan 0001

     Laatste bezoek: 01 jan 0001

   • Aanbevelingen

     Ontvangen: 0

     Gegeven: 0

   •    Aantal posts: 0

   Ik heb inderdaad gewoon een screencapture gemaakt van één en dezelfde backtest, de eerste zonder trailing stop en de tweede met trailingstop. Verder geen verschil.
   
   Het is geen nep of iets wat ik niet begrijp. "Helaas" begrijp ik wel wat er gebeurt.
   Het probleem is als volgt.
   Zoals bekend...Een bar bevat altijd 4 waardes,
   OPEN
   HOOG
   LAAG
   KOERS (aka SLOT)
   
   Zonder trailingstop is er niets aan de hand. De backtest kijkt of er een close signaal komt. Zo ja, wordt meteen verkocht.
   
   Met trailingstop wordt het een ander verhaal.
   Er wordt nu ook gekeken of de trailingstop wordt geraakt.
   
   Plaatje 1
   www.uploadplaatjes.nl/img/n/676732.png
   
   6 oktober op dagsluiting wordt een LONG geopend op 287,30
   7 oktober gelden de volgende waardes
   OPEN 286.40
   HOOG 290.45
   LAAG 283.65
   SLOT 287.20
   
   De backtest kijkt naar de HOOG van de dag 290.45
   De trailingstop bedraagt 1 punt, dus de VERKOOP wordt 289.45
   Fantastisch!!! Of toch niet???
   
   Laat ik die dag eens nader bekijken.
   
   Volgend plaatje, 30 minuut op 7 oktober 2011
   www.uploadplaatjes.nl/img/n/676734.png
   
   Hier zie je een heel ander verloop.
   De koers gaat niet meteen naar HOOG van 290.45 (gebeurt pas in de middag)
   maar gaat eerst naar de daylow van 283.65
   In werkelijkheid zal de trailingstop dus staan op 286.95 (dayhigh om 10:00) - 1.00 = 285.95
   
   Het resultaat wordt dan:
   285.95 - 287.30 = -1.35
   
   Dat is een heel ander resultaat als de backtest:
   289.45 - 287.30 = +2.15
   
   Dit vertroebelt de hele backtest en maakt hem tamelijk waardeloos. Het verklaart ook de belachelijk lage drawdown en de super-winstcurve.
6. novital 5 september 2012 23:09

   auteur info

   • novital

     Lid sinds: 15 nov 2004

     Laatste bezoek: 15 okt 2024

   • Aanbevelingen

     Ontvangen: 161

     Gegeven: 62

   •    Aantal posts: 1.494

   Ik las je beschrijving, en begrijp nu wat je bedoelt.
   Ik ken die FLD flexibel stop loss niet. Is die van PRT of van derden?
   
   Ik kan met je niet anders concluderen dat er iets niet in de haak is. Het kan een software bug zijn.
   Het beste is dit te rapporteren in de hoop dat ze het onderzoeken en er iets aan doen als het aan PRT ligt.
   
7. [verwijderd] 5 september 2012 23:30

   auteur info

   • [verwijderd]

     Lid sinds: 01 jan 0001

     Laatste bezoek: 01 jan 0001

   • Aanbevelingen

     Ontvangen: 0

     Gegeven: 0

   •    Aantal posts: 0

   dat is geen fout van PRT, maar een programmeerfout
8. [verwijderd] 6 september 2012 08:11

   auteur info

   • [verwijderd]

     Lid sinds: 01 jan 0001

     Laatste bezoek: 01 jan 0001

   • Aanbevelingen

     Ontvangen: 0

     Gegeven: 0

   •    Aantal posts: 0

   Die FLD lijn doet niet ter zake deze wordt niet gebruikt in de BT.
   
   En programmeerfout? Van PRT dan ja.
   
   De gebruikte backtest is ZONDER deze rare trailingstop gewoon "betrouwbaar" met een normale realistische winstcurve.
   Pas nadat ik de standaard functie trailing stop activeer in de backtestfunctionalietit van PRT gaat het fout.
   
   Welke backtest je ook gebruikt, zodra je een trailing stop (of bijvoorbeeld een profitstop combineert met een stoploss) zal je dit probleem tegen komen als je een relatief kleine waarde gebruikt zoals in dit geval 1 fti.
   
   
9. novital 6 september 2012 10:16

   auteur info

   • novital

     Lid sinds: 15 nov 2004

     Laatste bezoek: 15 okt 2024

   • Aanbevelingen

     Ontvangen: 161

     Gegeven: 62

   •    Aantal posts: 1.494

   PRT is niet foutloos wat betreft de backtest/optimalisatie.
   Ze maakten eind vorig jaar een enorme blunder door een vernieuwde en versnelde backtester/optimizer vrij te geven, waarvan zonneklaar bleek dat die absolute garbage produceerde als je werkte met eigen indicatoren. Dat werd na 4 maanden hersteld. Maar er zitten nog steeds fouten in die backtester/optimizer.
   Zo zou die bijvoorbeeld geluidsignalen moeten geven als er koop/verkoopsignalen getriggerd worden. Die geluidssignalen komen niet op dat tijdstip, wel veel later op willekeurige tijdstippen en dan vaak nog helemaal fout ook.
   De fout die Psylo nu constateert versterkt mijn mening dat het nog steeds niet in de haak is.
10. hans 41 6 september 2012 12:30

    auteur info

    • hans 41

      Lid sinds: 17 okt 2006

      Laatste bezoek: 14 nov 2024

    • Aanbevelingen

      Ontvangen: 4

      Gegeven: 1

    •    Aantal posts: 329

    quote:

    novital schreef op 6 september 2012 10:16:

    PRT is niet foutloos wat betreft de backtest/optimalisatie.
    Ze maakten eind vorig jaar een enorme blunder door een vernieuwde en versnelde backtester/optimizer vrij te geven, waarvan zonneklaar bleek dat die absolute garbage produceerde als je werkte met eigen indicatoren. Dat werd na 4 maanden hersteld. Maar er zitten nog steeds fouten in die backtester/optimizer.
    Zo zou die bijvoorbeeld geluidsignalen moeten geven als er koop/verkoopsignalen getriggerd worden. Die geluidssignalen komen niet op dat tijdstip, wel veel later op willekeurige tijdstippen en dan vaak nog helemaal fout ook.
    De fout die Psylo nu constateert versterkt mijn mening dat het nog steeds niet in de haak is.
    

    
    
    IS E.E.A. BESCHIKBAAR ??
    
    Hans
11. novital 6 september 2012 12:37

    auteur info

    • novital

      Lid sinds: 15 nov 2004

      Laatste bezoek: 15 okt 2024

    • Aanbevelingen

      Ontvangen: 161

      Gegeven: 62

    •    Aantal posts: 1.494

    quote:

    hans 41 schreef op 6 september 2012 12:30:

    [...]
    
    IS E.E.A. BESCHIKBAAR ??
    
    Hans
    

    Wat bedoel je daarmee?
12. hans 41 6 september 2012 23:23

    auteur info

    • hans 41

      Lid sinds: 17 okt 2006

      Laatste bezoek: 14 nov 2024

    • Aanbevelingen

      Ontvangen: 4

      Gegeven: 1

    •    Aantal posts: 329

    quote:

    novital schreef op 6 september 2012 12:37:

    [...]
    
    Wat bedoel je daarmee?
    
    

    Ik bedoel de backtester/optimizer van PRT
    Hans
13. [verwijderd] 7 september 2012 09:19

    auteur info

    • [verwijderd]

      Lid sinds: 01 jan 0001

      Laatste bezoek: 01 jan 0001

    • Aanbevelingen

      Ontvangen: 0

      Gegeven: 0

    •    Aantal posts: 0

    Backtest is gewoon standaard functionaliteit. Met de parameters kan je een backtest optimizen.
    
14. hans 41 7 september 2012 11:27

    auteur info

    • hans 41

      Lid sinds: 17 okt 2006

      Laatste bezoek: 14 nov 2024

    • Aanbevelingen

      Ontvangen: 4

      Gegeven: 1

    •    Aantal posts: 329

    quote:

    Psylo schreef op 7 september 2012 09:19:

    Backtest is gewoon standaard functionaliteit. Met de parameters kan je een backtest optimizen.
    
    

    DUIDELIJK. Hans