Globala celler/variabler strular

[LillWicke]

Jag skulle vilja utfärda en varning för att använda de globala cellerna så som de är beskrivna i script-manualen idag. Det kan kosta stora pengar om en ordermodell löper amok.

Anledningen till varningen är att det finns en bugg i SetGvarIf()-funktionens villkorsdel, som under vissa förutsättningar, medför att falska villkor blir sanna. Parametern L som föreslås ovan har ingen inverkan på detta.

Till dess att buggen är fixad, får vi använda oss av vissa begränsningar för att kringgå den och om man beaktar nedanstående kriterier/begränsningar vid scriptskrivningen, kan buggen idag kringgås på ett säkert sätt.

Kriterier:
1) De enda villkor som man idag kan vara helt säker på fungerar i SetGvarIf() är fast inskrivna värden 1 eller 0, eller namngivent: etta:=1, nolla:=0
Ex: SetGvarIf(värde,500,1,T), SetGvarIf(värde,500,nolla,T)

2) Skriv alltid in den fjärde parametern i funktionerna. Ex: GetGvar(500,N) om man skall hämta normal-värdet, och SetGvarIf(värde, 500,1,T) om det är ett villkor som avses. Om inte parametrarna skrivs in kan man ibland råka ut för att de hämtade cellvärdena börja rulla. Det som jag själv fick uppleva vid starten av denna tråd.

3) Tänk på att det är i villkorsdelen av SetGvarIf() som felet ligger, inte i värdedelen. Detta medför att man kan skriva in funktioner, minnesreferenser och namngivna uttryck helt obegränsat till värdedelen, men inte till villkorsdelen. Ex:

värde=”lång beräkningsfunktion” ”minnesreferens” eller ”namngivet uttryck”
SetGvarIf(värde,155,1,T)
Fungerar.

Men
villkor=”lång beräkningsfunktion” ”minnesreferens” eller ”namngivet uttryck”
SetGvarIf(1,155,villkor,T)
Fungerar inte.

4) Ta för vana att alltid skriva ”nul” framför ensamstående funktioner. Ex:
nul=SetGvarIf(värde,500,1,T). På det sättet blir scriptet stabilare och råkar inte ut för nycker.

Använder man sig av ovanstående kriterier och därmed också begränsningar, kan man idag använda sig av de ”globala cellerna” på ett säkert sätt.

[Rikard Nilsson]

Stopp och belägg! Jag tycker vi ska vara försiktiga med varningar innan vi verkligen konstaterat någon bugg. Vi undersöker detta och uppdaterar om något skulle visa sig vara fel.

[LillWicke]

Rikard, om det här inte är en bugg, lovar jag att köra Vätternrundan nästa år.

[Henric]

"Om det finns en bug"
LillWicke, får du alltid problem eller endast vid diagramritning.

[LillWicke]

LillWicke, får du alltid problem eller endast vid diagramritning.

Det jag skrev om ovan, angående fel i villkorsdelen, tycks alltid inträffa.
Problemet jag startade tråden om däremot, "värderullning", försvinner om man skriver in den 4:e parametern.

För den som önskar, är det annars väldigt enkelt, att själv rigga upp ett testscript och utvärdera hur villkorsdelen uppför sig.

[Rikard Nilsson]

Här är ett testscript där man kan labba lite med olika villkor:

larm10:=and(gt(frac(d),0.416),lt(frac(d),0.427))
larm11:=and(gt(frac(d),0.458),lt(frac(d),0.468))
larm12:=and(gt(frac(d),0.5),lt(frac(d),0.512))
larm13:=and(gt(frac(d),0.541),lt(frac(d),0.552))
larm14:=and(gt(frac(d),0.583),lt(frac(d),0.593))
larm15:=and(gt(frac(d),0.625),lt(frac(d),0.637))
larm16:=and(gt(frac(d),0.666),lt(frac(d),0.677))
larm17:=and(gt(frac(d),0.708),lt(frac(d),0.718))
måndag:=eqv(dayofweek(),1)
fredag:=eqv(dayofweek(),5)
i5(
setgvarif(10,80,and(fredag,larm10),L)
{setgvarif(11,80,larm11,L)}
{setgvarif(12,80,larm12)}
{setgvarif(13,80,larm13)}
setgvarif(14,80,and(larm14,måndag))
{setgvarif(15,80,larm15)}
{setgvarif(16,80,larm16,L)}
mult(larm17,10)
)



För att testa värdet i cell 80 kan man bygga följande enkla kalkyl:

getgvar(80)

