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.