Allmänt meddelande

Collapse
No announcement yet.

Ordrar som inte går igenom

Collapse
X
 
  • Filter
  • Klockan
  • Show
Clear All
new posts

  • Ordrar som inte går igenom

    Jag har en fundering på hur man bär sig åt för att kunna styra orderläggningen på ett lite mer intelligent inifrån NAT.

    Ett exempel:
    Låt oss säga att vi har en snabb kursrörelse åt något håll och en köp eller säljsignal slår till. Orden går iväg och trots att prisscriptet plussat på en del extra på köp/sälj-kursen så blir det inget avslut.

    En order ligger nu alltså aktiv i marknaden. Kursen går vidare åt samma håll och NAT signalerar (efter att order_delay tiden passerats) en gång till. Ny order men inget avslut. Resultat: nu ligger det två ordrar i marknaden åt samma håll.

    Detta förlopp kan naturligtvis teoretiskt fortgå så att det i slutändan kanske ligger 10? öppna ordrar i marknaden åt samma håll, och ingen sitter naturligtvis vid datorn hemma och kan kolla läget.

    Som på en given signal slår sedan naturligtvis kursen om och drar med hög hastighet åt motsatta hållet. En efter en plockas de öppna ordrarna och helt plötsligt sitter man med 10-dubbla antalet kontrakt mot vad man tänkt, åt fel håll.

    Min fråga blir alltså vad kan man göra för att ovanstående situation inte ska kunna inträffa? Någon funktion för ordermakulering kan i alla fall inte jag hitta i NAT-språket.

    Last edited by LillWicke; 2012-09-07, 17:03.

  • #2
    Använder makulera befintlig order. Tar bort alla ordrar som ligger åt samma håll som ordern. Den sist kan dock ligga kvar om ingen noll order läggs som rensar alla utestående ordrar.

    Comment


    • #3
      Ursprungligen postat av Henric Visa inlägg
      Använder makulera befintlig order. Tar bort alla ordrar som ligger åt samma håll som ordern. Den sist kan dock ligga kvar om ingen noll order läggs som rensar alla utestående ordrar.
      Utveckla gärna lite. "Makulera befintlig order" vad är det för NAT-scriptsfunktion??

      Comment


      • #4
        nej, det är en egenskap som väljs när du bygger ordermodellen. Efter det att du har skapat en sekvens kan du högerklicka på den och välja olika egenskaper för order, tex simulera eller auto, makulera befintlig eller ej, osv.

        Comment


        • #5
          Nu förstår jag vad du menar.
          Ja, där kan man ju välja "makulera befintlig order" och då är ju problemet med en hel sekvens ordrar åt samma håll löst på ett smidigt sätt.

          Men som du skriver så har vi fortfarande ett problem med den sista ordern. Den kommer att ligga kvar och lösa ut när kursen går åt fel håll. Vad gör man med den?

          Idealiskt vore om man kunde makulera befintlig order om ingen orderbekräftelse kommit från Nordnet efter ett visst antal minuter.
          Hur löser man det i NAT?

          Comment


          • #6
            Du kollar tiden för lasttrade och efter tex 5 minuter läggs en order med pris 0. Läggs en order med pris 0 makuleras alla ordrar. Har inte testat detta på länge. Gjorde så tidigare då jag hade fiskeorder ute.

            Comment


            • #7
              Hmm, lasttrade loggar ju lokalt? (har jag för mig).

              Finns det inget sätt att kolla att ordern verkligen har gått igenom? Jag tänker här närmast på "Starta>Loggade ordertransaktioner" Där separeras ju ordern från själva transaktionen.
              .

              Comment


              • #8
                Vet ej bästa sätt att kolla om ordern gått igenom? Menar du T kolumnen. Om jag har förstått det rätt lagras tiden i lasttrade när ordern skickades och har det blivit avslut så lagras tiden vid avslut(då ändras koden). Egentligen borde det inte ha någon betydelse om du ändå vill ta bort en order om ej avslut inom viss tid. Skickar du nollorder och redan avslut händer inget, annars makuleras alla ordrar.
                Last edited by Henric; 2012-09-07, 18:56.

                Comment


                • #9
                  Man kan lagra tidstämpeln när ordern skickas med retval(), och därefter mäta den verkliga avslutstiden med lasttrade(b,d) som alltid ska vara senare om orden gått igenom.

                  Comment


                  • #10
                    Nu känns det som att man måste hålla tungan rätt i mun om radordningen skall bli rätt

                    Koden behöver väl bara ligga i ett av triggerscripten om man har 4 parallella modeller för enter-exit? (Retval() däremot måste ju förstås ligga i alla fyra scripten.) En motsvarande kod måste ju sedan också ligga i antalsscriptet.

                    Skulle nedanstående kod kunna fungera, har jag missat något eller finns det bättre sätt?

                    Timelock är där för att vänta på att Nordnet svarat.

                    { triggerscript }

                    timelock:=1
                    innehav_ok:=eqv(portfolio(v),0)

                    lt1:=LastTrade(B,D)
                    lt2:=LastTrade(S,D)
                    minSedanKöp1:=mult(sub(date(),lt1),1440)
                    minSedanSälj1:=mult(sub(date(),lt2),1440)
                    min_sedan_trans:=mn(minSedanKöp1,minSedanSälj1)

                    lt3:=LastTrade(B,0)
                    lt4:=LastTrade(S,0)
                    minSedanKöp2:=mult(sub(date(),lt3),1440)
                    minSedanSälj2:=mult(sub(date(),lt4),1440)
                    min_sedan_order:=mn(minSedanKöp2,minSedanSälj2)

                    i30(
                    orderdelay_ok=gt(min_sedan_order,timelock)
                    nollorder=and(lt(min_sedan_order,min_sedan_trans),gt(min_sedan_order,3)
                    .
                    .
                    .
                    buy5=and(and(.....,orderdelay_ok),innehav_ok)

                    if(buy5,retval(date(),0),1)
                    buy6=or(buy5,nollorder)
                    mult(buy6,10)
                    )



                    EDIT1: minut_nu borttaget och ersatts med date()
                    EDIT2: ändrat i nollorder från gt() till lt()
                    Last edited by LillWicke; 2012-09-08, 18:47.

                    Comment


                    • #11
                      Ett fel som jag ser är att du lagrar vilket minut det är på dagen, men jämför med tidstämpel i sitt kompletta format, dvs enligt julianska kalendern.

                      minut_nu bör nog tas bort och ersättas med Date() rakt av.

                      Annars hittar jag inga fel, bara att provköra!

                      Comment


                      • #12
                        Ursprungligen postat av Rikard Nilsson Visa inlägg
                        minut_nu bör nog tas bort och ersättas med Date() rakt av.

                        Annars hittar jag inga fel, bara att provköra!

                        Finemang, insåg faktiskt själv efter det att datorn stängts av inatt att "minut_nu" i det här fallet nog inte var så smart. Det kan ju faktiskt vara så att det är flera dagar sedan senaste order gjorts.

                        Jag har ändrat scriptet ovan, tagit bort "minut_nu" och ersatt med "date()".
                        Är det något mer man behöver tänka på?

                        Last edited by LillWicke; 2012-09-08, 13:22.

                        Comment


                        • #13
                          Kommer minnesrefen nollorder någonsin att bli sann om det finns en hängande order utan avlust.

                          Comment


                          • #14
                            Ursprungligen postat av Henric Visa inlägg
                            Kommer minnesrefen nollorder någonsin att bli sann om det finns en hängande order utan avlust.
                            Tack för ditt påpekande Henric.

                            Om det finns en hängande order är ju tiden sedan order "min_sedan_order" mindre än vad tiden sedan den bekräftade ordern "min_sedan_trans" är.

                            Jag får naturligtvis ändra gt() till lt()

                            Har du hittat något mer?

                            Comment


                            • #15
                              Jag tror inte om du hade fel i det jag påpekade. I vilket fall som helst borde detta fungera. Vad tror du?

                              Det kanske är enklare att använda något liknande.
                              Det fungerar inte med sekvenser utan måste ligga i en oberoende ordermodell eller som en egen ordermodell.

                              Retval(0) sätts i slutet av varje sl) script som ingår.

                              noll1=eqv(lasttrade(b,d),lasttrade(b,0))
                              noll2=or(eqv(lasttrade(s,d),lasttrade(s,0)),noll1)
                              noll3=and(noll2,gt(mult(sub(date(),mx(lasttrade(b,d),lasttrade(s,d))),1440),3))

                              Sedan skicka en order med pris noll och alla utestående ordrar makuleras. Jag tror att både köp- och säljordrar makuleras?

                              Först är det nog bäst att lägga på lite vid tex andra eller tredje försöket. Då blir det förmodligen avslut och detta är en sista säkerhetsåtgärd.

                              Förmodar att lasttrade(b och s,d) får exakt samma tidsvärde som retval i triggerscripten(när orden skickas vill säga)?

                              Tillägg:
                              Vad händer vid delavslut. Det kanske är bäst att alltid panga i väg en nollorder tex 4 minuter efter senaste icke nollorder eller lägga på så mycket vid flera
                              försök att det med största sannolikhet blir avslut.
                              Last edited by Henric; 2012-09-08, 20:15.

                              Comment

                              Working...
                              X