Het gevaar van 'Floating Point Errors' in financiële berekeningen
Een verkeerde komma kan je duur komen te staan. Je denkt een winst van €500 te hebben, maar je broker ziet €0,50.
Of erger, je bot koopt per ongeluk 1000 aandelen in plaats van 10.
Dit is geen bug in je strategie, maar een fundamenteel probleem in hoe computers met getallen omgaan. Het heet een 'floating point error' en het is de stille moordenaar van algoritmische trading bots. Je ziet het niet aankomen totdat je positie openstaat en je winst of verlies compleet anders is dan je backtest. Dit is het soort fout dat ervoor zorgt dat je bot op een maandagochtend je hele account leegtrekt omdat hij een getal net iets anders interpreteert dan jij.
Wat zijn floating point errors?
Stel je voor dat je een oneindige reeks cijfers na de komma moet proberen te schrijven op een papiertje dat maar beperkt ruimte heeft.
Je moet ergens stoppen en afronden. Dat is precies wat computers doen.
Ze kunnen niet oneindig veel cijfers na de komma opslaan. In plaats van de exacte breuken die we in de wiskunde gebruiken (zoals 1/3 = 0.333...), gebruiken computers een soort 'dichtstbijzijnde benadering'. Wiskundig gezien werken de meeste programmeertalen (zoals Python) met 'doubles' of 'floats'. Dit zijn getallen met een bepaalde precisie. Meestal 64-bit.
Dat klinkt heel accuraat, maar het betekent dat een getal als 0.1 in feite nooit precies 0.1 is in het geheugen van je computer. Het is 0.1000000000000000055511151231257827021181583404541015625.
Het verschil is klein, totdat je het begint te vermenigvuldigen. In trading, waar je met hefboomwerking en grote volumes werkt, vermenigvuldig je deze minieme fouten tot een enorme afwijking. Denk aan je backtesting results.
Je script berekent een winst van €1.000. In werkelijkheid, door deze onzichtbare afrondingsfouten, is het er €999,99.
Dat lijkt nog mee te vallen. Maar stel je voor dat je bot 500 trades per dag doet.
Elke trade verliest €0,01 door deze fout. Dat is €5 per dag. €150 per maand. €1.800 per jaar. En dat is zonder dat je het door hebt. Je strategie lijkt winstgevend, maar in live trading verdien je minder dan je denkt, of je betaalt net iets meer transactiekosten.
Waarom dit je bot fataal kan worden
Het echte gevaar ontstaat bij logische checks. Je schrijft een simpele 'if'-statement: if winst > 0:.
In je backtest is de winst 0.000000001. Je bot denkt: "Dit is een winstgevende trade!" en houdt de positie open. In werkelijkheid is het verlies 0.000000002. Je broker ziet een verlies.
Je bot ziet een winst. Je loopt vast in een positie die je nooit had moeten hebben, of je sluit hem te vroeg.
Stel je voor dat je een stop-loss instelt op €50.000 op een aandeel dat €50.100 staat.
Je script zegt: "Als de prijs onder €50.000 komt, verkoop dan." Door floating point berekeningen (misschien door een klein verschil in de datafeed van je broker zoals Interactive Brokers of degiro), komt de priks op €49.9999999999999 terecht. Jouw script ziet dit als 'groter dan 50.000' vanwege de manier waarop de vergelijking wordt gemaakt, of juist als kleiner en triggert de verkoop. Het resultaat is onvoorspelbaar gedrag.
Je risicobeheer faalt op het moment dat je het het hardst nodig hebt. Voeg hier de complexiteit van API's aan toe.
Wanneer je een order plaatst via de API van een broker, stuur je een getal mee voor het aantal aandelen of de limietprijs. Stuur je per ongeluk een getal met te veel decimalen door? Sommige API's accepteren dit en reageren met een error.
Andere API's rondingen het af op een manier die jij niet verwacht.
Je order van 100 aandelen wordt er 99, of 101. Bij een aandeel van €200 is dat direct €200 verschil in blootstelling.
De impact op Risicomanagement
Risicomanagement draait om precisie. Als je Kelly Criterion berekent of een fixed-fractional model gebruikt, draait alles om percentages.
Stel je berekent je positiegrootte: account_balance * 0.02. Je hebt €10.000 op je rekening. Je wilt 2% riskeren, dus €200. De berekening geeft €200,00000000001.
Je bot probeert een positie te openen die net iets te groot is. De broker geeft een error: "Onvoldoende middelen" in het midden van de nacht.
Je mist de trade. Of erger, de bot denkt: "Ik pas mijn positie wel iets aan" en opent een positie die 0.1% groter is dan gepland.
Na 100 trades loop je enorm uit je plan. Kijk naar de 'Sharpe Ratio' in je backtests. Dit getal berekent de risicogecorrigeerde return.
Het is extreem gevoelig voor afrondingsfouten. Een backtest kan een Sharpe Ratio van 2.1 laten zien, terwijl de werkelijkheid 1.8 is.
Je vertrouwt op een strategie die in theorie goed presteert, maar in de praktijk net onder de streep verliest. De floating point error zit niet in je strategie-logica, maar in de wiskundige formule zelf.
Herken de boosdoeners in je code
Je hoeft geen wiskundig genie te zijn om deze problemen te fixen. Je moet alleen weten waar je moet kijken. In Python, de taal van bijna elke serieuze algoritmische trader, zijn er een paar klassieke valkuilen.
De grootste is het direct vergelijken van floats met '==', '<', of '>'.
Zoals hierboven gezegd, is 0.1 + 0.2 namelijk niet precies 0.3. Het is 0.30000000000000004. Als je code zegt if (0.1 + 0.2) == 0.3:, dan faalt die check.
In je trading bot betekent dit dat een check op 'als prijs == stop_loss' nooit werkt zoals je verwacht. Een andere boosdoener is de 'decimal' module. Veel beginners gebruiken de standaard 'float' voor geldbedragen. Doe dit nooit.
Voor financiële data moet je de decimal.Decimal class gebruiken in Python. Deze class slaat getallen op als strings in plaats van binary floats.
Hierdoor zijn ze 100% accuraat tot aan de precisie die je instelt. Het is langzamer dan standaard floats, maar voor risicoberekeningen en orderplaatsing is het essentieel. Een trade van €50.000 verdient precisie. Let ook op de data die je binnenhaalt via je API.
Als je data van een broker als Bitvavo of Binance haalt, of een datafeed van een partij als Refinitiv, zitten daar soms al afrondingsfouten in. Je Python script moet deze data 'schoonmaken' voordat je er logica op loslaat.
Converteer strings naar Decimal objecten, round ze niet alleen visueel af maar wiskundig.
Zorg dat je weet hoeveel decimalen je broker accepteert (bij aandelen is dat meestal 2, bij crypto soms 8 of meer). Stel je hebt een bot die handelt in de S&P 500 index futures (ES). De prijs beweegt in 'ticks'.
Een voorbeeld uit de praktijk
Een tick is 0.25 punten. De waarde per tick is €12.50. Je bot berekent een entry op 4500.25.
Je stop-loss staat op 4499.75. Een verschil van 0.50 punten.
Dat is 2 ticks. €25 verlies. Simpel? Nu komt de floating point error.
Je berekent het verschil in Python: entry = 4500.25, stop = 4499.75. verschil = entry - stop. In een normale situatie is dit 0.5. Maar als je deze getallen binnenhaalt via een API die soms wetenschappelijke notatie gebruikt (zoals 4.50025e3), en je verwerkt ze verkeerd, kan er een microscopische fout ontstaan.
Je risico engine denkt nu misschien dat het verschil 0.4999999999999999 is. Hij berekent het aantal ticks: 1.9999999999999996 ticks.
Hij rondt af naar beneden. Je krijgt 1 tick risico in plaats van 2. Je positie wordt twee keer zo groot als je dacht. In plaats van €12.50 risico loop je €25 risico. Bij 10 trades per dag is je risico verdubbeld zonder dat je het door hebt.
Praktische tips om je bot veilig te houden
Gelukkig is dit probleem volledig oplosbaar met een paar simpele regels. Je hoeft geen expert te worden in computerwetenschap, je moet gewoon disciplined zijn in je code.
Hier is een checklist die je kunt gebruiken voordat je je bot live zet. Als je deze regels volgt, maak je je bot vele malen robuuster. Je vermijdt de meest gênante fouten (zoals een order die faalt omdat je 0.0000001 te weinig saldo lijkt te hebben) en je zorgt dat je financiële code grondig test zodat je risicomanagement klopt.
- Gebruik Decimal voor geld: Importeer from decimal import Decimal, getcontext. Zet je precisie hoog (bijv. getcontext().prec = 20). Gebruik Decimal('0.1') in plaats van 0.1. Reken alles in Decimal uit tot je een order plaatst. Pas de API limieten toe op het allerlaatste moment.
- Vergelijk met 'epsilon': Stop met directe vergelijkingen. Gebruik een 'epsilon' (een heel klein getal) voor vergelijkingen. In plaats van if price == stop:, gebruik if abs(price - stop) < 0.0001:. Dit vangt de kleine afwijkingen op.
- Ken je broker: Lees de API documentatie. Wat is de minimale prijsverandering? Wat is de maximale grootte van een order? Als je broker vraagt om prijzen met max 2 decimalen, stuur dan geen 5 decimalen. Rond het af voordat je de API call maakt, maar reken intern met Decimal.
- Test met 'Edge Cases': Test je backtests niet alleen op normale data. Test met getallen die bekend staan als lastig voor computers: 0.1, 0.2, 0.3, 1/3, 0.999999. Kijk wat er gebeurt als je posities opent op exacte support/resistance levels. Als je bot daar rare dingen doet, weet je dat er floating point issues zijn.
- Log de 'raw' data: Log niet alleen je trades, maar log de exacte getallen die je binnenkrijgt en de getallen die je berekent. Zie je rare eindes op .00000001? Dan weet je dat je ergens moet converteren naar Decimal.
Trading is al moeilijk genoeg; je wilt niet dat je computer je in de weg loopt.
Zorg dat de getallen kloppen, dan kun jij je richten op de markt.