Välja strategi för handels/ordermodeller

[shadowtwister]

Hej,

Har blivit dags för mig att välja strategi för hur ordermodeller bör implementeras,
dvs. bestämma handelsmodellen/handelsstrategin.

Det finns ju många olika sätt att gå tillväga. För att inte välja fel sätt och
kanske tvingas göra om i ett senare skede tog jag dagen till att fundera
igenom vilken variant/strategi av ordermodeller som har störst
sannolikhet att fungera.

Har gjort en powerpoint-presentation (se bifogad fil) med hur jag ser
verkligheten just nu gällande ordermodeller.

Skulle vara trevligt om vi kan ha en diskussion i denna tråden om de antaganden
jag gjort stämmer, om de kan förbättras eller om det är totalt feltänk
i någon av varianterna av ordermodeller.

/Robban

[Rikard Nilsson]

Wow, vad snyggt du gjort! Riktigt bra genomgång av olika varianter.

[shadowtwister]

Wow, vad snyggt du gjort! Riktigt bra genomgång av olika varianter.

Tack Rikard.
Tror jag tänkt hyfsat rätt, men det är säkert något som jag inte tänkt på
som kan hända vid testning. Så länge grundidén är rätt uppfattad dock så
blir det ju lite enklare att åtgärda det.

[LillWicke]

Ambitiös genomgång, mycket bra gjort.

Man skulle också kanske kunna tillägga att de vi i vardagslag här på forumet brukar kalla "platta" ordermodeller är den variant vi ser i nr2,
och de vi brukar kalla sekvensbaserade modeller är de vi ser i nr3-6.

Nr1 är väldigt ovanlig, om den ska fungera som handelsmodell, och används vad jag känner till endast för stopploss/takeprofit/bevaknings-modeller för manuellt lagda ordrar.

[shadowtwister]

Intressant om nr 1. Den varianten skulle då kunna vara fristående script som
ingår som komplement till ordermodeller. Det skulle göra handelsmodellen mer flexibel.
Jag lutar åt variant 4 just nu, men kan ju som sagt köra med ett gäng fristående script som diverse "add-ons".

[LillWicke]

Ja, "komplement till ordermodeller" är inte dumt. Själv kör jag ett antal fristående script som tittar på kursen genom olika glasögon och matar modellerna med data. Jag kallar dem kontrollskript.

För att man ska kunna köra dessa kontrollscript i bänken, måste man göra om dem till "fejkade" ordermodeller, och i dessa fall blir det då förstås nr2 man använder.

[shadowtwister]

Ja, "komplement till ordermodeller" är inte dumt. Själv kör jag ett antal fristående script som tittar på kursen genom olika glasögon och matar modellerna med data. Jag kallar dem kontrollskript.

För att man ska kunna köra dessa kontrollscript i bänken, måste man göra om dem till "fejkade" ordermodeller, och i dessa fall blir det då förstås nr2 man använder.

Ja, det är väl det bästa sättet att låta dessa köras kontinuerligt ?
Inte helt klar på hur man kan göra en fejkad ordermodell. Det låter som ett
bra knep för testning.

Läste i tråden http://www.autostock.se/vbulletin/showthread.php?t=2964
om bra sätt att ansluta fristående script. Är det så du gör kanske som
beskrivet där med fejkade ordermodeller ?

(Har inte gett mig in i bänkens förtrollade värld ännu.)

[Rikard Nilsson]

Jag skulle spontant också säga att variant 2 bör vara enklast att bygga. Då kan vilken signal agera när som helst och inget riskerar att fastna. Modellerna kan alltid fås att prata med varandra via Loggade lokala ordertransaktioner eller globala celler eller varför inte inifils-variabler.

Enda nackdelen är väl att det blir 4 modeller att ansluta.

[LillWicke]

Ja, det är väl det bästa sättet att låta dessa köras kontinuerligt ?
Inte helt klar på hur man kan göra en fejkad ordermodell. Det låter som ett
bra knep för testning.

Läste i tråden http://www.autostock.se/vbulletin/showthread.php?t=2964
om bra sätt att ansluta fristående script. Är det så du gör kanske som
beskrivet där med fejkade ordermodeller ?

(Har inte gett mig in i bänkens förtrollade värld ännu.)

Nja, att "fejka" en ordermodell till bänken eller "live" är enkelt.
Det är bara att skriva mult(1,0) sist i triggerscriptet så att modellen aldrig löser ut. Både "live" och bänken betraktar den då som en vanlig ordermodell och kör den som vanligt tillsammans med de andra "skarpa" modellerna. Den enda uppgift den fejkade modellen/kontrollmodellen har är ju att förse de övriga modellerna med specifik fakta.

