Outomatiese Handel Stelsel Programmering

Die skep van outomatiese handel stelsels met behulp van Interaktiewe Brokers: outomatiese handel met interaktiewe Brokers Die Interaktiewe Brokers verhandelingsplatform self bied nie outomatiese handel. Maar 'n paar oplossings is beskikbaar vir handelaars wat wil handel stelsels outomatiseer met behulp van die IB Trader Workstation (TSW) platform, insluitend: Derde-party API Programmering Consultants IB APIs 13 Derde-party API's 'n Application Programming Interface (API) is 'n taal-formaat benut deur 'n aansoek program om te kommunikeer met ander stelsel sagteware. 'N API tree op as 'n koppelvlak of go-tussen daardie kode om te kommunikeer met die IB verhandelingsplatform toelaat. Derdeparty-verkopers bied 'n verskeidenheid van eiendom APIs wat aanpas, voortgang algoritmes en plug-and-play handel sagteware programme wat ontwerp is om in samewerking met Prikkelbare Dermsindroom Trader Workstation (TWS) handel platform.13A lys van derde deel APIs voorsien word op beskikbare die IB webwerf: vanaf die tuisblad op die Onderwys opskrif en kies die MarketplaceIB. Lees die disclaimer en as jy instem tot die voorwaardes, kliek As jy instem tot die Disclaimer, Klik hier om voort te gaan. Klik op die blad sagteware gereedskap en die post Bestel Management Sagteware verskaffers en produkte (sien figuur 1) te sien. Figuur 1 - Kies die blad sagteware gereedskap in die MarketplaceIB om derdeparty-verskaffers te blaai. Programmering Consultants Benewens die kommersieel beskikbare APIs, Die MarketplaceIB het ook 'n skakel na Programmering konsultante wat handelaars en beleggers kan help met die ontwikkeling van persoonlike aanwysers en strategieë wat gebruik word in outomatiese handel. Die konsultante kodering in 'n verskeidenheid van tale, insluitend Java, C, Visual Basic, SQL, Perl, Matlab asook ander handel platforms eie tale wat gebruik kan word gekoppel met IB. Hou in gedagte dat programmeerders kan net program absolute reëls, en hulle gewoonlik nie voorstelle aan te bied vir die verbetering van die winsgewendheid van 'n stelsel - net die prestasie van die kode. Voordat die werk met 'n programmeerder, is dit belangrik om in staat wees om al die handel stelsels inskrywing, uitgang en bestuur logika definieer. As dit kan gedefinieer word, kan dit waarskynlik gekodeer. Programmering met IB Apis 'n Derde oplossing is vir handelaars met die vaardighede (of begeerte om te leer) om hul eie API program. Interaktiewe Brokers bied verskeie APIs wat handelaars kan gebruik om aan te sluit deur óf die TWS of die IB Gateway. Connecting deur die TWS vereis dat die aansoek te loop, maar kan handelaars om te toets en te bevestig dat die API bestellings korrek funksioneer. Connecting deur die IB Gateway, aan die ander kant, maak nie voorsiening 'n koppelvlak vir die toets en bevestiging, maar toelaat dat die API te voer sonder 'n groot GUI aansoek hardloop. Waar die derde party API bied aanpas, voortgang algoritmes, die IB API programmeer omgewing is in wese rou materiaal. IB bied die toerusting en komponente, en die gebruiker doen al die programme. Gebruikers kan die program in 'n verskeidenheid van tale, insluitend C, Java, ActiveX of DDE vir Excel. Daar is 'n aantal API verwante instellings in TWS dat handelaars kan instel, word in Figuur 2. Die IB API Reference Guide (beskikbaar op die Interaktiewe Brokers webwerf: soek vir API Verwysingsgids) bied 'n oorsig asook instruksies wat spesifiek op die verskillende programmeertale. 13 Figuur 2 - die API-instellings in TWS. Gevolgtrekking Handelaars wat wil outomatiese handel stelsels te implementeer deur die Interaktiewe Brokers platform het 'n verskeidenheid van opsies. Nie-programmeerders kan wens om die derde party API verskaffers wat 'n verskeidenheid van aanpas of plug-and-play opsies bied verken. Handelaars met 'n unieke idees kan werk met 'n gekwalifiseerde ontwikkeling konsultant. Diegene met programming ervaring of die tyd en die begeerte om te leer 'n programmeertaal kan die IB API diens by die ontwikkeling van outomatiese handel stelsels. Teken in op nuus te gebruik vir die nuutste insigte en analysisThe voor - en nadele van outomatiese handel stelsels handelaars en beleggers kan presiese inskrywing draai. uitgang en geldbestuur reëls in outomatiese handel stelsels wat toelaat dat rekenaars uit te voer en te monitor die ambagte. Een van die grootste trekpleisters van strategie outomatisering is dat dit 'n paar van die emosie kan uitneem van handel sedert ambagte outomaties geplaas wanneer sekere kriteria voldoen. In hierdie artikel sal stel lesers en verduidelik 'n paar van die voordele en nadele, asook die realiteite van outomatiese handel stelsels. (Vir verwante leesstof, sien die krag van Kursus ambagte.) Wat is 'n outomatiese Trading System outomatiese handel stelsels, ook bekend as meganiese handel stelsels, algoritmiese handel. outomatiese handel of stelsel handel, toelaat handelaars om spesifieke reëls vas te stel vir beide handel inskrywings en uitgange dat, sodra geprogrammeer kan outomaties uitgevoer word deur 'n rekenaar. Die vakbond toegang en uitgang reëls kan gebaseer wees op eenvoudige toestande soos 'n bewegende gemiddelde crossover. of kan ingewikkeld wees strategieë wat 'n omvattende begrip van die programmeringstaal wat spesifiek op die gebruikers verhandelingsplatform, of die kundigheid van 'n gekwalifiseerde programmeerder vereis. Outomatiese handel stelsels tipies vereis dat die gebruik van sagteware wat gekoppel is aan 'n direkte toegang makelaar. en enige spesifieke reëls moet in daardie platforms eie taal. Die TradeStation platform, byvoorbeeld, gebruik die EasyLanguage programmeertaal die NinjaTrader platform, aan die ander kant, maak gebruik van die NinjaScript programmeertaal. Figuur 1 toon 'n voorbeeld van 'n outomatiese strategie wat drie ambagte veroorsaak tydens 'n handel sessie. (Vir verwante leesstof, sien Global Trade En die valutamark.) Figuur 1: 'n vyf-minuut grafiek van die ES kontrak met 'n outomatiese strategie toegepas. Sommige handel platforms het strategie gebou towenaars wat gebruikers in staat stel om keuses te maak uit 'n lys van algemeen beskikbare tegniese aanwysers aan 'n stel reëls wat dan outomaties kan verhandel word bou. Die gebruiker kan vestig, byvoorbeeld, wat 'n lang handel nadat die 50-dae - bewegende gemiddelde kruise bo die 200-daagse bewegende gemiddelde op 'n vyf-minuut grafiek van 'n bepaalde handel instrument sal daaroor gevoer word nie. Gebruikers kan ook die invoer van die tipe orde (mark of beperking, byvoorbeeld) en wanneer die handel sal veroorsaak (byvoorbeeld, aan die einde van die bar of oop van die volgende bar), of gebruik die platforms verstek insette. Baie handelaars is egter kies om hul eie persoonlike aanwysers en strategieë program of werk nou saam met 'n programmeerder om die stelsel te ontwikkel. Terwyl dit meer moeite verg gewoonlik as die gebruik van die towenaar platforms, dit laat 'n veel groter mate van buigsaamheid en die resultate kan meer lonend wees. (Ongelukkig is daar geen perfekte beleggingstrategie wat sukses sal waarborg. Besoek vir meer inligting met behulp van tegniese aanwysers aan Trading strategieë te ontwikkel.) Sodra die reëls ingestel is, kan die rekenaar die markte te monitor om te koop of te verkoop geleenthede gebaseer op die handel te vind strategie spesifikasies. Afhangende van die spesifieke reëls, so gou as 'n handelsmerk is ingevoer, enige bestellings vir beskermende stop verliese. sleep tot stilstand kom en wins teikens sal outomaties gegenereer word. In vinnig bewegende markte, kan dit onmiddellik orde inskrywing die verskil tussen 'n klein verlies en 'n katastrofiese verlies in die geval van die handel beweeg teen die handelaar beteken. Voordele van outomatiese handel stelsels Daar is 'n lang lys van voordele aan 'n rekenaar monitor die markte vir handel geleenthede en uit te voer die ambagte, insluitend: Minimize Emosies. Outomatiese handel stelsels te verminder emosies regdeur die handel proses. Deur die behoud van emosies in toom, handelaars het gewoonlik 'n makliker tyd vas aan die plan. Sedert handel bestellings outomaties uitgevoer word sodra die reëls handel nagekom is, sal handelaars nie in staat wees om te huiwer of bevraagteken die handel. Benewens help handelaars wat bang is om die sneller te trek, kan outomatiese handel te bekamp diegene wat bekwaam om te koop en verkoop van overtrade by elke waargeneem geleentheid. Vermoë om backtest. Back testing geld handel reëls om historiese mark data om die lewensvatbaarheid van die idee te bepaal. Wanneer die ontwerp van 'n stelsel vir outomatiese handel, moet al die reëls absolute te wees, met geen ruimte vir interpretasie (die rekenaar kan nie raai dit moet presies vertel wat om te doen). Handelaars kan hierdie presiese stelle reëls neem en toets dit op historiese data voor gevaar geld in lewende handel. Versigtig back testing kan handelaars om te evalueer en te verfyn 'n handels idee, en om die stelsels verwagting die gemiddelde bedrag wat 'n handelaar kan verwag om te wen te bepaal (of verloor) per eenheid van risiko. (Ons bied 'n paar wenke oor die proses wat jou kan help musiek vind jou huidige handel strategieë vir meer inligting back testing:.. Interpretasie van die verlede) Bewaar dissipline. Omdat die reëls handel gevestig en uitvoering handel outomaties uitgevoer word, is dissipline bewaar selfs in wisselvallige markte. Dissipline is dikwels verlore as gevolg van emosionele faktore soos vrees vir die neem van 'n verlies, of die begeerte om eweneens in 'n bietjie meer wins uit 'n bedryf. Outomatiese handel help verseker dat dissipline gehandhaaf word omdat die handel plan presies sal gevolg word. Daarbenewens is die vlieënier fout geminimaliseer en 'n bevel tot 100 aandele te koop nie verkeerd geloop as 'n bevel tot 1000 aandele te verkoop. Bereik konsekwentheid. Een van die grootste uitdagings in die handel is om die handel te beplan en handel die plan. Selfs as 'n verhandeling van plan het die potensiaal om winsgewend te wees, handelaars wat die reëls te ignoreer is verander enige verwagting die stelsel sou gehad het. Daar is nie so iets soos 'n verhandeling van plan dat 100 van die tyd verliese is 'n deel van die spel wen. Maar verliese kan sielkundig traumatizing wees, so 'n handelaar wat twee of drie verloor ambagte in 'n ry kan besluit om die volgende handel slaan. As dit volgende handel 'n wenner sou gewees het, het die handelaar reeds enige verwagting die stelsel moes vernietig. Outomatiese handel stelsels kan handelaars om konsekwentheid te bereik deur die handel van die plan. (Sy onmoontlik om 'n ramp te vermy sonder handel reëls. Besoek vir meer inligting 10 Stappe om te bou van 'n Wen Trading Plan.) Verbeterde Order Entry Speed. Sedert rekenaars onmiddellik te reageer op veranderende marktoestande, outomatiese stelsels in staat is om bestellings so gou as handel kriteria voldoen genereer. Om in of uit 'n handelsmerk 'n paar sekondes vroeër kan 'n groot verskil in die ambagte uitkoms te maak. Sodra 'n posisie is aangegaan, word alle ander bestellings outomaties gegenereer, insluitend beskermende stop verlies en wins teikens. Markte kan vinnig beweeg, en dit is demoraliserende om 'n handel te bereik die wins teiken of blaas verby 'n stop verlies vlak voor die bestellings kan selfs daaroor gevoer word nie. 'N outomatiese handel stelsel verhoed dat dit gebeur. Diversifiseer Trading. Outomatiese handel stelsels toelaat dat die gebruiker om verskeie rekeninge of verskillende strategieë handel op 'n tyd. Dit het die potensiaal om die risiko oor verskeie instrumente versprei terwyl die skep van 'n verskansing teen die verlies van poste. Wat sou ongelooflik uitdagend wees vir 'n mens om te bereik doeltreffend deur 'n rekenaar in 'n kwessie van millisekondes uitgevoer word. Die rekenaar in staat is om te soek na handelsgeleenthede in verskeie markte, genereer bestellings en monitor ambagte. Nadele en realiteite van outomatiese handel stelsels outomatiese handel stelsels spog baie voordele, maar daar is 'n paar ondergang van en realiteite waaraan handelaars moet bewus wees. Meganiese mislukkings. Die teorie agter outomatiese handel maak dit lyk eenvoudig: die opstel van die sagteware, program die reëls en kyk hoe dit handel. In werklikheid is egter outomatiese handel is 'n gesofistikeerde metode van handel, nog nie onfeilbaar. Afhangende van die verhandelingsplatform, kan 'n handelsmerk orde woon op 'n rekenaar en nie 'n bediener. Wat dit beteken is dat as 'n internet konneksie verloor, 'n bevel kan nie na die mark gestuur. Daar kan ook 'n verskil tussen die teoretiese ambagte wat gegenereer word deur die strategie en die orde inskrywing platform komponent wat draai hulle binnein werklike ambagte wees. Die meeste handelaars moet 'n leerkurwe verwag wanneer die gebruik van outomatiese handel stelsels, en dit is oor die algemeen 'n goeie idee om te begin met 'n klein handel groottes terwyl die proses verfyn. Monitering. Alhoewel dit wonderlik om te draai op die rekenaar en laat staan ​​vir die dag sou wees, doen outomatiese handel stelsels vereis monitering. Dit is te danke doen die potensiaal vir meganiese mislukkings, soos verbinding kwessies, krag verliese of rekenaar ineenstort, en aan die stelsel eienaardighede. Dit is moontlik vir 'n outomatiese handel stelsel om onreëlmatighede wat kan lei tot dwalende bestellings, vermiste bestellings, of dupliseer bestellings ondervind. As die stelsel gemonitor, kan hierdie gebeure word geïdentifiseer en vinnig opgelos. Oor-optimalisering. Hoewel dit nie spesifiek vir outomatiese handel stelsels, kan handelaars wat back testing tegnieke aan te wend stelsels wat lyk groot op papier en voer verskriklik in 'n lewendige mark te skep. Oor-optimalisering verwys na oormatige krommepassing dat produseer 'n verhandeling van plan dit is onbetroubaar in lewende handel. Dit is moontlik, byvoorbeeld, 'n strategie aanpas om uitstekende resultate op die historiese data waarop dit getoets te bereik. Handelaars soms verkeerdelik aanvaar dat 'n verhandeling van plan naby aan 100 winsgewende bedrywe moet hê of moet nooit ervaar 'n onttrekking tot 'n lewensvatbare plan wees. As sodanig, kan parameters word aangepas om 'n byna perfekte plan wat heeltemal in gebreke bly sodra dit toegepas word om 'n lewendige mark te skep. (Hierdie oor-optimalisering skep stelsels wat goed lyk op papier net vir meer inligting back testing en stuur Toets:.. Die belangrikheid van korrelasie)-bediener gebaseerde Automation Handelaars doen het die opsie om hul outomatiese handel stelsels loop deur 'n bediener gebaseerde handel platform soos strategie Runner. Hierdie platforms bied gereeld kommersiële strategieë te koop, 'n towenaar sodat handelaars hul eie stelsels kan ontwerp, of die vermoë beskik om bestaande stelsels te bied op die bediener gebaseerde platform. Vir 'n fooi, kan die outomatiese handel stelsel scan vir, uit te voer en te monitor ambagte met alle bestellings wat op hul bediener, wat lei tot potensieel vinniger, meer betroubaar orde inskrywings. Gevolgtrekking Alhoewel 'n ppealing vir 'n verskeidenheid van faktore, outomatiese handel stelsels moet nie beskou word as 'n plaasvervanger vir noukeurig uitgevoer handel. Meganiese mislukkings kan gebeur, en as sodanig, het hierdie stelsels vereis monitering. - Bediener-gebaseerde platforms kan 'n oplossing vir handelaars wat die risiko's van meganiese mislukkings te minimaliseer voorsien. (Vir verwante leesstof, sien Dag handel strategieë vir beginners.) WEN 1000 na 'n MultiCharts Lifetime Lisensie Sommige makelaars bied 'n beter pryse, en 'n paar data voed verskaf meer historiese data. Kies dié wat jou behoeftes te pas. Selfs met 'n wen-strategie, kan net 'n kort vertraging in die uitvoering orde al die verskil maak. Outomatiese handel is 'n baie vinniger as 'n mens. Bekend as 'n quotscreenerquot, of ldquoquote boardrdquo, kan hierdie instrument wat jy monitor duisende mark simbole in 'n venster om winsgewende geleenthede te vind. EasyLanguage is 'n industrie standaard taal vir ontwikkeling strategieë en aanwysers. Dit is spesifiek gemaak vir handelaars grootste voordeel is jy kan begin in minute. Back testing is die toepassing van 'n strategie om historiese data te sien ldquohow jy donerdquo sou hê. Portefeulje back testing kan jy ontwerp en toets strategieë op verskeie simbole. 2012 t2w Members39 Choice Award Beste sagteware vir Meganiese stelsel Handelaars Beste Tegniese analise sagteware 2011 t2w Members39 Choice Award Beste Professionele Trading Platform Beste sagteware vir Intra-Dag Handelaars 2013 tegniese ontleding van aandele en kommoditeite Readers39 Choice Award semifinalis Standalone Analitiese sagteware 1000 en Bo 2012 BMT beste van die saak toekenning Trading platform van die Jaar Futures Trading platform die YearBest Programmering taal vir Algorithmic Trading Systems Deur Michael Saal-Moore op 26 Julie 2013 Een van die mees algemene vrae wat ek ontvang in die QS Koevert is Wat is die beste programmeertaal vir algoritmiese handel. Die kort antwoord is dat daar geen beste taal. Strategie parameters, prestasie, modulariteit, ontwikkeling, veerkragtigheid en koste moet al oorweeg. In hierdie artikel sal uiteensetting van die nodige komponente van 'n algoritmiese handel stelsel argitektuur en hoe besluite oor die implementering invloed op die keuse van taal. Eerstens, sal die belangrikste komponente van 'n algoritmiese handel stelsel in ag geneem word, soos die navorsing gereedskap, portefeulje-optimaliseerder, risikobestuurder en uitvoering enjin. Daarna sal verskillende handel strategieë ondersoek word en hoe hulle invloed op die ontwerp van die stelsel. In die besonder die frekwensie van die saak en die waarskynlike handel volume sal beide bespreek word. Sodra die handel strategie gekies is, is dit nodig om argitek die hele stelsel. Dit sluit in die keuse van hardeware, die bedryfstelsel (s) en stelsel veerkragtigheid teen seldsame, potensieel katastrofiese gebeure. Terwyl die argitektuur oorweeg word, moet daar behoorlik ag gegee word aan prestasie - beide om die navorsing gereedskap sowel as die lewendige uitvoering omgewing. Wat is die handel stelsel probeer om te doen voordat jy besluit op die beste taal waarmee 'n outomatiese handel stelsel is dit nodig om die vereistes te definieer skryf. Is die stelsel gaan suiwer uitvoering gebaseer Sal die stelsel vereis dat 'n risikobestuur of portefeulje konstruksie kursus sal die stelsel vereis dat 'n hoë-prestasie backtester Vir die meeste strategieë die handel stelsel kan verdeel word in twee kategorieë wees: Navorsing en sein generasie. Navorsing handel oor evaluering van 'n strategie prestasie oor historiese data. Die proses van evaluering van 'n handel strategie oor data voor mark staan ​​bekend as back testing. Die grootte van data en algoritmiese kompleksiteit sal 'n groot impak op die rekenaarmatige intensiteit van die backtester het. CPU spoed en samelopendheid is dikwels die beperkende faktore in die optimalisering van uitvoering navorsing spoed. Sein generasie is gemoeid met die opwekking van 'n stel van handel seine van 'n algoritme en sulke bestellings stuur na die mark, gewoonlik deur 'n makelaar. Vir sekere strategieë 'n hoë vlak van prestasie vereis. I / O kwessies soos netwerk bandwydte en latency is dikwels die beperkende faktor in die optimalisering van die uitvoering stelsels. So die keuse van tale vir elke komponent van jou hele stelsel kan heel anders wees. Tipe, frekwensie en volume van Strategie Die tipe algoritmiese strategie in diens sal 'n aansienlike impak op die ontwerp van die stelsel het. Dit sal nodig wees om te oorweeg die markte verhandel word, die konneksie na eksterne data verskaffers, die frekwensie en volume van die strategie, die kompromis tussen gemak van ontwikkeling en verbetering van die prestasie, sowel as enige persoonlike hardeware, insluitend mede geleë persoonlike bedieners, GPU's of FPGAs wat nodig mag wees. Die tegnologie keuses vir 'n lae-frekwensie Amerikaanse aandele strategie sal grootliks verskil van dié van 'n hoë-frekwensie statistiese arbitrage strategie handel oor die termynmark wees. Voor die keuse van taal baie data verskaffers moet geëvalueer alledaagse n strategie aan die hand. Dit sal nodig wees om verbinding met die verkoper, struktuur van enige APIs, tydigheid van die data, bergingsvereistes en veerkragtigheid te oorweeg in die lig van 'n ondernemer gaan af. Dit is ook wys om 'n vinnige toegang tot verskeie verskaffers in besit te neem Verskeie instrumente almal hul eie stoor eienaardighede, voorbeelde van wat insluit verskeie ENKELE simbole vir aandele en verval datums vir Toekomsnavorsing (nie aan enige spesifieke OTC data te noem). Dit moet ingereken in die platform ontwerp. Frekwensie van strategie is waarskynlik een van die grootste oorsake van hoe die tegnologie stapel sal gedefinieer word nie. Strategieë in diens data meer dikwels as fyn of tweedens bars vereis betekenisvolle ag met betrekking tot prestasie. 'N Strategie oorskry tweedens bars (bv merk data) lei tot 'n prestasiegedrewe ontwerp as die primêre vereiste. Vir 'n hoë frekwensie strategieë 'n aansienlike bedrag van die mark data sal moet word gestoor en geëvalueer. Sagteware soos HDF5 of KDB word algemeen gebruik vir hierdie rolle. Met die oog op die uitgebreide volumes van data wat nodig is vir HFT aansoeke te verwerk, moet 'n groot skaal new backtester en uitvoering stelsel gebruik word. C / C (moontlik met 'n paar assembler) is geneig om die sterkste taal kandidaat. Ultrahoëfrekwensie strategieë sal ongetwyfeld vereis persoonlike hardeware soos FPGAs, ruil mede-plek en kernal / netwerk koppelvlak tuning. Navorsing Systems Research stelsels tipies behels 'n mengsel van interaktiewe ontwikkeling en outomatiese script. Die voormalige vind dikwels plaas in 'n IDE soos Visual Studio, Matlab of R Studio. Laasgenoemde behels uitgebreide numeriese berekeninge oor talle parameters en data punte. Dit lei tot 'n taalkeuse verskaffing van 'n eenvoudige omgewing te toets kode, maar bied ook voldoende prestasie om strategieë oor verskeie parameter dimensies evalueer. Tipiese Ides in hierdie ruimte sluit Microsoft Visual C / C, wat uitgebreide ontfouting nuts,-kode voltooiing vermoëns bevat (via IntelliSense) en eenvoudige oorsigte van die hele projek stapel (via die databasis ORM, LINQ) Matlab. wat ontwerp is vir 'n uitgebreide numeriese lineêre algebra en gevectoriseerd bedrywighede, maar in 'n interaktiewe konsole wyse R Studio. wat vou die R statistiese taal konsole in 'n volwaardige IO Eclipse IDE vir Linux Java en C en semi-eiendom Ides soos Enthought Canopy vir Python, wat data-analise biblioteke soos Numpy sluit. Scipy. scikit-leer en pandas in 'n enkele interaktiewe (konsole) omgewing. Vir numeriese back testing, al die bogenoemde tale is geskik, maar dit is nie nodig om 'n GUI / IDE gebruik as die kode in die agtergrond sal uitgevoer word. Die eerste oorweging in hierdie stadium is dat van die uitvoering spoed. A saamgestel taal (soos C) is dikwels nuttig as die back testing parameter dimensies is groot. Onthou dat dit nodig versigtig vir sulke stelsels te wees is as wat die saak gevolge het verduidelik tale soos Python dikwels gebruik van 'n hoë-prestasie biblioteke soos Numpy / pandas vir die back testing stap maak, ten einde 'n redelike mate van mededingendheid te behou met saamgestel ekwivalente. Uiteindelik is die wat gekies is vir die back testing taal sal bepaal word deur spesifieke algoritmiese behoeftes sowel as die verskeidenheid van biblioteke beskikbaar in die taal (meer op wat hieronder). Tog kan die taal wat gebruik word vir die backtester en navorsing omgewings heeltemal onafhanklik van dié wat in die portefeulje konstruksie, risikobestuur en uitvoering komponente, soos gesien sal word. Portefeulje Konstruksie en Risikobestuur Die portefeulje konstruksie en risikobestuur komponente word dikwels oor die hoof gesien deur kleinhandel algoritmiese handelaars. Dit is byna altyd 'n fout. Hierdie gereedskap verskaf die meganisme waardeur kapitaal sal bewaar word. Hulle het nie net probeer om die aantal riskant verbintenis te verlig, maar ook hulself te verminder kansellasies van die ambagte, die vermindering van transaksiekoste. Gesofistikeerde weergawes van hierdie komponente kan 'n beduidende invloed op die gehalte en consistentcy van winsgewendheid het. Dit is maklik om 'n stabiele strategieë as die portefeulje konstruksie meganisme en risikobestuurder skep kan maklik aangepas word om verskeie stelsels te hanteer. So moet hulle in aanmerking kom essensiële komponente aan die begin van die ontwerp van 'n algoritmiese handel stelsel. Die werk van die portefeulje konstruksie stelsel is om 'n stel van gewenste ambagte te neem en te produseer die stel van die werklike ambagte wat kansellasies te verminder, blootstelling aan verskeie faktore (soos sektore, bateklasse, wisselvalligheid ens) in stand te hou en te optimaliseer die toekenning van kapitaal na verskeie strategieë in 'n portefeulje. Portefeulje konstruksie verminder dikwels 'n lineêre algebra probleem (soos 'n matriks faktorisering) en vandaar prestasie is hoogs afhanklik van die doeltreffendheid van die numeriese lineêre algebra implementering beskikbaar. Gemeenskaplike biblioteke sluit uBLAS. LAPACK en NAG vir C. MatLab beskik ook op groot skaal new matriksbewerkings. Python gebruik Numpy / Scipy vir sulke berekeninge. 'N gereeld herbalanseer portefeulje sal 'n saamgestel (en goed new) matriks biblioteek vereis dat hierdie stap uit te voer, sodat dit nie die handel stelsel knelpunt. Risikobestuur is 'n ander baie belangrike deel van 'n algoritmiese handel stelsel. Risiko kan kom in baie vorms: Groter wisselvalligheid (hoewel dit as wenslik vir sekere strategieë kan gesien word), verhoogde korrelasies tussen bateklasse, teenparty verstek bediener kragonderbrekings, Black Swan gebeure en ongemerk foute in die handel kode, te noem 'n paar. Risikobestuur komponente probeer antisipeer die gevolge van oormatige wisselvalligheid en korrelasie tussen bateklasse en hul daaropvolgende effek (s) op die handel kapitaal. Dikwels is dit verminder tot 'n stel van statistiese berekeninge soos Monte Carlo stres toetse. Dit is baie soortgelyk aan die computational behoeftes van 'n afgeleide pryse enjin en as sodanig sal CPU-gebonde wees. Hierdie simulasies is hoogs parallelisable (sien onder), en 'n sekere mate, is dit moontlik om die hardeware te gooi by die probleem. Uitvoering Systems Die werk van die uitvoering stelsel is om gefiltreer handel seine van die portefeulje konstruksie en risikobestuur komponente ontvang en stuur hulle oor na 'n makelaar of 'n ander manier van toegang tot die mark. Vir die meerderheid van die kleinhandel algoritmiese handel strategieë behels dit 'n API of FIX verbinding met 'n makelaars soos Interaktiewe Brokers. Die primêre oorwegings wanneer jy moet besluit op 'n taal insluit gehalte van die API, taal-wrapper beskikbaarheid vir 'n API, uitvoering frekwensie en die verwagte glip. Die kwaliteit van die API verwys na hoe goed gedokumenteer is dit, watter soort prestasie dit bied, of dit moet selfstandige sagteware te verkry of 'n poort vasgestel kan word in 'n onthoofde mode (dit wil sê geen GUI). In die geval van Interaktiewe Brokers, die Trader WorkStation instrument moet hardloop in 'n GUI omgewing ten einde toegang tot hul API. Een keer het ek 'n lessenaar Ubuntu uitgawe installeer op 'n wolk bediener Amazon toegang Interaktiewe Brokers afstand, suiwer vir hierdie rede waarom die meeste API sal 'n C en / of Java koppelvlak verskaf. Dit is gewoonlik tot die gemeenskap te taalspesifieke omhulsels vir C, Python, R, Excel en MatLab ontwikkel. Let daarop dat met elke bykomende plugin gebruik (veral API omhulsels) is daar ruimte vir foute insluip in die stelsel. toets altyd plugins van hierdie soort en verseker dat hulle aktief in stand gehou. 'N waardevolle meter is om te sien hoeveel nuwe updates vir 'n kodebasis is gemaak in die afgelope maande. Uitvoering frekwensie is van die uiterste belang in die uitvoering algoritme. Let daarop dat honderde bestellings elke minuut kan gestuur word en as sodanig prestasie is van kritieke belang. Glip aangegaan sal word deur middel van 'n erg-presterende uitvoering stelsel en dit sal 'n dramatiese impak op winsgewendheid het. Staties-getik tale (sien onder) soos C / Java is oor die algemeen 'n optimale vir uitvoering maar daar is 'n trade-off in die ontwikkeling tyd, toetsing en gemak van die onderhoud. Dinamiese-getik tale, soos Python en Perl is nou algemeen vinnig genoeg. Maak altyd seker dat die komponente is ontwerp om in 'n modulêre wyse (sien onder), sodat hulle kan omgeruil uit die stelsel skale. Argitektoniese beplanning en ontwikkelingsproses Die komponente van 'n handel stelsel, die frekwensie en volume vereistes wat hierbo bespreek is, maar stelsel infrastruktuur het nog gedek moet word. Diegene wat optree as 'n kleinhandel handelaar of besig om in 'n klein fonds sal waarskynlik dra baie regeer. Dit sal die finale implementering van die stelsel wat nodig is om te wees wat die alfa model, risikobestuur en uitvoering parameters wees, en ook. Voordat delf in spesifieke tale die ontwerp van 'n optimale stelsel argitektuur bespreek sal word. Skeiding van Kommer Een van die belangrikste besluite wat by die begin moet word, is hoe om die belange van 'n handel stelsel te skei. In die ontwikkeling van sagteware, beteken dit in wese hoe om op te breek die verskillende aspekte van die handel stelsel in aparte modulêre komponente. Deur bloot koppelvlakke by elk van die komponente is dit maklik om te ruil uit dele van die stelsel vir ander weergawes wat prestasie hulp, betroubaarheid of onderhoud, sonder om die wysiging enige eksterne afhanklikheid kode. Dit is die beste praktyk vir sulke stelsels. Vir strategieë teen laer frekwensies sulke praktyke word aangeraai. Vir ultra hoë frekwensie handel die reëlboek mag hê om dit te ignoreer ten koste van die opstel van die stelsel vir nog meer prestasie. 'N Meer styf gekoppel stelsel wat wenslik mag wees. Die skep van 'n komponent kaart van 'n algoritmiese handel stelsel is 'n artikel op sigself die moeite werd. Maar 'n optimale benadering is om seker te maak daar is afsonderlike komponente vir die historiese en real-time mark data insette, data stoor, toegang tot die inligting API, backtester, strategie parameters, portefeulje konstruksie, risikobestuur en outomatiese uitvoering stelsels. Byvoorbeeld, as die data stoor wat gebruik is tans onderpresteer, selfs teen beduidende vlakke van optimalisering, kan dit omgeruil met 'n minimale herskryf om die data inname of toegang data-API. Sover die as backtester en daaropvolgende komponente betref, is daar geen verskil. Nog 'n voordeel van vervreem komponente is dat dit kan 'n verskeidenheid van programmeertale wat gebruik word in die algehele stelsel. Daar is geen rede om te beperk tot 'n enkele taal as die kommunikasie metode van die komponente is taal onafhanklik. Dit sal die geval wees indien hulle kommunikeer via die TCP / IP, ZeroMQ of 'n ander taal-onafhanklike protokol. As 'n konkrete voorbeeld, kyk na die geval van 'n back testing stelsel in C vir verwerking van syfers prestasie geskryf, terwyl die portefeuljebestuurder en uitvoering stelsels in Python geskryf met behulp van Scipy en IBPy. Prestasie oorwegings prestasie is 'n belangrike oorweging vir die meeste handel strategieë. Vir hoër frekwensie strategieë is dit die belangrikste faktor. Prestasie dek 'n wye verskeidenheid van onderwerpe, soos algoritmiese uitvoering spoed, netwerk latency, bandwydte, data I / O, concurrency / parallelisme en skalering. Elkeen van hierdie gebiede word individueel gedek deur groot handboeke, so hierdie artikel sal net krap die oppervlak van elke onderwerp. Argitektuur en taalkeuse sal nou in terme van hul effek op prestasie bespreek word. Die heersende wysheid soos deur Donald Knuth. een van die vaders van Rekenaarwetenskap, is dat voortydige optimalisering is die wortel van alle kwaad. Dit is byna altyd die geval nie - behalwe wanneer die bou van 'n hoë frekwensie handel algoritme Vir diegene wat belangstel in die laer frekwensie strategieë is, 'n gemeenskaplike benadering is om 'n stelsel te bou in die eenvoudigste manier moontlik en net optimaliseer as knelpunte begin om te verskyn. Profilering gereedskap gebruik om te bepaal waar knelpunte ontstaan. Profiele gemaak kan word vir al die bogenoemde faktore, hetsy in 'n MS Windows of Linux-omgewing. Daar is baie bedryfstelsel en taal gereedskap wat beskikbaar is om dit te doen, sowel as nuts derde party. Taalkeuse sal nou in die konteks van prestasie bespreek word. C, Java, Python, R en MatLab bevat almal 'n hoë-prestasie biblioteke (hetsy as deel van hul standaard of ekstern) vir basiese datastrukture en algoritmiese werk. C skepe met die Standard Sjabloon Biblioteek, terwyl Python bevat Numpy / Scipy. Gemeenskaplike wiskundige take te vinde in hierdie biblioteke en dit is selde voordelig vir 'n nuwe implementering skryf. Een uitsondering is wanneer hoogs persoonlike hardeware argitektuur vereis en 'n algoritme maak uitgebreide gebruik van eiendom uitbreidings (soos persoonlike caches). Maar dikwels heruitvinding van die wiel afval tyd dat 'n beter bestee kan word ontwikkel en die optimalisering van ander dele van die handel infrastruktuur. Ontwikkeling tyd is uiters kosbare veral in die konteks van uitsluitlike ontwikkelaars. Latency is dikwels 'n kwessie van die uitvoering stelsel as die navorsing gereedskap gewoonlik op dieselfde masjien. Vir die eerste keer nie kan latency voorkom by verskeie plekke langs die uitvoering pad. Databasisse moet geraadpleeg word (skyf / netwerk latency), seine moet gegenereer word (bedryfstelsel firmas, kernal boodskappe latency), handel seine gestuur (NIC latency) en bestellings verwerk (ruil stelsels interne latency). Vir hoër frekwensie bedrywighede is dit nodig om intiem vertroud is met kernal optimalisering asook die optimalisering van die netwerk oordrag geword. Dit is 'n diep gebied en is aansienlik buite die bestek van die artikel, maar as 'n UHFT algoritme dan verlang bewus te wees van die diepte van kennis wat nodig is Caching is baie nuttig in die toolkit van 'n kwantitatiewe handel ontwikkelaar. Caching verwys na die konsep van die stoor gereeld besoek data op 'n wyse wat toegang hoër-prestasie kan, ten koste van die potensiële staleness van die data. 'N Algemene gebruik geval kom voor in die web-ontwikkeling by die neem van die data van 'n skyf gerugsteun relasionele databasis en sit dit in die geheue. Enige daaropvolgende versoeke vir die data het nie na die databasis en so prestasie winste kan beduidend wees getref. Vir handel situasies kan caching uiters voordelig wees. Byvoorbeeld, kan die huidige stand van 'n strategie portefeulje bewaar word in 'n kas totdat dit herbalanseer, sodanig dat die lys nie die geval is moet herskep op elke lus van die handel algoritme. Sulke wedergeboorte is geneig om 'n hoë CPU of skyf I / O werking wees. Maar kas is nie sonder sy eie sake. Herlewing van die kas data in 'n keer, as gevolg van die volatilie aard van die kas stoor, kan beduidende vraag op infrastruktuur te plaas. Nog 'n probleem is hond-hei. waar verskeie generasies van 'n nuwe kas kopie onder uiters hoë lading, wat lei tot mislukking waterval gedra. Dinamiese geheuetoekenning is 'n duur operasie in uitvoering sagteware. Dit is dus noodsaaklik vir hoër prestasie handel aansoeke om goed bewus wees hoe geheue word toegeken en deallocated tydens program vloei. Nuwer taal standaarde soos Java, C en Python al uit te voer outomatiese vullisverwydering. wat verwys na deallocation van dinamiese toegeken geheue wanneer voorwerpe uitgaan van omvang. Vullisverwydering is baie nuttig tydens ontwikkeling as dit verminder foute en hulpmiddels leesbaarheid. Dit is egter dikwels sub-optimale vir sekere hoë frekwensie handel strategieë. Custom vullisverwydering word dikwels verlang vir hierdie gevalle. In Java, byvoorbeeld deur tuning die vullis versamelaar en hoop opset, is dit moontlik om 'n hoë werkverrigting vir HFT strategieë te verkry. C nie die geval bied 'n boorling vullis versamelaar en daarom is dit nodig om al geheuetoekenning / deallocation hanteer as deel van 'n implementering voorwerpe. Terwyl potensieel vatbaar fout (potensieel lei tot hangend wysers) is dit baie nuttig om fyn beheer van hoe voorwerpe verskyn op die hoop vir sekere aansoeke het. By die keuse van 'n taal te verseker om te bestudeer hoe die vullis versamelaar werk en of dit kan verander word om te optimaliseer vir 'n spesifieke gebruik geval. Baie bedrywighede in algoritmiese handel stelsels is vatbaar vir Parallellisatie. Dit verwys na die konsep van die uitvoering van verskeie programmatiese bedrywighede op dieselfde tyd, d. w.z in parallel. Sogenaamde embarassingly parallelle algoritmes sluit stappe wat ten volle onafhanklik van ander stappe kan bereken word. Sekere statistiese bedrywighede, soos Monte Carlo simulasies, is 'n goeie voorbeeld van embarassingly parallelle algoritmes soos elke ewekansige trekking en daaropvolgende operasie pad kan bereken word sonder kennis van ander paaie. Ander algoritmes is slegs gedeeltelik parallelisable. Vloeidinamika simulasies is so 'n voorbeeld, waar die domein van berekening kan onderverdeel, maar uiteindelik hierdie domeine moet met mekaar en sodoende die bedrywighede is gedeeltelik opeenvolgende kommunikeer. Parallelisable algoritmes is onderhewig aan Amdahls wet. wat 'n teoretiese boonste limiet aan die prestasie verhoging van 'n parallelised algoritme toe onderhewig aan N aparte prosesse (bv op 'n CPU kern of draad). Parallellisatie het al hoe belangriker as 'n middel van die optimalisering geword sedert verwerker klok-spoed het gestagneer, soos nuwer verwerkers bevat baie kern waarmee parallel berekeninge uit te voer. Die opkoms van die verbruikers grafiese hardeware (predominently vir die video speletjies) het gelei tot die ontwikkeling van grafiese verwerking van eenhede (GPU), wat honderde kerne vir hoogs konkurrente bedrywighede bevat. Sulke GPU's is nou baie bekostigbaar. Hoë-vlak raamwerke, soos Nvidias CUDA het gelei tot wydverspreide aanvaarding in die akademie en finansies. Sulke GPU hardeware is oor die algemeen slegs geskik vir die navorsing aspek van kwantitatiewe finansies, terwyl ander meer gespesialiseerde hardeware (insluitend veldwerk-programmeerbare Gate Arrays - FPGAs) word gebruik vir (O) HFT. Tans is die meeste moderne langauges ondersteun 'n mate van concurrency / multi-threading. Dit is dus maklik om 'n backtester optimaliseer, aangesien alle berekeninge is oor die algemeen onafhanklik van die ander. Skalering in sagteware-ingenieurswese en bedrywighede verwys na die vermoë van die stelsel om konsekwent te verhoog vragte in die vorm van 'n groter versoeke, hoër gebruik verwerker en meer geheue toekenning te hanteer. In algoritmiese handel strategie is in staat om te skaal as dit groter hoeveelhede kapitaal kan aanvaar en steeds lewer konsekwente opbrengste. Die handel tegnologie stapel skale as dit groter handel volumes en verhoogde latency kan verduur, sonder Bottelnek. Terwyl stelsels moet ontwerp volgens skaal, is dit dikwels moeilik om vooraf te voorspel waar 'n bottelnek sal plaasvind. Wettisch meld, toetsing, profilering en monitering sal grootliks help in sodat 'n stelsel op skaal. Tale self dikwels beskryf as onbestygbare. Dit is gewoonlik die gevolg van verkeerde inligting, eerder as harde werklikheid. Dit is die totale tegnologie stapel wat gevolg moet word vasgestel vir scalability, nie die taal. Dit is duidelik dat sekere tale het 'n groter prestasie as ander in die besonder gebruik gevalle, maar een taal is nooit beter as 'n ander in elke sin. Een middel van die bestuur van skaal is kommer skei, soos hierbo genoem. Met die oog op die vermoë om spykers te hanteer in die stelsel (dit wil sê 'n skielike wisselvalligheid wat 'n reeks van bedrywe snellers) verder te voer, is dit nuttig om 'n boodskap toustaan ​​argitektuur te skep. Dit beteken eenvoudig die plasing van 'n boodskap tou stelsel tussen komponente sodat bestellings gestapel as 'n sekere komponent is nie in staat om baie versoeke te verwerk. Eerder as om versoeke verlore hulle is eenvoudig gehou in 'n stapel, totdat die boodskap hanteer. Dit is veral nuttig vir die stuur van ambagte 'n uitvoering enjin. As die enjin is wat ly onder swaar latency dan sal dit te staaf ambagte. 'N tou tussen die handel seingenerator en die uitvoering API sal hierdie kwessie te verlig ten koste van potensiële handel glip. 'N gerespekteerde open source boodskap tou makelaar is RabbitMQ. Hardeware en bedryfstelsels Die hardeware bestuur van jou strategie kan 'n beduidende impak op die winsgewendheid van jou algoritme het. Dit is nie 'n probleem beperk tot 'n hoë frekwensie handelaars nie. 'N swak keuse in hardeware en bedryfstelsel kan lei tot 'n masjien crash of herlaai op die mees ongeleë oomblik. Dit is dus nodig om te oorweeg waar jou aansoek sal woon. Die keuse is oor die algemeen tussen 'n persoonlike lessenaar masjien, 'n afgeleë bediener, 'n wolk verskaffer of 'n ruil mede-geleë bediener. Desktop masjiene is maklik om te installeer en te administreer, veral met nuwer use bedryfstelsels soos Windows 08/07, Mac OSX en Ubuntu. Lessenaar stelsels te doen in besit te neem 'n paar belangrike nadele egter. Die eerste is dat die weergawes van bedryfstelsels ontwerp vir desktop masjiene is geneig om te herselflaai benodig / lap (en dikwels op die slegste tye). Hulle gebruik ook meer computational hulpbronne deur die hoofde van wat 'n grafiese gebruikerskoppelvlak (GUI). Benutting hardeware in 'n huis (of plaaslike kantoor) omgewing kan lei tot die internet konneksie en krag uptime probleme. Die grootste voordeel van 'n lessenaar stelsel is dat beduidende computational perdekrag kan gekoop word vir die fraksie van die koste van 'n afgeleë dedicated server (of wolk-gebaseerde stelsel) van vergelykbare spoed. 'N dedicated server of wolk-gebaseerde masjien, terwyl dikwels duurder as 'n lessenaar opsie, maak voorsiening vir meer betekenisvol ontslag infrastruktuur, soos outomatiese data rugsteun, die vermoë om meer reguit te verseker uptime en afgeleë monitering. Hulle is moeiliker om te administreer, aangesien hulle die vermoë om afgeleë login vermoëns van die bedryfstelsel gebruik vereis. In Windows is dit oor die algemeen deur die GUI Afstandwerkskerm protokol (RDP). In Unix-gebaseerde stelsels Veilige die opdrag-lyn skil (SSH) is gebruik. Unix-gebaseerde bediener infrastruktuur is byna altyd command-line gebaseer wat onmiddellik lewer-GUI gebaseer programmeringshulpmiddels (soos Matlab of Excel) te onbruikbaar wees. 'N mede-geleë bediener, as die frase gebruik word in die finansiële markte, is bloot 'n toegewyde bediener wat woonagtig is in 'n ruil ten einde latency van die handel algoritme te verminder. Dit is absoluut noodsaaklik vir sekere hoë frekwensie handel strategieë, wat staatmaak op 'n lae latency om alfa genereer. Die finale aspek hardeware keuse en die keuse van programmeertaal is platform-onafhanklikheid. Is daar 'n behoefte aan die kode uit te voer oor verskeie verskillende bedryfstelsels Is die kode wat ontwerp is om te loop op 'n spesifieke tipe verwerker argitektuur, soos die Intel x86 / x64 of sal dit moontlik om uit te voer op RISC verwerkers wees soos dié vervaardig deur ARM sal hierdie kwessies hoogs afhanklik van die frekwensie en tipe strategie geïmplementeer word. Veerkragtigheid en toetsing Een van die beste maniere om 'n klomp geld op algoritmiese handel verloor is om 'n stelsel te skep met geen veerkragtigheid. Dit verwys na die duursaamheid van die stelsel word wanneer onderhewig aan seldsame gebeurtenisse, soos makelaars bankrotskappe, skielike oortollige wisselvalligheid, streek-wye stilstand vir 'n wolk bediener verskaffer of die toevallige skrap van 'n hele handel databasis. Jaar van winste uitgeskakel kan word binne sekondes met 'n swak ontwerpte argitektuur. Dit is absoluut noodsaaklik om kwessies soos debuggng, toets, aan te meld, rugsteun, hoë-beskikbaarheid en monitering as kernkomponente van jou stelsel te oorweeg. Dit is waarskynlik dat in enige redelik ingewikkeld persoonlike kwantitatiewe handel aansoek ten minste 50 van die ontwikkeling tyd sal bestee word aan ontfouting, toetsing en onderhoud. Byna alle programmeringstale óf skip met 'n gepaardgaande debugger of besit gerespekteerde derde party alternatiewe. In wese is, 'n debugger laat uitvoering van 'n program met invoeging van arbitrêre breek punte in die kode pad, wat uitvoering tydelik te staak ten einde die toestand van die stelsel te ondersoek. Die grootste voordeel van debugging is dat dit moontlik is om die gedrag van die kode voor te ondersoek om 'n bekende ongeluk punt. Ontfouting is 'n noodsaaklike komponent in die toolbox vir die ontleding van programmering foute. Tog is dit meer algemeen gebruik word in saamgestel tale soos C of Java, as dit vertaal word tale soos Python is dikwels makliker om te ontfout weens minder LOC en minder uitgebreide verklarings. Ten spyte van hierdie tendens Python beteken skip met die PDB. Dit is 'n gesofistikeerde debugging hulpmiddel. Die Microsoft Visual C IO besit uitgebreide GUI ontfouting nuts, terwyl dit vir die command line Linux C programmeerder, die gdb debugger bestaan. Toets in sagteware-ontwikkeling verwys na die proses van die toepassing van bekende parameters en resultate om spesifieke funksies, metodes en voorwerpe binne 'n kodebasis, ten einde gedrag na te boots en verskeie kode-paaie te evalueer, te help om te verseker dat 'n stelsel optree soos dit hoort. 'N Meer onlangse paradigma staan ​​bekend as Toets Driven Ontwikkeling (TDD), waar toets kode ontwikkel teen 'n bepaalde koppelvlak met geen implementering. Voor die voltooiing van die werklike kodebasis alle toetse sal misluk. Soos kode is geskryf om die spasies in te vul, sal die toetse uiteindelik al slaag, op watter punt ontwikkeling moet ophou. TDD vereis uitgebreide vooraf spesifikasie ontwerp asook 'n gesonde mate van dissipline ten einde suksesvol uit te voer. In C, Boost bied 'n eenheid toets raamwerk. In Java, die JUnit biblioteek bestaan ​​om dieselfde doel te bereik. Python het ook die unittest module as deel van die standaard biblioteek. Baie ander tale beskik eenheid toets raamwerke en dikwels is daar verskeie opsies. In 'n produksie-omgewing, gesofistikeerde meld is absoluut noodsaaklik. Meld verwys na die proses van uitdruk boodskappe, met verskillende grade van erns, met betrekking tot die uitvoering gedrag van 'n stelsel om 'n plat lêer of databasis. Logs is 'n eerste linie van aanval wanneer jag vir onverwagte program runtime gedrag. Ongelukkig is die tekortkominge van 'n te meld stelsel is net tot ontdek nadat die feit Soos met rugsteun hieronder bespreek, moet 'n te meld stelsel gegee word behoorlike oorweging voor 'n stelsel is ontwerp. Beide Microsoft Windows en Linux kom met 'n uitgebreide stelsel aan te meld vermoë en programmeertale is geneig om te skip met die standaard te meld biblioteke wat die meeste gebruik gevalle te dek. Dit is dikwels wys wees om te sentraliseer meld inligting ten einde dit te analiseer op 'n later datum, aangesien dit dikwels kan lei tot idees oor die verbetering van prestasie of foute te verminder, wat byna seker 'n positiewe impak op jou handel opbrengste sal hê. Terwyl meld van 'n stelsel sal inligting oor wat geblyk in die verlede voorsien, sal monitering van 'n aansoek insig in wat nou gebeur voorsien. Alle aspekte van die stelsel moet in ag geneem word vir die monitering. Stelsel vlak statistieke soos skyf gebruik, beskikbare geheue, netwerk bandwydte en CPU gebruik voorsien basiese vrag inligting. Trading statistieke soos abnormale pryse / volume, skielike vinnige onttrekkings en rekening blootstelling vir verskillende sektore / markte moet ook deurlopend gemonitor. Die volgende stap is om te bespreek hoe programmeertale algemeen geklassifiseer. Michael Saal-Moore Mike is die stigter van QuantStart en is betrokke by die kwantitatiewe finansiële sektor vir die afgelope vyf jaar, in die eerste plek as 'n quant ontwikkelaar en later as 'n quant handelaar konsultasie vir verskansingsfondse.