Räkning av antal poster som fått avslut

[apabarn]

Jag vill när en trigger löser ut vara säker på att få avslut på hela antalet poster som önskas. Anledningen till att jag helst inte vill lösa detta genom att buda långt förbi aktuell kurs är att market makern ibland hoppar ur någon sekund här och där, och då riskerar man att få betydligt sämre kurs på avslutet om man har otur vilket har hänt i test. Har istället skrivit en snurra som ser till att man fortsätter handla om man inte fått fullt avslut på första försöket.

Antalet som ska handlas ligger i global cell 1 i exemplet. Triggern löser ut om detta värde är över 0.

I global cell 2 sparas portföljvärdet, så att man kan jämföra varv för varv om det har ändrats sedan sist, i så fall antar man att man har handlat.

Om något handlats sedan förra varvet ("antal_diff") så ska det dras av från värdet i global cell 1, så att man endast handlar det som återstår i nästa varv. Om man fått avslut på hela det önskade antalet så ska det innebära att värdet i global cell 1 blir 0, så att scriptet inte fortsätter handla.

antal_diff=sub(portfolio(v),GetGVar(2))
SetGVarIf(sub(GetGVar(1),antal_diff),add(thisindex,1),gt(antal_diff,0))
SetGVarIf(portfolio(v),2,not(eqv(antal_diff,0)))

add(0,GetGVar(1))

Detta funkar fint i test, så till vida att den slutar handla efter att ha fått "avslut" på första försöket då portfolio(v) har ändrats med samma antal som önskades. Men kommer det att funka lika bra om man kör skarpt? Det hänger på att portfolio(v) hinner uppdateras omedelbart om man fått avslut på en order, redan innan nästa varv i scriptet körs. Annars skulle den fortsätta handla samma antal tills portfolio(v) hunnit uppdateras.

Finns det någon risk att portfolio(v) inte uppdateras lika fort när man kör skarpt som när man kör på testkonto? Och finns det i så fall någon bra lösning i allmänhet?

[Rikard Autostock]

Global cell 1 finns inte. Celler 0-9 är "lokala" som du kan använda med Retval() och Getval(), eller Lasttrade(b,0-4) osv. Även Draw() använder dessa. Dessa är instrument/kontounika.

Globala celler är 10-899, där 800-serien används av div standardmodeller etc. Det finns också 1001-9999, men ETP link använder 1010 till 4999 om du ansluter den.

[apabarn]

Okej! Det visste jag inte, då får jag byta plats på cellerna. Konstigt nog verkar det dock ha funkat när jag använt cellerna 0-9 än så länge då rätt värden kommit ut, trots att jag även använt Retval osv utan problem.

Men hur är de med portfolio(v) som jag undrade om? Kommer den att uppdateras omedelbart på samma sätt när man kör skarpt som när man kör på testkonto, eller kan det bli viss delay när denna ska hämtas från Nordnet istället för att bara beräknas lokalt? Om den inte alltid uppdateras redan till nästa "varv" i scriptet så behöver jag justera mitt sätt att räkna.

[Rikard Autostock]

Japp, Portfolio() uppdateras först när ordern skickas, och därefter igen så fort skarpt avslut kommer tillbaka från Nordnet. Någon sekund oftast, så i princip alltid nästa varv. Bäst är att alltid spara målantalet i cell 0-4 med retval() och därefter jämföra med portfolio(v) och justera tills det stämmer.

[apabarn]

Tack för svaret! Låter kanon om portfolio(v) hinner uppdateras så snabbt.

Jag glömde dock nämna att jag har ändrat SurveillanceInterval till 1000 i ini-filerna så att scipten ska köras varje sekund. Med tanke på detta, kommer portfolio(v) ändå i princip alltid hänga med och vara uppdaterad redan på nästa varv om man har handlat? Eller borde jag lägga in någon sorts delay på räknaren just med tanke på att jag kör scripten så frekvent, för att vara på den säkra sidan?

