Allmänt meddelande

Collapse
No announcement yet.

Subtraktion av decimaltal

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

  • Subtraktion av decimaltal

    Hej,

    Åkte på en luring då autotradern inte verkar beräkna subtraktion av decimaltal helt rätt. Se bifogat. 13,59-13,61 borde bli -0,02, men debuggern visar -0,0199999...

    Addition med samma tal verkar dock fungera.

    Obs att detta inte verkar vara endast i debuggern, utan anledningen till att jag testade där var för att mina villkor inte verkade gå igenom i en trigger pga detta.

    Hur kommer sig detta och vad kan man göra åt saken?

    Har tillfälligt gjort en workaround ungefär så här, för att försöka få ut korrekt differens:
    tmp=sub(varde1,varde2)
    differens=div(int(add(mult(tmp,100),if(gt(tmp,0),0.5,if(lt(tmp,0),-0.5,0)))),100)​

    Edit: I min workaround multiplicerar jag med 100, avrundar till närmaste heltal och delar sedan på 100. Detta för att få fram differensen avrundat till närmaste hundradel vilket stämmer bättre med verkligheten än autotraderns beräkning i det här fallet.
    Attached Files
    Last edited by apabarn; 2024-09-17, 12:10.

  • #2
    Hm, hur såg scriptet som räknade fel ut exakt?

    Comment


    • #3
      Jag bifogade ett enkelt test i bilden ovan där samma fel uppstår. sub(13.59,13.61) blir inte ekvivalent med -0.02 (som det borde bli). Detta skapade problem i min trigger men samma fel verkar uppstå även i isolerad miljö, åtminstone enligt debuggern.

      Comment


      • #4
        Det är definitvt någon vajsing med räkningen ibland i autotradern. Jag demonstrerade ovan att den räknade lite fel på 13,61-13,59.

        Här är ett annat exempel bifogat. Det är exakt samma kod som körs i båda fallen. Ena gången blir 15.28=15.28 sant, och andra gången blir det falskt. Se variabeln "testeqv" i debuggern. Input till variabeln är enl debuggern samma i båda fallen, men det stämmer uppenbarligen inte riktigt.

        Det som har hänt i bakgrunden är att orderboken har ändrats. 15.28 ska dock fortfarande vara ekvivalent med 15.28 oavsett detta. Jag har ibland haft problem med att värden inte blir ekvivalenta trots att de borde, vilket då fått oönskade konsekvenser, medan det fungerar andra gånger.

        RoundPrice verkar inte hjälpa mot detta, medan manuell avrundning verkar hjälpa. Men det blir många ställen man behöver göra "onödigt "jobb på om man alltid ska avrunda alla värden manuellt till närmsta hundradel. Går det att göra någonting åt detta i allmänhet?
        Attached Files

        Comment


        • #5
          Vi har möjligen en teori som vi undersöker. Stby

          Comment


          • #6
            Jag testar en modell med allokering mellan 0-1 i steg om 0.1
            Försökte debugga, men hittade aldrig varför den överköpte.
            Om jag använder lt(villkor,1) handlar den till 1.1
            Om jag använder lt(villkor,0.99) handla den till 1.0 (om jag lägger till fler 9 fungerar tills nått x-antal och då handlar den till 1.1 igen)

            Comment


            • #7
              Hm, hur ser scriptet ut?

              Comment


              • #8

                Här är en förkortad version. Säljscriptet alltid falskt. Det blir 11 köp. Sätter jag 0.99 blir det 10 köp. Vid tillräcklig många 9or i decimalen blir det 11.

                tid=ge(xtime(date(),h),10)
                delay=gt(int(d),int(lasttrade(b,d)))
                stegOK=lt(lasttrade(b,1),1)
                exe=and(and(tid,delay),stegOK)
                retval(add(lasttrade(b,1),0.1),1)
                and(exe,1)​

                Comment

                Working...
                X