vilket skyltar ut värdet i kolumnen.

Enkelt test:


1. Kör scriptet som det är. Nu sätts värdet 14 i cell 80 eftersom villkoret larm14 är det senaste som blir sant.
2. Kommentarmarkera raden

{setgvarif(14,80,and(larm14,måndag))}

3. Vänta några sekunder och kör kalkylen igen, värdet 14 ligger kvar trots att raden

setgvarif(10,80,and(fredag,larm10),L)

är den senaste som är sann, detta eftersom L-parametern förhindrar skrivning eftersom tidpunkten då larmet var sant i fredags är tidigare än den tidstämpel som skrevs nyss.

4. Ta bort parametern L i raden

setgvarif(10,80,and(fredag,larm10),L) så att det blir
setgvarif(10,80,and(fredag,larm10))

5. Vänta några sekunder, kör kalkylen. Nu finns värdet 10 i cellen eftersom skrivning tillåtits. Slutsats, L-parametern fungerar.



Ytterligare test:

6. Ta bort kommentarmarkering på raden:

{setgvarif(16,80,larm16,L)}


7. Vänta till efter kl 17 så ska värdet 16 skrivas in i cellen eftersom villkoret blir sant först då, och L-parametern ska tillåta skrivning eftersom tidstämpeln då är senare än "nu" och inget annat villkor är sant.

[LillWicke]

Ok, Rikard du pratar om ett värde som ligger kvar från föregående dag till nästkommande. Jag pratar om värden som skall skrivas in kontinuerligt under dagen. Vad händer om du ersätter L-parametern med ett T, och lägger in ett villkor som växlar många gånger under dagen? Prova det och återkom. Har du testat scriptet jag skickade till dig?

[Henric]

Kan du ge ett script som jag kan testa. Jag Kör ett script med global celler och verkar inte få några problem.

[LillWicke]

Ok, Här kommer mitt allra enklaste scriptexempel, som alla med lite scripterfarenhet alla kan köra.

Scriptet skriver kontinuerligt 5 i cellerna 80 och 90. Med hjälp av kalkylmodellen ”Hämta cell 80 90” kan man sedan se vilken tid som förflutit från senaste skrivningen. Ett av villkoren är alltid falskt och i den cellen skall det följaktligen inte skrivas något. Genom att köra kalkylmodellen några gånger efter varandra kan man se hur det förhåller sig med den saken.

Med hjälp av kalkylmodellen ”Nolla cell 80 90” kan man då och då under körning nolla cellerna för att se vad som händer. Ett av villkoren är som sagt alltid falskt och följaktligen skall det inte skrivas 5 i båda cellerna samtidigt.

Om allt fungerar som det ska och medelvärdet pekar uppåt skall det alltså skrivas i cell 80 men ingenting i cell 90. Tvärtom om medelvärdet pekar nedåt. Detta kan man allså med hjälp av kalkylmodellerna se om det stämmer.

Anvisning:

1) Skapa kalkylmodellerna:

”Hämta cell 80 90”
Minut 80: mult(1440,sub(date(),GetGvar(80,D)))
Get 80: GetGvar(80,N)
Minut 90: mult(1440,sub(date(),GetGvar(90,D)))
Get 90: GetGvar(90,N)

”Nolla cell 80 90”
Set 80: SetGvarIf(0,80,1,T)
Set 90: SetGvarIf(0,90,1,T)

2) Skapa ett nytt script i scripteditorn och döp det till exempelvis ”Celltest 80 90”

3) Kopiera in scriptet nedan och spara.

4) Bocka rutorna ”Script anslutet” och ”Visa i diagram Intraday”

5) Se till att diagrammet som scriptet kopplas till körs, exempelvis OMXS30 under dagen och Nasdaq 100 på kvällen.


{ Test av villkorsdelen av SetGvarIf(), allra enklaste varianten}

i5(
med2=mov(c,5,s)

{ Villkor }
buy2=gt(med2,aref(med2,1))
short2=lt(med2,aref(med2,1))

{ Skrivning }
SetGvarIf(5,80,buy2,T)
SetGvarIf(5,90,short2,T)

draw(med2,2,bab)
)

[Henric]

Jag körde 4 snabba tester. Med och utan rita i diagram och med 3 respektive 4 parameterar. Vid diagram ritning kan båda cellerna bli 5 samtidigt. Spelar ingen roll om det är 3 eller 4 parametrar. Utan diagramritning har cellerna aldrig blivit 5 samtidigt.

Jag kör alltid utan diagramritning med globala celler och förhoppningsvis uppstår då inga problem.