Ska se om jag kan spara ett målantal istället som man kan hålla räkningen mot, själva räkningen har dock funkat fint i test. Mest orolig för om det finns minsta risk att det blir någon delay i portfolio(v) när man kör skarpt då jag absolut vill undvika dubbelköp (kommer handla ganska stora ordrar).

[Henric]

Jag skulle köra en delay. Det kan även bli delorder precis när nästa order skickas. Sedan kolla loggade transaktioner så ser du hur lång tid emellan skickad order och avslut. Minska sedan tiden för delay om det behövs.

[apabarn]

Tack, låter säkrast att köra delay om man vill vara hundra då. Kanske även makulera föregående avslut och ge det lite tid att kontrollräkna igen innan man skickar en ny order, ifall man vill undvika delorder precis när nästa order skickas som du säger.

Jag har fortfarande aldrig kört skarpt så är inte hundra på hur allt fungerar då, men menar du att samma order dyka upp flera gånger i loggade transaktioner då, både som skickad order och avslut, så att man kan jämföra tiden mellan dem? Är det i så fall "skickad" som S:et står för i tredje kolumnen? I test får jag bara en rad per order, inga separerade rader för skickade ordrar och avslut.

[Henric]

M=manuell
S=skickad
T=Transaktion

Normalt 1 sekund mellan s och t. Förutsatt det fanns tillräckligt i orderdjupet för priset. Bra idé med makulera. Skicka order->makulera->läs av och eventuellt skicka ny. Dvs 3 varv. Med eller utan delay. Annars bara en delay.

[apabarn]

Då är jag med, i test får jag bara S på alla ordrar, trots att de räknas in i portfolio(v) direkt som om de vore avslutade. I skarpt läge kommer väl inte portfolio(v) uppdateras förrän man har fått ett riktigt avslut?

Något sånt här då, i tillägg till exemplet ovan.

Global cell 1 = antal
Global cell 3 = pris
Global cell 4 = räknare för delay
cancelprice = pris för att makulera tidigare order utan risk för nytt avslut, t.ex. 0.01 vid köp och 9999.9 vid sälj. Skulle det funka? I test får jag "avslut" på alla ordrar, så det är svårt att testa makulering där.
delaynbr = antal varv man vill vänta för att hinna kontrollräkna innan ev ny order

iscanceled=eqv(GetGVar(3),cancelprice) {kolla om senaste order var makuleringsorder}
SetGVarIf(add(GetGVar(4),1),4,iscanceled) {lägg till 1 till delaycounter om senaste order var makuleringsorder}
SetGVarIf(cancelprice,3,not(iscanceled)) {makulera efter varje order för att ge sig tid för kontrollräkning}
delayfinished=or(eqv(GetGVar(4),delaynbr),eqv(GetGVar(1),0)) {kolla om delay är färdig, eller om man handlat färdigt}
SetGVarIf(-1,add(thisindex,3),delayfinished) {återställ pris}
SetGVarIf(0,add(thisindex,4),delayfinished) {återställ delay}

...

and(GetGVar(1),not(GetGVar(4))) {lös ut trigger om det finns ett antal att handla och delay är nollställd}

[Rikard Autostock]

S är Sent, så på testkonto blir det bara det. Omedelbart efter skickad order får du S även om du skickar till skarpt konto, och då visar även Lasttrade() det som skickats. Så fort skarpt avslut mottages från NN blir det en T-trans och LastTrade() returnerar värdena från den istället. Det kan även bli flera T-transar om det blir delavslut osv. Så för att läsa av sånt du sparat med RetVal() i Loggade lokala ordertransar behöver du använda LastTrade(bs,0-4)

[Henric]

Jag skulle också använda retval/lasttrade. Får du det att fungera helt med celler och är nöjd så varför inte.
Med delay i tidigare inlägg syftade jag på fördröjning i sekunder och inte bara intervall.

ge(mult(sub(date(),lasttrade(b,d)),86400),x)

Edit: I simulering kan du använda delay för en fake makuleringsorder.

[apabarn]

