Best Practise runt Ordermodeller

[Rikard Nilsson]

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?

En variant är att lägga hela eller delar av (så mycket som behövs) triggerscriptet i antalscriptet så att samma logik används även där för att avgöra insatsen etc. Sparar man då dessutom ned köpkod med retval i triggerscriptet vet man i efterhand vilken strategi som köpte, och antalscriptet har handlat för rätt belopp.

[PerG]

Precis som jimmy säger så klustrar många signaler till mycket hög grad (då jag främst handlar just innan call:en) detta leder till att jag ogärna vill jobba mot en global/ini slot för att risken att spara över den blir stor om många ordermodeller snurrar samtidigt.

Jag ser ju gärna att jag kan använda en pappersspecifik slot för att skriva in edgen. Om man inte kan skriva till scrPar uppfyller inte det syftet.

Visst kan man använda en slot i ini-filen per papper och läsa med crcid() vilken slot man skall gå till, men det vore faktiskt trevligast att bara använda en pappersspecifik slot och lämna de ini-variablerna tillgängliga för annat. Om man vill handla Large-cap blir det ju rätt stora IF-satser för att att mappa till rätt ini-variabel med vilket borde bloata scriptet och dra ned prestanda.

Då återstår frågan vilka slots som är pappersspecifika man kan skriva till genom sl/insats-script ?

[jimmy]

Hej PerG,

Jag tycker Rickards alternativ att flytta edge beräkningen till antal skriptet låter bäst/enklast och renast. Om det inte funkar har du kanske ett behov/krav som jag/vi inte riktigt uppfattat.

Om ini fil inte har någon tråd problematik (vad jag föreslog) borde det också gå. Jag hade själv använt eget id för att få kontroll på vilka idn som används i vilken range i ini filen, iställert för aktiens id vilket skulle skapa allokeringar på en väldigt utspridd nyckel idn.

[Rikard Nilsson]

Det går utmärkt att sätta ett eget id i en bestämd plats i Indarascript så kan exakt samma script användas för alla aktier. Id motsvara då den cell tex i ini-filen man skriver till. Annars är lösningen med triggerscript inbakat i antalscript enklast.

[PerG]

Vi alla pratar säkert om samma sak fast från olika sätt/synvinklar.

Jag vill egentligen bara ha svar på en sak, och om det finns någon papperspecifik slot som INTE är ini som går att skriva och läsa från trigger/insatsscript. Om ja, vad heter det kommandot ?

Om det INTE finns så får jag leva med att flytta viss logik till insatsscripten (från sl-scripten) och istället skapa lite mer avancerade insatsscript som är unikt för varje ordermodell. Då behöver jag veta om ordermodellerna körs parralellt, dvs ex 20st ordermodeller samtidigt, eller om de körs en efter en ? beroende på svaret kan det blir problem att ordermodellerna sparar över värdet i ini-filen för varandra om man bara jobbar med 1 slot för alla ordermodellerna.

[LillWicke]

Jag vill egentligen bara ha svar på en sak, och om det finns någon papperspecifik slot som INTE är ini som går att skriva och läsa från trigger/insatsscript. Om ja, vad heter det kommandot ?

Det finns bara två Nat-funktioner som kan skriva externt och som kan användas till att lagra och hämta värden med.
Dessa är Globala variabler (SetgvarIf) eller skriva till ini-filen (SetiniIf)

Om det INTE finns så får jag leva med att flytta viss logik till insatsscripten (från sl-scripten) och istället skapa lite mer avancerade insatsscript som är unikt för varje ordermodell. Då behöver jag veta om ordermodellerna körs parralellt, dvs ex 20st ordermodeller samtidigt, eller om de körs en efter en ? beroende på svaret kan det blir problem att ordermodellerna sparar över värdet i ini-filen för varandra om man bara jobbar med 1 slot för alla ordermodellerna.

Helt parallellt tror jag aldrig du kan få någonting någonsin att köra, men beroende på att NAT numera är trådat och om du kör med en flerkärning processor kan du nog få det till att bli hyfsat parallellt.

Att använda endast EN global variabel till samtliga modeller skulle nog jag aldrig göra även om de körde helt parallellt, alldeles för stor risk precis som du säger.
Om du istället tilldelar en specifik global cell/variabel till varje modell får du på köpet en identifierare av varje modell och kan sedan agera på olika sätt beroende på vilken modell det är som triggar.

När det gäller vad scripten skall göra utifrån vilken aktie som för närvarande behandlas, kan du knappa in olika koder procentsatser eller vad det kan vara för varje aktie för sig i "indata script". Dessa värden kan sedan läsas av scripten med funktionen "scarpar" varvid du då kan få scripten att agera olika beroende på vilken aktie som behandlas.

[Henric]

Jag har samma fråga som Per G. Jag trodde ordermodellerna kördes en efter en och hela vägen oavsett dator? sl) -> va) -> vl) -> xk) -> order. Skulle flera script köras samtidigt skulle väl det kunna uppstå andra problem med globala celler, etc. Är det så räcker det med att börja med att nollställa och därefter eventuellt sätta värde i sl-scriptet. För att vara säker kanske använda två celler. En med crcid och en för värde. Fungerar körningar live och analysbänken på exakt samma sätt?

[Rikard Nilsson]

Det är inte helt korrekt att endast SetGVarIf och SetIniIf är de enda sätten att skriva ned något till disk, om man använder retval vid order lagras det i TRANS.DFB och kan läsas ut av tex Excel.

Det är en intressant ide att använda en enda global cell faktiskt, jag har för mig att det körs i den här ordningen:

