Globala celler/variabler strular

[Rikard Nilsson]

Såg att det ska vara 4 parametrar när man använder L för skrivning. Det behövs alltså en Date() för att skriva in systemtiden så att L-parametern kan jämföra med databastiden från en diagramritning. Tänk dock på att villkoren lätt kan bli sanna någon gång i samma period beroende på lutningen på medelvärdet. Vill man kringgå det kan man ändra till buy=gt(aref(med2,1),aref(med2,2)) så testas bara slutvärdet från stapeln innan. Det kan inte ändras i efterhand.

{ 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,Date(),L)
SetGvarIf(if(short2,minut_nu,GetGvar(90)),90,Date(),L)

draw(med2,2,bqb)
)

[LillWicke]

Såg att det ska vara 4 parametrar när man använder L för skrivning. Det behövs alltså en Date() för att skriva in systemtiden så att L-parametern kan jämföra med databastiden från en diagramritning.

Now you´re talking.
Jag, och säkert flera andra med mig, har tidigare inte fattat ett smack när du placerat L-parametern i villkorsdelen.
Alla parametrar i SetGvarIf() skall ju placeras i 4:e positionen.
Ska testa detta i morgon och återkommer.


Edit: Jag börjar ta in lite nu om den fantastiska tidsmaskinen du uppfunnit i inlägg #43 där det omöjliga inträffar att "nutid"="dåtid".
Det är helt enkelt ingenting annat än systemtid kontra datortid du menar, right?

[Rikard Nilsson]

Det här ser ut att funka, jag ändrade till D istället för Date() i parameter 3 nedan. Det är viktigt att komma ihåg att skrivning sker hela tiden till cellen med avseende på datumdelen av cellen. Dvs, tillhörande "datumcell" får alltid nytt värde vid varje cykel, men värdet som skrivs villkoras av If-satsen. Då har vi en fungerande kombination där man både isolerar bort påverkan från diagramritning, samt att man kan villkora skrivning till cellen. Att däremot läsa ut tidstämpeln från datumcellen blir inget användbart eftersom det i princip bara motsvarar början på innevarande period hela tiden. Eller D med andra ord.

Jo, det stämmer att man både kan räkna med systemtid och databastid. Det kan ju finnas situationer där man vill kunna använda det ena eller det andra osv.



{ 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,D,L)
SetGvarIf(if(short2,minut_nu,GetGvar(90)),90,D,L)

draw(med2,2,bqb)
and(buy2,1)
)

[LillWicke]

Nu har jag testat och nedan följer en utvärdering av vad som hittills framkommit i denna tråd.

Villkorsbuggen i SetGvarIf är en ständigt närvarande följeslagare och flera försök har under åren gjorts för att försöka skriva runt denna.. Själv har jag pysslat med detta de senaste två månaderna utan att lyckas. Nu i denna tråd har hittills två seriösa alternativ framkommit, Rikards och Henriks.

1) Henriks alternativ går ut på att helt sonika koppla bort diagramritningen och på så sätt undgå buggen. Detta fungerar, men har andra nackdelar, såsom att signaler och ritade kurvor som scripten genererar inte syns i diagrammen. Dessutom får man inte glömma att aktivera larmbevakningen annars körs inte scripten. Ett alternativ här kan vara att man skapar dubbla script, ett som innehåller Setgevarif(), (och som körs i ordermodellen), samt ett annat modifierat script som kopplas till diagrammen, och som finns till bara för att generera grafik. Detta blir ju lite pysslande för att inte undvika kollisioner med orderscriptet, men borde kunna gå om man är noggrann.