[shadowtwister]

Jag skulle spontant också säga att variant 2 bör vara enklast att bygga. Då kan vilken signal agera när som helst och inget riskerar att fastna. Modellerna kan alltid fås att prata med varandra via Loggade lokala ordertransaktioner eller globala celler eller varför inte inifils-variabler.

Enda nackdelen är väl att det blir 4 modeller att ansluta.

Nattkörning igen..
Funderade på detta med kommunikation mellan script <--> ordermodeller
med variant 2 + fristående script.

Använda scrpar() verkar inte hållbart. Behövs ju manuell handpåläggning
och det tar bort idén med automatisering.

ini-fil kan ju vara en variant om man vill koppla in externa program till
att kommunicera med AT. I mitt fall är det dock inte aktuellt, i alla fall inte i dagsläget,
men framtiden kanske visar på annat.

Global variabel verkar enklast. Tar exempel med en tidsstopp jag vill
implementera.

{ gvar version. If time stop triggers, set gvar 115 to 1 to indicate this to the sell script. }

{ --- IN SEPARATE SCRIPT --- }
..
exit=... (fristående scripts logik triggar här)

{ Set gvar trigger if timeStop is true. }
setGlobal=setgvarif(1,115,exit)
and(setGlobal,1)


{ --- IN SELL SCRIPT --- }
..
timeStop=getgvar(115)
..

{ Add an or condition to check separate script status info from gvar 115. }
..
sell3=.. (grundvillkor för en säljsignal utan inverkan av separat script)
sell4=or(timeStop,sell3)
mult(sell4,1)

Sedan kan man ju bara bygga på med "add-ons" där varje separat script
behöver en egen global variabel + en läsning i säljscriptet + ett or-villkor
per separat script.

Variant 2 + fristående script verkar alltså vara en handelsmodell som
är enkel att implementera om man är beredd på lite extra pill med att
koppla på ordermodeller och extra script innan dagens handel börjar.

[shadowtwister]

Nja, att "fejka" en ordermodell till bänken eller "live" är enkelt.
Det är bara att skriva mult(1,0) sist i triggerscriptet så att modellen aldrig löser ut. Både "live" och bänken betraktar den då som en vanlig ordermodell och kör den som vanligt tillsammans med de andra "skarpa" modellerna. Den enda uppgift den fejkade modellen/kontrollmodellen har är ju att förse de övriga modellerna med specifik fakta.

Aha !
Det där var ju en snygg workaround. "You're full of surprises mr Baggins" som Gimli sa.

[shadowtwister]

{ Set gvar trigger if timeStop is true. }
setGlobal=setgvarif(1,115,exit)
and(setGlobal,1)

Bra att man testar. Funkar inte att sätta setgvarif() på ovan sätt.
Då får setGlobal alltid värdet 1.

Måste vända på det till setGlobal=setgvarif(exit,115,1) för att ta värdet på exit.

Märklig logik, den struntar i villkorstestet, men det funkar om man gör så här istället.

[Rikard Nilsson]

Nja, det är ju så att i första varianten sätts värdet 1 om villkoret Exit är sant. Sen finns det inget som tar bort ettan. Däremot, i andra varianten sätts värdet av villkoret kontinuerligt i cellen.

[shadowtwister]

Nja, det är ju så att i första varianten sätts värdet 1 om villkoret Exit är sant. Sen finns det inget som tar bort ettan. Däremot, i andra varianten sätts värdet av villkoret kontinuerligt i cellen.

Jo, det var så jag förstod det, men när jag testar:

exit=add(0,0)
test=setgvarif(1,115,exit)

så ger kalkylforskaren svaret 1 för test istället för 0.
Det ger också svaret 1 om jag provar med exit=add(0,1) vilket är
förväntat.

Provar jag istället med:

exit=add(0,0)
test=setgvarif(2,115,exit)

så ges värdet 2 för test. Detta tolkar jag som att test tar värdet som
ska sättas i den globala variabeln, oavsett vad testet av villkoret säger.
Jag har kanske tolkat exekveringsordningen och hur värden sätts på fel sätt.

[LillWicke]

Det du berör i inlägget ovan (#14) är en av de absolut bästa fördelarna med setgvarif.
Funktionen sätter ett nytt värde i cellen om villkoret är sant. Om villkoret istället är falskt lämnas innehållet orört.

I ditt fall vill du ju kontinuerligt lagra ett värde, nämligen det du får av "exit", och för att göra det måste ju villkoret alltid vara sant, annars lagras inget värde.

Det du själv kommit fram till "setGlobal=setgvarif(exit,115,1)" är i det här fallet det korrekta sättet att skriva på.