Räkning av antal poster som fått avslut

[Rikard Autostock]

Kolla i Tradelog.txt om det loggats några felkoder etc. Där syns även om den hamnade i marknaden som "On market".

[apabarn]

Det står ORDER_TICKSIZE_ERROR på alla dessa ordrar som inte fick avslut.

Edit: ser nu att det verkar vara priset det är fel på, då den enligt loggen budat 2995.4099 istället för 2995.41. Men jag har ju i prisscriptet returnerat priset med odepth(b,p,0) i det här fallet. Hur kan det bli fel när scriptet hämtar priset direkt från orderboken?

Även "makuleringsordrar" får fel pris i loggen och ticksize_error, då jag satt 9999.99 som pris men den skickar order med 9999.9902 istället. Det spelar mindre roll om de inte går igenom då makulering verkar fungera ändå, men felet kanske är gemensamt med ovan nämnda.

Och en sak till, nu när jag letade upp loggen så fanns den uppdaterade versionen inte där den skulle, utan i C:\Sandbox\Administrator\Autotrader_1\user\all\AutoTraderBasOld. Antar att det beror på att vi varit inne och ändrat då det varit problem tidigare. Innebär det att även ini-filer och annat ligger i "fel" mapp? Jag har nämligen varit inne och ändrat i ini-filen i C:\Sandbox\Administrator\Autotrader_1\user\all\AutoTraderBas och antagit att det fungerade. Nu även ändrat i ini-filen AutoTraderBasOld, efter att jag upptäckte detta, men det vore bra att veta vad som gäller och ha samma ordning på filerna på alla instanser.

[apabarn]

Jag har nu kollat igenom alla loggar, och hittat fler ticksize_error. Det finns två fall där det återkommer:

1) Då jag gör "makuleringsorder" på säljsidan och skickar en säljorder till priset 9999.99. Det verkar då alltid istället bli 9999.9902 enligt loggen vilket ger ticksize_error.

2) Alla övriga förekomster är på ett och samma instrument, där priset är betydligt högre än det är på övriga instrument som har fungerat utan samma problem. Den tenderar på detta instrument att ibland slå på eller ta bort en tusendel på priset, så att det blir fel. Detta trots att priset ska hämtas direkt från orderboken med odepth(b,p,0). Exempel på priser som autotradern har försökt handla till enligt loggen, och som gett ticksize_error:
2972.1699
2972.1101
2977.5701
3013.9399
osv...

På övriga instrument, där priset är lägre, har jag inte en enda liknande förekomst av detta fel, trots att de har handlats betydligt mer frekvent.

Sammanfattningsvis.
När priset är högre än det annars brukar vara (runt 3000) så förvanskar autotradern på något sätt ibland priset genom att antingen lägga till eller ta bort en tusendel, så att det blir fel.
När priset är ännu högre (9999.99) så lägger den alltid till två tusendelar på priset, så att det blir fel.

Vad kan detta bero på, och hur löser man det?

[Rikard Autostock]

Hm, kanske är bra att använda RoundPrice() i prisscripten, så bör det inte kunna bli några ticksize-problem. Ibland händer det att aktier får nya ticksizes, så det kan vara bra att skanna listan manuellt då och då via Starta > Sök nya instrument.

[apabarn]

Okej! Ska testa med RoundPrice i prisscripten men det känns lite vanskligt att det kan bli så, finns det någon grundläggande orsak som man kan förhindra? Nu gick jag på en nit med denna trade, men jag hade ju dessutom ett liknande problem nyligen med andra värden som inte blev ekvivalenta pga att autotradern förvanskade värdet med någon miljontedel eller så, se bifogat. Startade en tråd om detta men fick inget riktigt svar på vad det kan bero på.

Jag undrade även vad som hänt med ini-filerna och annat då jag hittade loggen på "fel" plats i filsystemet som jag beskrev ovan, går det att åtgärda så att allt ligger där det ska? Vågar nog inte pilla själv där för mycket.

[Rikard Autostock]

Hur ser prisscriptet ut? Brukar aldrig vara några problem med dessa. Körs Windows i svenskt format? Om inte är det något vi vet kan ställa till olika problem.

[apabarn]

Prisscriptet returnerade bara bästa pris från orderboken.

price=GetGVar(add(thisindex,40))

add(0,if(gt(price,0),price,odepth(b,p,0)))

Oavsett om if-satsen gick igenom eller inte ska priset komma från odepth i grunden så det borde inte vara några konstigheter.

Windows verkar använda engelska som systemspråk. Det är på servern som ni hjälpt mig hyra och sätta upp och jag har inte ändrat något sådant själv.

[Rikard Autostock]

Ok, fint. Det är engelska som systemspråk men svenskt format så inga problem i så fall. Det jag tror kan vara problemet är värden som skickas via globala celler. Kan vara så att de behöver avrundas och jämnas till lite. Odepth() returnerar bara momentana värden direkt från marknaden så det ska inte vara något problem. Gissningsvis räcker följande:

price=div(int(mult(100,GetGVar(add(thisindex,40)))),100)

eller kanske:

roundprice(if(gt(price,0),price,odepth(b,p,0)))

[apabarn]