2) Rikard har konstruerat en ”tidsmaskin”. Den går ut på att inte använda SetGvarif()´s villkorsdel alls, utan i stället göra en omskrivning och ta in villkoren i värdedelen. Detta grepp fungerar, ”tidsmaskinen” är stabil samt har även fördelen att den fungerar även om diagramritningen är påslagen, men den har en allvarlig brist. Den fungerar bara inom den period som anges av intradayprefixet. När ny period inleds blir det blockerade villkoret sant och ett nytt värde skrivs in i villkorscellen. Detta är inte bra eftersom en villkorscell endast skall uppdateras med nya värden om villkoret i själva scriptet ändras och inte när ny period/stapel inleds. Villkoret i själva scriptet kan ju ta flera staplar på sig för att ändras, ja kanske en hel dag eller flera dagar. Detta medför att det är omöjligt att veta när/(vid vilken tidpunkt) en signal först gavs, vilket ju är själva vitsen med en villkorscell. Vem vet, Rikard kanske kan konstruera en ”tidsmaskin nr2” som tar hand om denna brist? I väntan på detta går ”tidsmaskinen” som den fungerar idag inte att använda till att lagra triggersignaler i villkorsceller.

Jag har en vädjan till de ansvariga.
I stället för att försöka göra diverse omskrivningar eller ta till andra knepigheter, ta tag i själva villkorsbuggen och lös den, så att de globala cellerna och SetGvarIf() kan börja användas som tänkt.

[Rikard Nilsson]

Jag har lite svårt att förstå var "buggen" är? Villkoren fungerar ju som det står beskrivet (åtminstone så långt vi testat enligt ovan):

setgvarif(värde,cell,villkor,T) sätter värde när "villkor" blir sant. Ingen hänsyn tas till scriptkörning vid diagramritning vilket gör att celler kan sättas när man ritar om diagram. Helt naturligt.

setgvarif(värde,cell,tidstämpel,L) sätter värde när tiden är senare än den tidstämpel som anges som parameter 3.


För att kombinera dessa båda får man scripta lite, vilket möjligen kan tyckas omständigt, men det är knappast en bugg. Det beror ju helt på vad man vill göra.


Fick lite mer tips från Lasse som kan vara användbara:

isToday:=eqv(int(date()),int(d))
isDiagram:=or(gt(cum(1),1),not(isToday))
isOrderModel:=gt(omInfo(s),0)


Om du vill göra generella script för både bevakning och diagram men spärra vissa saker som skrivning till globala celler osv kan du använda ovanstående.

cum(1) är ett i första perioden som beräknas, och ökar med 1 sedan för varje stapel genom grafen.
Om det är större än 1 är det flera staplar och alltså diagram, men för fallet att cum(1) är 1 i första perioden kollar man så det inte är idag. Då skall den vara säker.

omInfo(s) ger noll, tror jag, om det är i graf.

Så du kan använda negation av vilket dera också

ärDiagram:=not(isOrdermodel)

eller

ärOrdermodell:=not(isDiagram)

mvh
Lasse

[LillWicke]

Jag har lite svårt att förstå var "buggen" är? Villkoren fungerar ju som det står beskrivet (åtminstone så långt vi testat enligt ovan):

setgvarif(värde,cell,villkor,T) sätter värde när "villkor" blir sant. Ingen hänsyn tas till scriptkörning vid diagramritning vilket gör att celler kan sättas när man ritar om diagram. Helt naturligt.

Men, hur många gånger ska jag behöva säga detta?
Det är ju här buggen ligger. Värde skrivs in till cellen oavsett om villkoret är sant, eller falskt. De enda villkor som fungerar är fast inskrivna 1 eller 0 som jag redogjort för tidigare i tråden. Om du kallar det naturligt så vet jag inte vad.

setgvarif(värde,cell,tidstämpel,L) sätter värde när tiden är senare än den tidstämpel som anges som parameter 3.

För att kombinera dessa båda får man scripta lite, vilket möjligen kan tyckas omständigt, men det är knappast en bugg. Det beror ju helt på vad man vill göra.

Då får du nog scripta väldigt duktigt. Kombinationen av en bugg och en ickebugg blir fortfarande en bugg.

Fick lite mer tips från Lasse som kan vara användbara:

Inte för att jag kan se hur dessa tips kan hindra SetGvarIf() från att skriva i cellerna trots att villkoret är falsk, men jag lovar att titta på detta.

