Best Practise runt Ordermodeller

[PerG]

Sitter och funderar på hur man bäst bygger ordermodeller ur skalbarhetssynpunkt.

Låt oss säga att jag har 6 olika varianter av strategin Rikoshett där varje variant har olika edge, passar olika marknader och skall handlas med dynamisk insats.

1)
Är det best pratice att använda en ordermodell och 6st sl) script, och sedan plocka insatsen genom att dynamiskt insatsscript för hela ordermodellen som läser ex från globala variabler vilken insats de skall använda beroende på vilket av de 6 st sl)-scripten som triggade?

2)
eller går det snabbare (prestandamässigt) att köra med 6st separata ordermodeller? (ha i åtanke att det körs många andra ordermodeller samtidigt med andra strategier ex att den skall klara 30-tal ordermodeller)

3)
Vilken ordning exekeveras ordermodellen och scripten? loopar den igenom alla sekvenser i ordermodellen innan insatsscriptet körs, eller körs insatsscriptet i varje sekvens som scriptet triggas? (dvs i detta fall 6ggr )

4)
Om ett sl) script inte skjuter, fastnar ordermodellen i den sekvensen eller kan få ordermodellen att loopa hela tiden+

[Rikard Nilsson]

Bra inlägg, kan vara till stor nytta för andra scriptare!

1. Det du beskriver är en variant, även om det kanske lätt blir lite "klumpigt" med många sekvenser osv. Jag skulle nog titta på möjligheterna att baka in alla sex varianterna i samma triggerscript. Då skulle det bara behövas två parallella ordermodeller, en för köp och en för sälj. Du kan fortarande låta insatsscriptet läsa av en cell som styrs från triggerscriptet och avgör hur mycket pengar som ska investeras osv vid olika kriterier.

2. Snabbare med 6 parallella modeller än vadå? En superordermodell med alla sekvenser i samma modell? Eller som i punkt 1, med all logik i endast två triggerscript? Det går att göra på samtliga sätt, men min gissning är att det blir snabbast med så få triggerscript som möjligt.


3. Ordermodellerna kör en efter en enligt ID-ordning. Endast den sekvens man "står på nu" körs. Först när triggerscriptet larmar körs insatsscript, prisscript och ev kontrollscript.

4. Om triggerscriptet inte larmar kommer modellen inte vidare till nästa sekvens. Om detta är önskvärt är man hänvisad till fler parallella ordermodeller som kan lägga order enligt de kriterier man vill.

[LillWicke]

Jag tittade lite på det här när jag började scripta i NAT. Tyckte först att det verkade smart att kunna bygga ordermodeller med olika sekvenser, men lämnade detta rätt snart och kör numera enbart med parallella modeller.

[PerG]

OK, enligt detta förutsättningen verkar det alltså klokast med 6st parallella ordermodeller. Dock kommer det att leda till skalbarbetsproblem i takt med att man kanske snurrar 50 ordermodeller parallellt som s i sin tur "fyller" NAT-threaden.

@Rickard, hur många ordermodeller orkar NAT med som ex handlar under samma period? ex i samband med callen.

Om man istället för att köra 6 paralella ordermodeller går på att baka in allt i ett sl)-script så kommer man väl inte att veta vilket "case" som gjorde att scriptet sköt i loggen. Dvs så länge det inte finns någon "echo" eller "print" funktion till meddelandefönstret så blir det svårt att följa vilken av de 6 varianterna som gjorde att sl)-scriptet sköt.

Gällande om man skall sätta insatsen för varje instrument, det kan väl här vara en fördel att hålla Ini-filen utanför för att inte ta upp onödiga slots, och istället titta på något instrument-specifikt.. bör ScrPar() användas för att lagra den aktuella insatsen just nu , eller någon annan slot som bara är kopplat till papperet? eller vad rekommenderas?

[jimmy]

Hej,