[LillWicke]

Jag körde 4 snabba tester. Med och utan rita i diagram och med 3 respektive 4 parameterar. Vid diagram ritning kan båda cellerna bli 5 samtidigt. Spelar ingen roll om det är 3 eller 4 parametrar.

De inte bara kan bli 5 samtidigt, de blir alltid 5 samtidigt.

Utan diagramritning har cellerna aldrig blivit 5 samtidigt.

Bra Henric, då har vi snävat in "Faskt blir sant-buggen" till diagramritning. Frågan är: Hur blir det vid körning i ordermodeller?

Till er andra som kanske provar detta, scriptet slutar att uppdateras om man bara klickar bort ritning i diagram, man måste då också samtidigt klicka i att scriptet är larmbevakat för att det ska köras det vidare.

Jag kör alltid utan diagramritning med globala celler och förhoppningsvis uppstår då inga problem.

Förhoppningsvis, men det är ingen garanti. Vad är det som gör att buggen uppträder just vid diagramritning påslaget, undrar man? Det är samtidigt lite farligt att ha det på det här viset, eftersom många kör sina script med "Visa i diagram" påslaget.

[i00006]

Hej,
Fråga räcker det med att STÄNGA alla fönster för att minska problemet eller måste man ta bort VISA i DIAGRAM för att unvika problem?

Mvh
Ingemar

[Rikard Nilsson]

De inte bara kan bli 5 samtidigt, de blir alltid 5 samtidigt.


Bra Henric, då har vi snävat in "Faskt blir sant-buggen" till diagramritning. Frågan är: Hur blir det vid körning i ordermodeller?

Scripten körs i samband med att diagram ritas upp av den enkla anledningen att kurvor och flaggor ska synas i diagrammet. Då sätts även globala celler om man inte spärrar bort skrivningen med hjälp av tidsstämpeln. Dvs, tidpunkten i ett diagram som ritas är alltid tidigare än "nu". Det gör att vi kan blockera skrivningen. Vid vanlig "live"-körning av script i ordermodeller etc blir tidstämpeln alltid "nu" vilket är senare än tidigare skrivningar, och då är det fritt fram att skriva. Se scriptet längst ner.

Till er andra som kanske provar detta, scriptet slutar att uppdateras om man bara klickar bort ritning i diagram, man måste då också samtidigt klicka i att scriptet är larmbevakat för att det ska köras det vidare.

Script körs vid följande tillfällen:

1. Om det är anslutet via en ordermodell.
2. Om det är förkryssat att rita något i ett diagram.
3. Om "Larmbevakat" är kryssat.

Om inget av ovanstående är förkryssat exekveras scriptet överhuvudtaget inte. Därför är det nödvändigt att tex kryssa i Larmbevakat (och eventuellt Lokalt bara) om man vill att scriptet ska köras utan diagramritning.

Förhoppningsvis, men det är ingen garanti. Vad är det som gör att buggen uppträder just vid diagramritning påslaget, undrar man? Det är samtidigt lite farligt att ha det på det här viset, eftersom många kör sina script med "Visa i diagram" påslaget.

Det räcker att ett villkor blev sant vid ett enda tillfälle genom diagramritningen för att en cellskrivning ska ske. Det kan lätt förväxlas med en "bugg" eftersom man kanske inte ens ser signalen i diagrammet i efterhand.

Men har man det i åtanke och använder antingen L-parametern så behöver man inte råka ut för konstigheter.


stigH:=gt(c,aref(h,1))
fallL:=lt(c,aref(l,1))
inget:=and(not(stigH),not(fallL))
i1(
setgvarif(if(stigH,10,getgvar(80)),80,L)
setgvarif(if(fallL,5,getgvar(80)),80,L)
setgvarif(if(inget,0,getgvar(80)),80,L)
mult(stigH,10)
)

Scriptet ovan testar om Close är över föregående 1-minutsstapel. I så fall skrivs värdet 10 till cell 80, men bara om tidstämpeln är senare än förra skrivningen. Dvs, diagramritning sker ju i "dåtid" och får ingen effekt.

Är Close under föregående 1-minutsstapel skrivs värdet 5 till cell 80.
Är Close "innanför" föregående 1-minutsstapel skrivs värdet 0 till cell 80.

Det kan enkelt testas med Kalkylforskaren.

[LillWicke]