[Rikard Nilsson]

Precis som du själv säger (och som även Henric konstaterat) uppträder "buggen" bara när man kör med diagramritning påkopplad. Och "buggen" är alltså ingen bugg utan bara den naturliga effekten av att script körs när diagram ritas och om villkoret blir sant någon gång under diagramritning så sätts värdena enligt det villkoret vid den tidpunkten.

Vill man isolera bort effekterna av att script körs kan man ta till någon av lösningarna ovan, och även prova de tips som Lasse kom med. Jag kan inte se hur vi ska kunna lösa det på något annat sätt?

[Henric]

Precis som du själv säger (och som även Henric konstaterat) uppträder "buggen" bara när man kör med diagramritning påkopplad. Och "buggen" är alltså ingen bugg utan bara den naturliga effekten av att script körs när diagram ritas och om villkoret blir sant någon gång under diagramritning så sätts värdena enligt det villkoret vid den tidpunkten.

Vill man isolera bort effekterna av att script körs kan man ta till någon av lösningarna ovan, och även prova de tips som Lasse kom med. Jag kan inte se hur vi ska kunna lösa det på något annat sätt?

Det är ingen bugg, men kan uppfattas så. Vad kom först, hönan eller ägget? Det positiva är att problemet har blivit belyst och de som ritar med globala celler är medvetna.

[LillWicke]

Och "buggen" är alltså ingen bugg utan bara den naturliga effekten av att script körs när diagram ritas och om villkoret blir sant någon gång under diagramritning så sätts värdena enligt det villkoret vid den tidpunkten.

Det du skriver här är ju rena självklarheterna, du får väl köra med en trigger som är stabil. Script med diagramritning påslagen och script med bara larmbevakat påslaget uppdateras ju dessutom, enligt dig själv, med samma frekvens så därvidlag ska det ju inte vara någon skillnad.

Gör som jag, kör med en stabil trigger och identiska script parallellt, där det ena kör med diagramritning påslagen och det andra inte. Naturligtvis skiver scripten inte i samma celler och naturligtvis loggar du hur triggervillkoren stod vid skrivning. Det blir skillnad.

[LillWicke]

Det är ingen bugg, men kan uppfattas så.

Och ändå kör du alltid med diagramritningen frånkopplad för säkerhets skull.

[Henric]

Ok, vi kan kalla det en paradox, ha ha. Kör jag testing på livedata så behöver jag inget diagram. Det är ju signalerna som gäller. Vill jag kolla något i diagrammet gör jag det och är medveten om omritning.

[LillWicke]

Häpp.

Jag fick en idé när Rikard förklarade sin tidsmaskin, speciellt att diagramet ritar i en tid och scriptet kan köras i en annan. Dessutom visade det ju sig att L-parametern var datumformatskänslig.

Jag tog helt sonika och bytte ut alla Date() i mina lite större testscript mot D, och vipps så verkar allt fungera. även med diagramritningen påslagen.

SetGvarIf()-funktionen är alltså datumformatskänslig, och detta oberoende av vilken parameter man använder (jag har nu kört med T-parametern).

Det verkar som om när diagramvisningen är påslagen så måste datumformatet i scriptet lira med det datumformat som diagrammet uppdateras i, annars fungerar inte SetGvarIf()

Någon annan kanske kan utveckla det hela närmare.
Rikard kommer väl säga: "helt naturligt"

[Rikard Nilsson]

Det här ser också ut att fungera:

{ Skrivning }
SetGvarIf(minut_nu,80,and(buy2,eqv(cum(1),1)),T)
SetGvarIf(minut_nu,90,and(short2,eqv(cum(1),1)),T)

[LillWicke]

Och vad har du för förklaring till inlägg #57?

[Rikard Nilsson]

Precis som du skrev, det är helt naturligt. Fenomen som man kanske inte tänkt på kan ju uppstå när man skriver in "nutid" från Date() på ställen där scriptet körs i "dåtid" medan diagramritningen sker.