Kanske du kan låta varje delvillkor få ett id. T. Ex. Id, 1-6. Och skriva det till en Global cell som du kan titta på i kalkylen eller fil. . Vill du kombinera med annat id kan man använda decimal eller punkt som separator. Ex. "id" . "id" . Kan ju vara ordermodell id. Entry id.

Önskar också loggningsfunktion..

[Rikard Nilsson]

[QUOTE=PerG;29570]OK, enligt detta förutsättningen verkar det alltså klokast med 6st parallella ordermodeller. Dock kommer det att leda till skalbarbetsproblem i takt med att man kanske snurrar 50 ordermodeller parallellt som s i sin tur "fyller" NAT-threaden.

@Rickard, hur många ordermodeller orkar NAT med som ex handlar under samma period? ex i samband med callen.

Om man istället för att köra 6 paralella ordermodeller går på att baka in allt i ett sl)-script så kommer man väl inte att veta vilket "case" som gjorde att scriptet sköt i loggen. Dvs så länge det inte finns någon "echo" eller "print" funktion till meddelandefönstret så blir det svårt att följa vilken av de 6 varianterna som gjorde att sl)-scriptet sköt.

QUOTE]

Hej,

Kanske du kan låta varje delvillkor få ett id. T. Ex. Id, 1-6. Och skriva det till en Global cell som du kan titta på i kalkylen eller fil. . Vill du kombinera med annat id kan man använda decimal eller punkt som separator. Ex. "id" . "id" . Kan ju vara ordermodell id. Entry id.

Önskar också loggningsfunktion..

Det går ju utmärkt att använda retval() och spara ned ett ID med transaktionen så loggas det ju så att man kan ta reda på vilken strategi som öppnade en viss position osv:

Kodavsnitt 1 i triggerscriptet:

kod1=if(strategi1,1,0)
kod2=if(strategi2,2,0)
kod3=if(strategi3,3,0)
köpkod=add(kod1,add(kod2,kod3))

retval(köpkod,1)

skriver köpkod till cell 1 vid köp. Därefter kan vilket script som helst få reda på det genom lasttrade(b,1)

Allt loggas då också i Lokala loggade ordertransaktioner så att man kan se det senare, eller ta ut det via TRANS.DBF om man vill öppna i tex Excel.

[PerG]

Ja, men detta kräver som du säger att man går igenom historiken i .DBF.
Jag menar att jag gärna vill se det i "larm/meddelande". och i mejlen.

Min fråga ang ScrPar() är att jag vill ha ett sätt att sätta dynamisk insatsen i en cell/variabel (genom sl-scriptet) för traden i samband med att den tas (beroende på edge), och den skall vara pappersspecifik för att undvika att man sparar över insatsen genom att ordemodellen körs mot ex alla large-cap aktier samtidigt.

Finns det något papperspecifik slot som lämpar sig för detta? (undviker gärna globala vars i detta fall)

[Bertil]

Alla Scrpar är ju pappersspecifika. Problemet är ju att det är antalsscriptet som ger hur mycket man skall köpa. sl) scriptet triggar ju bara handel. Svårt att lösa ditt problem utan globala variabler. Men du kan ju ha flera sl script. Ett basscript som köper på vissa villkor och ytterligare ett sl script som slår till då du har mer edge. Sl scripten får ju då vara kopplade till olika antalsscript som tittar på olika scrpar.
mvh
Bertil

[PerG]

Så här tänker jag

1) sl-script > Sparar till scrPar ned edge/insatsfaktor beroende på vilket "case" i sl-skriptet som triggar.

2) insatsskriptet läser sedan från scrPar bör att veta hur stor edge som är i spel i denna aktie (insatsfaktor) och läser av portföljstorlek (och anpassar insatsen i exakta kr.)

3) ordermodellen tar värdet från insatsscriptet i kr, och genomför traden.


Vilka slots är lämpliga att använda i scrPar för detta syfte?

[jimmy]

Hej,

Man kan väll inte spara till scrpar. Utan läsa vad som sats som input i fältet. Dessa fällt är begränsat till antal mig veterligen.