Tack för förslagen! Jag har lagt in alla returvärden från prisscript i roundprice på en av instanserna till att börja med, för att se hur det går. Men det är lite svårtestat eftersom det annars inte är ofta jag handlar just detta instrument som har felat flera gånger enligt loggen. Felet verkar som sagt endast ha uppstått på det instrument där priset varit betydligt högre, och aldrig annars.

Jag tror inte att värdet från den globala cellen användes alls i det här fallet. Enligt all logik så bör värdet i den globala cellen ha varit -1, och därför ska prisscriptet istället ha returnerat odepth(b,p,0). Det har även varit tydligt i andra motsvarande fall att den använt odepth(b,p,0) direkt i prisscriptet som tänkt, eftersom värdet i den globala cellen varit -1. Så jag ser det som osannolikt att problemet i det här fallet beror på att värdet gått genom den globala cellen.

Kan vi lösa detta med filsystemet vid passande tillfälle tro?

[Rikard Autostock]

Ok, ja då borde värdet från Odepth() vara det enda som spelar någon roll. Det är inte helt omöjligt att det kommer något konstigt med decimalerna där. Värdet plockas direkt från APIet hos Nordnet.

[apabarn]

Jag har nu testat att köra RoundPrice på returvärdet i alla prisscript, och det blir ändå samma fel. När jag lägger "makuleringsorder" på säljsidan med ett högre pris än vanligt, 9999.99, så förvanskas det så att priset enligt loggen är 9999.9902 och loggen visar ticksize_error. På makuleringsorder spelar det mindre roll då det blir makulerat ändå, men detta indikerar att RoundPrice inte löste problemet. Se bifogade bilder.

Returvärdet från prisscriptet i det här fallet är följande:
add(0,RoundPrice(GetGVar(add(thisindex,80))))

Det ska alltså alltid bli RoundPrice, oavsett vad man har för värde i den globala cellen som priset hämtas från i prisscriptet.

Fortfarande fungerar alla ordrar med lägre pris utan problem. Det är uppenbarligen någon vajsing när priset är för högt just.

Edit: Felet beror uppenbarligen inte heller (bara) på att det kommer något konstigt med decimalerna från API:et hos Nordnet när man kör Odepth(), eftersom samma fel även uppstår när jag sätter priset till 9999.99 (för att makulera) utan att använda Odepth().

[Rikard Autostock]

Men då är 9999.99 inte ett tillåtet pris enligt ticksize-tabellerna? Testa ett annat "omöjligt" pris, tex 1 eller likn. Det viktiga är att det inte kan gå till avslut. Dvs, ok om det hamnar i marknden. Det är inte helt optimalt om du postar ett pris som resulterar i felkoder hos Nordnet.

[apabarn]

Poängen är att den inte skickar 9999.99, utan 9999.9902 i ordern till Nordnet enligt loggen, och att priset därmed inte längre är avrundat till närmaste hundradel. Om sedan priset är inom det tillåtna intervallet är en annan sak. Se bifogat "tradelog.png" ovan.

Precis samma fel uppträdde ju även på priser inom det tillåtna intervallet tidigare. Det är dock inget som jag vill prova igen skarpt bara för sakens skull, när jag redan kan se i loggen på makuleringsorder att den fortfarande skickar fel pris, trots RoundPrice. Om den fortfarande lägger på två tiotusendelar på makuleringsorder, trots att man använder RoundPrice, så kan man anta att RoundPrice inte löste problemet med att avrunda priset till närmaste hundradel.

Edit: Det gör inget att makuleringsorder inte kan gå till avslut, men det är värre när samma fel orsakar att riktiga ordrar inte går till avslut, som jag beskrev hade hänt igår. Det har redan kostat. Risken att felet uppstår verkar vara högre när priset är högre. Därav händer det alltid när man skickar 9999.99. Makuleringsordern är ett exempel där felet alltid uppstår, men felet är inte unikt för makuleringsorder.

[Rikard Autostock]

Jo, men det kanske inte finns någon ticksize-tabell som täcker det priset, därav fungerar inte RoundPrice(). Det är bara en teori, men fullt möjligt. RoundPrice använder tabellerna, det avrundas inte rent "matematiskt" baserat på något annat. Man kan såklart använda INT() istället och multiplicera/dividera för att få bort decimalerna.

[apabarn]

Okej, jag förstår. Jag kan prova att avrunda själv. Men det är då även uppenbart att felet inte beror på att det kommer skräp med från Nordnet när man kör Odepth(), eftersom samma fel uppstår när man inte använder Odepth(), t.ex. vid makulering. Antingen är det någonting lokalt i Autotradern som är fel, eller så sker förvrängningen av priset på något sätt i samband med interaktionen när ordern skickas till Nordnet.

En intressant sak i sammanhanget som jag nämnde ovan, var ju att autotradern även själv räknade fel på marginalen i andra fall vilket ledde till andra problem för mig tidigare. Ett enkelt script som bara skulle göra en subtraktion visade fel värde (på marginalen) i debuggern, se bifogat. Samma fel uppträdde inte bara i debug, utan ledde även till problem när jag körde script, vilket var anledningen till att jag debuggade. Kan det vara någon liknande felberäkning av autotradern som sker i det här fallet?