Räkning av antal poster som fått avslut

[apabarn]

PS

Kom på att det kan bli följdproblem om man följer förslaget att köra t.ex. följande:
price=div(int(mult(100,GetGVar(add(thisindex,40)))),100)

Om någon tiotusendel då hade dragits av från priset, så som har hänt tidigare, så skulle detta förvisso göra att priset blev exakt ned till hundradelen. Men priset skulle i så fall bli en hundradel för lågt, eftersom int() alltid avrundar nedåt. Detta kan t.ex. leda till att man inte får avslut om man går efter orderboken på köpsidan, så det behövs väl även avrundning till närmaste heltal innan man kör int() om jag tänker rätt nu?

[Rikard Autostock]

Man kan addera 0.5 innan avrundning.

[apabarn]

Detta fungerade inte heller.

Jag körde följande retur från prisscript:
div(int(add(mult(100,GetGVar(add(thisindex,80))),0.5)),100)

Det blev fortfarande samma fel med att den slog på två tiotusendelar på priset, så att det blev ticksize error, enligt loggen. Se bifogat.

[Rikard Autostock]

Hm, är det verkligen rätt script du redigerar i? Tänker på om det är det som ligger kopplat i ordermodellen. Eller byter du script i modellen? I så fall måste den anslutas igen.

[apabarn]

Ja, det var rätt. Som jag skrev tidigare så ändrade jag först till RoundPrice i alla mina pris-script. Och nu ändrade jag till denna avrundning i alla pris-script, men fick fortfarande samma fel. Jag kör flera ordermodeller parallellt, och alla verkar lida av samma problem när det gäller detta.

Jag byter inte script i samma modell, utan redigerar alla prisscript på en gång, eftersom samma fel redan har uppstått i flera olika ordermodeller.

Edit:
Om du vill jämföra koden i samma script som jag nämnde tidigare, så såg det nu istället ut så här:

price=GetGVar(add(thisindex,40))

div(int(add(mult(100,if(gt(price,0),price,odepth(b,p,0))),0.5)),100)

Men den ordermodellen är inte lika aktiv och har inte handlat idag, så där har jag inte haft chansen att jämföra utfallet. Men eftersom avrundningen inte hjälpte i det senare fallet, så kan man anta att den inte hjälper där heller. Jag har backat alla dessa försök till ändringar nu, eftersom Autotradern la till tiotusendelar i ordern trots både RoundPrice och avrundning. Skulle behöva en åtgärd som fungerar.

Har som jag skrivit ett par gånger haft problem med felräkningar på marginalen i andra fall. Värden som inte blir ekvivalenta trots att de borde. Jag postade ett enkelt exempel ovan. Kan det vara så att autotradern räknar lite fel på marginalen ibland? Och kan det vara något sådant som händer i detta fall?

[Rikard Autostock]

Hm, bara en ide - prova att lägga intraday-prefix runt scriptet. Vet inte om det påverkar något som körs eftersom Odepth() returnerar momentanvärden.

[apabarn]

Det är redan intraday-prefix runt. Jag inkluderade inte hela scriptet eftersom jag inte tänkte att det var relevant, men här är hela det senast nämnda prisscriptet:

i1(

thisid=crcid()
thisindex=if(eqv(GetGVar(810),thisid),GetGVar(820),if(eqv(GetGVar(811),thisid),GetGVar(821),if(eqv(GetGVar(812),thisid),GetGVar(822),if(eqv(GetGVar(81 3),thisid),GetGVar(823),if(eqv(GetGVar(814),thisid),GetGVar(824),-1)))))

div(int(add(mult(100,GetGVar(add(thisindex,80))),0.5)),100)

)

[apabarn]

Får fortfarande ticksize_error på ordrar där priset (per enhet) är över ett par tusen. Inget av förslagen har fungerat hittills, så jag har fått lägga handeln åt sidan nu på just det instrumentet där priset är så högt. Felet verkar aldrig ha uppstått på andra instrument, där priset är lägre, förutom när man lägger makuleringsordrar och sätter 9999.9 som pris. Då blir det samma fel. Makuleringsordrar på köpsidan däremot där jag sätter pris 0.01 får inte samma fel.

Felet verkar alltså inte vara direkt kopplat till något särskilt instrument, utan det verkar uppstå när priset är högt.

Har svårt att komma vidare då felet verkar ligga utanför själva scriptet. Men det måste väl ändå finnas någon lösning på detta?

[Rikard Autostock]

Vilket instrument är det? Kan kolla om det saknas ticksize-intervall på just det.

[apabarn]

Mailade dig istället nu.

[apabarn]

Den här slingan har räknat ätt 9999 gånger av 10000, men någon enstaka gång har den missat att den redan fått avslut och sedan handlat på nytt. Kan inte förstå vad detta då har berott på. En potentiell orsak om möjligt vore ifall portfolio(v) inte uppdateras tillräckligt snabbt efter handel. Kan det i undantagsfall hända att portfolio(v) dröjer lite extra med att uppdateras efter handel har skett på ett instrument, eller kan man alltid lita på att innehavet är uppdaterat i princip omedelbart efter en transaktion?

[Rikard Autostock]

Det skulle väl vara om det skickas order som hamnar i marknaden några sekunder innan den går till avslut. Då håller LastTrade() det postade värdet under tiden. Men räknaren borde ju räkna vidare i alla fall. Man kanske ska ge det några sekunder innan man tar beslut efter att cellen har uppdaterats.

Du kan läsa av senaste skrivtidpunkt för en global cell med Getgvar(x,d) där x är cellnumret och d tidstämpeln. Om man subtraherar bort den från Date() får du tiden sedan skrivning.

sekunder=mult(86400,sub(date(),lasttrade(x,d)))

Alternativt, blockera ny order x antal sekunder efter senaste skickade order så ger man systemet lite tid att synka allt.

sekunder=mult(86400,sub(date(),lasttrade(b,d))

för köporder tex.

villkor=gt(sekunder,15)

blir sant 15 sekunder efter skickad order.

[apabarn]

Tack för svar! Ja, om ordern blir kvar i marknaden ska inte portfolio(v) uppdateras under tiden. Men i det här enstaka fallet då det blev fel var det tvärtom; jag hade fått avslut direkt, men ändå verkar scriptet inte ha uppfattat detta genom kontrollräkningen med portfolio(v) och därför skickades sedan en ny order.

Ifall portfolio(v) inte uppdateras tillräckligt snabbt så skulle det kunna vara en möjlig orsak. Jag ger scriptet ett par "varv" på sig att makulera och kontrollräkna via portfolio(v), innan ny order skickas i händelse av att man inte fick fullt avslut. Jag skulle kunna skruva upp antalet varv som scriptet väntar innan ny order skickas, alternativt kolla att en viss tid gått sedan lasttrade, men jag vill gärna hålla tiden så kort som möjligt och detta verkar i allmänhet räcka för att portfolio(v) ska hinna uppdateras, åtminstone alla gånger utom just denna.

Kan såklart även bero på något annat, famlar lite i blindo eftersom det bara hänt någon enstaka gång på tusentals transaktioner och jag inte lyckats hitta någon uppenbar orsak.