Rikard du vet att jag hyser mycket stor respekt för dig, ditt arbete, och dina kunskaper. Du hjälper mig, och samtliga andra här på forumet, med många trixiga problem, dag som kväll. Du håller en otrolig servicenivå, som för dig leder till arbetsvillkor, som många andra inte ens skulle drömma om att ställa upp på. Utan dig skulle Autostock inte finnas, det är simpel hårdfakta. En stor eloge till dig med andra ord ,och jag hoppas verkligen för min, och alla andra NAT-ägares skull, att du aldrig kommer att tröttna. Det jag skriver nu är inget skämt, utan något som jag verkligen menar, och jag har också låtit dig förstå detta personligen ett par gånger vid telefonkontakt, hoppas du inte har glömt det.



I det här fallet dock, börjar jag känna mig en aning sorgsen, för hur ska man kunna ta itu med ett problem om man inte ens ser det?

Rikard skrev: ”Det räcker att ett villkor blev sant vid ett enda tillfälle genom diagramritningen för att en cellskrivning ska ske. Det kan lätt förväxlas med en "bugg" eftersom man kanske inte ens ser signalen i diagrammet i efterhand.”

Ovanstående uttalande visar att du inte tar problemet på riktigt allvar. Vad villkoren stod i exakt vid cellskrivningen är enkelt att kolla genom att lägga till två rader i scriptet ovan och samtidigt komplettera med visning av cellerna 81 och 91 i kalkylforskaren. För att få en lite skojigare skrivning har jag lagt till ”minut_nu”, så att man får en variabel skrivning i cellerna.
Man kan med all önskvärd tydlighet se, att det kontinuerligt skrivs i båda cellerna, trots att ett av villkoren alltid är falskt.

{ Test av villkorsdelen av SetGvarIf() allra enklaste varianten}

minut_nu:=mult(frac(date()),1440)

i5(
med2=mov(c,5,s)

{ Villkor }
buy2=gt(med2,aref(med2,1))
short2=lt(med2,aref(med2,1))

{ Skrivning }
SetGvarIf(minut_nu,80,buy2,T)
SetGvarIf(minut_nu,90,short2,T)

SetGvarIf(buy2,81,1,T) { Mellanlagring av buy-villkoret }
SetGvarIf(short2,91,1,T) { Mellanlagring av short-villkoret }

draw(med2,2,bab)
)

När det gäller din L-parameter försöker du skriva runt villkorsproblemet och placera villkoret i värdedelen istället.

Två problem uppstår med en sådan lösning.
1) Värden skrivs kontinuerligt i cellerna, vilket inte är syftet med villkorsdelen i SetGvarIf().
2) Falskt blir fortfarande sant med din lösning.
Kör nu mina script för en gångs skull och svara inte genom att hitta på egna.

Vi sätter in din lösning i mitt script ovan.
Resultatet blir att trots att ett villkor alltid är falskt, tolkas det ändå som sant. Vad skrivvillkoret stod i vid skrivningen kan man se i cell 81 och 91.

{ Test av villkorsdelen av SetGvarIf() allra enklaste varianten}

minut_nu:=mult(frac(date()),1440)

i5(
med2=mov(c,5,s)

{ Villkor }
buy2=gt(med2,aref(med2,1))
short2=lt(med2,aref(med2,1))

{ Skrivning }
SetGvarIf(if(buy2,minut_nu,GetGvar(80)),80,L)
SetGvarIf(if(short2,minut_nu,GetGvar(90)),90,L)

SetGvarIf(buy2,81,1,T) { Mellanlagring av buy-villkoret }
SetGvarIf(short2,91,1,T) { Mellanlagring av short-villkoret }

draw(med2,2,bab)
)

Hur man än vänder sig, har man alltid ändan bak.

[Rikard Nilsson]

Du kör med frac(date()) som tidstämpel vilket alltid returnerar datorklockans tid. Då blir det ju fel i scriptet eftersom det blir samma tid skriven oavsett när villkoret blev sant enligt "databastid". Prova det här istället:

{ Test av villkorsdelen av SetGvarIf() allra enklaste varianten}

minut_nu:=mult(frac(d),1440)

i1(
med2=mov(c,5,s)

{ Villkor }
buy2=gt(med2,aref(med2,1))
short2=lt(med2,aref(med2,1))

{ Skrivning }
SetGvarIf(if(buy2,minut_nu,GetGvar(80)),80,L)
SetGvarIf(if(short2,minut_nu,GetGvar(90)),90,L)

draw(med2,2,bqb)
)


Jag har provkört det en stund på AAPL och får olika minuter i cell 80 och 90 beroende på när medelvärdet vände senast. I mina ögon fungerar det.