1. Triggerscript
2. Om trigger löser ut > xk) > va) > vl) > st)
3. Nästa ordermodell > samma sak som punkt 2.

Därmed bör det vara möjligt att skicka ett värde från triggerscriptet i en global cell som de andra scripten i samma ordersekvens läser av någon ms senare när ordern byggs upp. Får dubbelchecka detta med Lasse dock. Inget lagras dock i så fall, när nästa ordersekvens eller ordermodell körs skrivs ju värdet över igen. Därför är nog retval() bättre eftersom man då får info sparat med transaktionen som kan läsas av senare från vilket script som helst. Trådningen av AT berör andra saker än just surveillance-tråden som sköter scriptexekvering och orderläggning. KS-hantering och analyzer är sånt som trådas.

[LillWicke]

Det är inte helt korrekt att endast SetGVarIf och SetIniIf är de enda sätten att skriva ned något till disk, om man använder retval vid order lagras det i TRANS.DFB och kan läsas ut av tex Excel.

Vi pratade om att NAT skulle skriva och läsa.
Med retval() kan man väl också bara skriva till 10 celler? Jag vet att cellerna även kan läsas med lasttrade(), men det blir ju problematiskt när dessa celler även används av Draw(), eller händer det något annat också som jag inte har koll på?

[LillWicke]

Jag har samma fråga som Per G. Jag trodde ordermodellerna kördes en efter en och hela vägen oavsett dator? sl) -> va) -> vl) -> xk) -> order. Skulle flera script köras samtidigt skulle väl det kunna uppstå andra problem med globala celler, etc. Är det så räcker det med att börja med att nollställa och därefter eventuellt sätta värde i sl-scriptet. För att vara säker kanske använda två celler. En med crcid och en för värde. Fungerar körningar live och analysbänken på exakt samma sätt?

Det är en intressant ide att använda en enda global cell faktiskt, jag har för mig att det körs i den här ordningen:

1. Triggerscript
2. Om trigger löser ut > xk) > va) > vl) > st)
3. Nästa ordermodell > samma sak som punkt 2.

Därmed bör det vara möjligt att skicka ett värde från triggerscriptet i en global cell som de andra scripten i samma ordersekvens läser av någon ms senare när ordern byggs upp. Får dubbelchecka detta med Lasse dock. Inget lagras dock i så fall, när nästa ordersekvens eller ordermodell körs skrivs ju värdet över igen. Därför är nog retval() bättre eftersom man då får info sparat med transaktionen som kan läsas av senare från vilket script som helst. Trådningen av AT berör andra saker än just surveillance-tråden som sköter scriptexekvering och orderläggning. KS-hantering och analyzer är sånt som trådas.

Att ordermodellen INTERNT körs sekventiellt dvs. sl)- > xk) > va) > vl) > st) har nog de flesta uppfattat det som att de gör, allt annat vore konstigt (nu blir jag emellertid lite orolig då Rikard säger att han ska dubbelkolla detta med Lasse).

Emellertid uppfattade jag det som att Per frågande efter om själva ordermodellerna kan köras parallellt. Jag har alltid tänkt mig att detta eventuellt kunde bli fallet och har anpassat mina globala variabler efter detta.

Nu säger Rikard att all scripexekvering sker i samma tråd vilket ju betyder att även ordermodellerna alltid körs sekventiellt, så man undrar om det alltid kommer att vara så, eller om det bara är så som det är nu?

[Rikard Nilsson]

Vi pratade om att NAT skulle skriva och läsa.
Med retval() kan man väl också bara skriva till 10 celler? Jag vet att cellerna även kan läsas med lasttrade(), men det blir ju problematiskt när dessa celler även används av Draw(), eller händer det något annat också som jag inte har koll på?

Nja, det blir faktiskt inte så eftersom värdena som Draw sätter i cellerna görs högre upp i scriptet och ändå skrivs över i slutet när man låter retval skriva eventuella edge-koder och annat som ska sparas med transaktionen. Dvs, värdena som finns i det ögonblick ordern sänds är de värden som sparas till Loggade lokala ordertransaktioner.

[Rikard Nilsson]

Att ordermodellen INTERNT körs sekventiellt dvs. sl)- > xk) > va) > vl) > st) har nog de flesta uppfattat det som att de gör, allt annat vore konstigt (nu blir jag emellertid lite orolig då Rikard säger att han ska dubbelkolla detta med Lasse).

Emellertid uppfattade jag det som att Per frågande efter om själva ordermodellerna kan köras parallellt. Jag har alltid tänkt mig att detta eventuellt kunde bli fallet och har anpassat mina globala variabler efter detta.

Nu säger Rikard att all scripexekvering sker i samma tråd vilket ju betyder att även ordermodellerna alltid körs sekventiellt, så man undrar om det alltid kommer att vara så, eller om det bara är så som det är nu?

Att det är samma tråd som kör alla script och ordermodeller finns det inga planer att ändra på. Det körs sekventiellt, och jag vill bara dubbelkolla med Lasse i exakt vilken ordning, men har för mig att det körs i ordermodellernas ID-ordning.

[storuman1]

Ordermodells id

Kan någon förklara ordermodellernas id-ordning? Hur vet jag vilket id en ordermodell har?

[Rikard Nilsson]

Det syns nog inte någonstans i programmet har jag för mig, men det går fint att öppna filen ORDR.DBF i tex Open Office (eller Excel) så syns ordermodell-ID till vänster i andra kolumnen. Det är en 4 digit bokstavs- och teckenkombo.