Tack, jag tror jag är med hyfsat på hur det fungerar nu med lasttrade även om man kör skarpt. Såvitt jag har förstått finns inget sätt att läsa av ifall det var en S- eller T-trans från scriptet. Samt att det är bara den senaste transaktionen man kommer åt genom LastTrade, med risk för att någon annan trade kommer emellan, till exempel om man får flera delavslut eller ett annat script råkar köra samtidigt.

Det var anledningarna till att jag föredrog att köra globala celler istället för retval, kändes som man hade mer kontroll och funkar nu bra i test men vet inte om det finns några problem med det som gör att jag behöver tänka om. Har just nu retval fullt med annat data för att lättare kunna följa upp handeln då jag har många script som kör parallellt, men det är inte helt nödvändigt om jag behöver retval för detta.

Sekunder skulle också funka fint att mäta i. Nu är det minst en sekund mellan varje varv utifrån mina inställningar, och i praktiken verkar det vara 1,5 sekunder mellan varje varv, så det borde inte göra någon större skillnad. Vet inte om jag missat något väsentligt som gör att sekunder vore bättre men ska fundera på det.

Det verkade hur som helst fungera ganska bra med hela snurran som jag postat i tråden när jag labbade i test idag.

Tack för all input!

[Henric]

Absolut. Bara du får det att fungera som du vill ha det. Vi vet ju inte hur modellen handlar. Kör man många instrumen slipper man hålla koll på massa celler. Vad gäller delay med sekunder så tänkte jag att det går att justera utan att ändra i ini-filen. Generellt kanske man vill att scripten körs i ett visst intervall och en annan tid för delay. Eller om delay är mindre än intervallet. Good luck.

[Rikard Autostock]

Du kan spara tidstämpeln D i en av cellerna 0-4 när ordern skickas, och jämföra senare med Lasttrade(b,d) tex. Den senare uppdateras vid T-avslut, så får ett högre värde. Då borde man kunna avgöra om det är en T-trans eller S-trans om det inte sker extremt snabbt inpå varandra.

[apabarn]

Nu har jag satt igång triggern inklusive koden ovan och den verkar i allmänhet bete sig som förväntat. Efter varje order ska den alltså makulera, kontrollräkna och skicka ny order om den inte fått fullt avslut, för att säkerställa att man förr eller senare når fullt avslut. De följande försöken ifall första ordern misslyckas ska alltid buda på bästa pris i orderboken för tillfället genom att returnera odepth(b,p,0) från prisscriptet. Sedan iterera tills den fått fullt avslut i max 1 minut.

Detta har hittills fungerat, fram tills idag då den vid ett tillfälle inte fick avslut alls. Detta var för mig märkligt, eftersom modellen hade 12 skickade ordrar till bästa pris i orderboken innan den gav upp efter en minut. Se bifogat "ordertransaktioner".

Eftersom autotradern inte kom till avslut trots upprepade försök, så kollade jag samtidigt på orderdjupet på samma värdepapper hos Nordnet. Där låg mycket riktigt en köporder på samma pris som ordermodellen försökte sälja till, och som till synes borde ha gett avslut. Se bifogat "orderdjup".

Trots att jag inte lyckades, så verkar någon annan däremot strax efteråt ha fått avslut till samma pris, enligt avslutshistoriken på Nordnet, se bifogat "avslut". Det verkar då som att marknaden fungerade som den skulle vid tillfället.

Medan ordermodellen budade kollade jag även på "order och avslut" på Nordnet, men jag såg inga pågående ordrar dyka upp i listan som jag gjort tidigare då det fungerat.

Allt detta får mig att undra ifall ordrarna verkligen gick igenom från autotradern till Nordnet alls.

Jag ser ingen särskild anledning till att ordrarna borde ha nekats hos Nordnet. Jag hade tillräckligt innehav att sälja av värdepappret för att täcka säljordern. Annan handel från autotradern har fungerat under dagen.

Oavsett hur scriptet ser ut i övrigt så har jag svårt att förstå varför ingen av mina 12 ordrar som syns i orderhistoriken lyckades gå till avslut, trots att det till synes fanns liggande bud i orderboken som borde ha matchat priset. Vad har jag missat?