Så därför tänker jag mig en lösning så här för att slippa ha olika SL skript (kod) men istället ett generellt och använda konfiguration.

Exempel
Du har 50 aktier.
I ett scrpar fält x sätter du ett unikt id som du tilldelar per aktie.
Tex. ABB får ID 1, ERIC får ID 2 osv

I din kod i SL läser du in id för pappret som den är ansluten till med scrpar från fältet x som du själv valt (ledigt)
När du beräknar edge skriver du SetIniIf(edge, id, 1) till fill.
I ditt prisskript läser du in vilket id du har för pappret med scrpar och sätter det i GetIni() som returnerar din edge
Nu har du passat värdet till prisskriptet med enbart konfiguration.

Detta är en otestad idé som jag tycker borde funka. Tidsinsatsen borde vara vid ett tillfälle att tilldela ett id per aktie.
Kanske bör man i exit skriptet nollställa edgen i filen så att den alltid är noll om riktig signal inte skickats.

[Henric]

Hej,

Man kan väll inte spara till scrpar. Utan läsa vad som sats som input i fältet. Dessa fällt är begränsat till antal mig veterligen.

Så därför tänker jag mig en lösning så här för att slippa ha olika SL skript (kod) men istället ett generellt och använda konfiguration.

Exempel
Du har 50 aktier.
I ett scrpar fält x sätter du ett unikt id som du tilldelar per aktie.
Tex. ABB får ID 1, ERIC får ID 2 osv

I din kod i SL läser du in id för pappret som den är ansluten till.
När du beräknar edge skriver du SetIniIf(edge, id, 1) till till fill.
I ditt prisskript läser du in vilket id du har för pappret med scrpar och sätter det i GetIni() som returnerar din edge
Nu har du passat värdet till prisskriptet med enbart konfiguration.

Detta är en otestad idé som jag tycker borde funka. Tidsinsatsen borde vara vid ett tillfälle att tilldela ett id per aktie.
Kanske bör exit skriptet nollställa edgen i filen så att den alltid är noll om riktig signal inte skickats.

En variant är att endast använda en global cell. Varje ordermodell börjar med att nollställa cellen. Edge lagras i cellen vid signal. Antalscriptet använder sedan värde för beräkning. Har inte testat med borde fungera.

Om ett stort antal aktier handlas för samma grundinsats är det enklare att använda en global cell där värdet sätts i ett script. Allt beror givetvis på metod, etc.

Loggning blir komplicerat. (Antal kombinationer köp * antal instrument) + (Antal kombinationer sälj * antal instrument). För backtesting går det enkelt att lägga till extrakolumner.

[jimmy]

Hej,
Risken med en Global cell är att PerG troligen får ett kluster av signaler och vill köpa en viss tidpunkt. Så det blir konflikt om den cellen. Jag utgår från att det var en del av kravet.
Jag ser dock risker med mitt förslag om filskrivning sker samtidigt och det inte hanteras rätt (en eller flera trådar) i NAT. Det har kanske redan uträtts tidigare eller så kan nog någon bekräfta det som vet hur det implementerats.

[jimmy]

Hej igen,

Det jag inte vet är om ini fil och och scrpar funkar i backtestat enligt mitt föregående inlägg . Någon som vet (ifall det var det du menade Henrik) ?

[LillWicke]

Sedan ska vi inte glömma bort funktionen CRCID(). Den funktionen returnerar instrumentets ID som ett decimaltal.

Den som har skrivit beskrivningen i scriptmanualen måste däremot ha varit bakfull
http://www.autostock.se/NATscriptref/CRCID.html

[jimmy]

Sedan ska vi inte glömma bort funktionen CRCID(). Den funktionen returnerar instrumentets ID som ett decimaltal.

Den som har skrivit beskrivningen i scriptmanualen måste däremot ha varit bakfull
http://www.autostock.se/NATscriptref/

Haha. Ja den var bra.

Perfekt i så fall behövs inte äns konfiguration av scrpar.

Saken är biff.