Spökeffekt

[HenrikSyst]

Tar jag bort raden som börjar med ABUY så får jag helt andra resultat av skriptet TROTS att inte variabel används senare i skriptet. Hur kan det komma sig?



Alltså en variabeln påverkar trots att den inte används senare. Kompileringsfel? Kör skriptet i minut upplösning

Detta är bara en liten del av ett större skript.
i60(
ABUY=aref(ATR(20),1)
psl=sub(pl,diffsl)
pc=add(psh,diffcov)

[Bertil]

Tar jag bort raden som börjar med ABUY så får jag helt andra resultat av skriptet TROTS att inte variabel används senare i skriptet. Hur kan det komma sig?



Alltså en variabeln påverkar trots att den inte används senare. Kompileringsfel? Kör skriptet i minut upplösning

Detta är bara en liten del av ett större skript.
i60(
ABUY=aref(ATR(20),1)
psl=sub(pl,diffsl)
pc=add(psh,diffcov)

Kan det ha med variabelnamnet att göra?
Byt namn från ABUY till tex hejsan och se om det blir någon skillnad.
Eller så kan det vara så att scriptet är så stort att någon buffert blir full. Testa då att ta bort någon annan rad som inte har så stor betydelse och se om det blir samma fenomen.
Jag har själv varit med om problem med för stora script. Då får man labba och ha fler villkor ovanför periodavdelaren.
Dvs skriv:

ABUY:=aref(ATR(20),1)
i60(
...

Med vänlig hälsning
Bertil

[Rikard Autostock]

Kör generellt längre variabelnamn än bara två tecken för att undvika risken att de blandad ihop i compilern.

[HenrikSyst]

Har ett annat skript som inte har periodavgränsare och det verkar inte känsligt för längden. Namnet spelar ingen roll för effekten.

Detta skript verkar väldigt känsligt för längden på skriptet och tiden det tar att köra tror jag. Min teori är att det de extra raderna överflödig kod gör exekveringen långsammare vilket medför att den missar perioder och det råkar medföra bättre resultat.

Tog bort andra rader och det var inte just denna rad som påverkade utan det var mängden funktioner som skulle köras. Provade att lägga på tung kod och det påverkade också.

Om den inte hinner med att exekvera så dröjer det ju 60 min innan nästa analys görs då det är inställt på 60 minuter och allt baseras på föregående period.

Provar nu att köra i 5 sekunders upplösning med och utan nonsenskod. Ska också prova att styra när signalen ges med Xtime så att ordern ges konsekvent vid samma tid.

Blev ganska lurad av skriptet....

[Bertil]

Då jag tar fram kod så brukar jag alltid rita ut linjer i realtidsfönstret av funktionerna. Är det en funktion som ger ett litet tal så kan man addera det talet till c och rita ut med drawfunktionen. Försvinner linjen (vilket händer rätt ofta då man har komplicerade script) så får man börja att felsöka och kommentera bort kod, lägga över funktioner till ovanför periodindelaren (eller ta ned funktioner därifrån). Har säkert lagt 10-tals timmar på den typen av felsökning genom åren. Förr eller senare kommer man på något sätt att gå runt problemet. Ett sätt är att ha slavordermodeller som inte handlar utan bara skriver in värden i globala variabler.

Med vänlig hälsning
Bertil

[HenrikSyst]

Bra tips

Koden är komplicerad med externa objekt och olika upplösningar. Hur som helst så hjälper inte något av att köra i mer frekventläge (5 sek) eller spärra.

För så hur jag löser detta?

(La in samma nonsens kod i ett liknande skript utan periodindelare och det påverkades inte)

[Rikard Autostock]

Det som kan orsaka problem är variabelnamn som liknar funktionsnamn för mycket, och faktiskt även kommentarer. Jag skulle börja med att ta bort kommentarer och öka längden på ev korta variabelnamn.

Exekveringen av långa script kan aldrig "inte hinnas med" eftersom compilern kör igenom varje script innan den går vidare till nästa. Man kan märka det på en tungt konfiggad installation att det tar betydligt mer än 5 sek mellan intervallen. Det körs som en loop där alla anslutna script körs igenom, därefter loop-delay 5 sek (eller så många sek som den är inställd på), därefter loop tillbaka till början.

Extra objekt kan påverka eftersom flera dataserier används och compilern försöker matcha dessa tidsmässigt.

[HenrikSyst]

Det som kan orsaka problem är variabelnamn som liknar funktionsnamn för mycket, och faktiskt även kommentarer. Jag skulle börja med att ta bort kommentarer och öka längden på ev korta variabelnamn.

Exekveringen av långa script kan aldrig "inte hinnas med" eftersom compilern kör igenom varje script innan den går vidare till nästa. Man kan märka det på en tungt konfiggad installation att det tar betydligt mer än 5 sek mellan intervallen. Det körs som en loop där alla anslutna script körs igenom, därefter loop-delay 5 sek (eller så många sek som den är inställd på), därefter loop tillbaka till början.

Extra objekt kan påverka eftersom flera dataserier används och compilern försöker matcha dessa tidsmässigt.

Menar nog snarare att exekveringen körs igenom och det tar olika lång tid vilket kan påverka resultatet.

[HenrikSyst]

Hur som helst övergav jag koden tillsvidare. Hittade ett sätt att få ungefär det jag ville ha utan en komplex konstruktion.

Sedan (på grund av detta missöde) så kom jag en helt ny strategi på spåret. Byggde den som en spinoff på en som jag tog fram tidigare. Den var mycket bättre.

[Bertil]

Hur som helst övergav jag koden tillsvidare. Hittade ett sätt att få ungefär det jag ville ha utan en komplex konstruktion.

Sedan (på grund av detta missöde) så kom jag en helt ny strategi på spåret. Byggde den som en spinoff på en som jag tog fram tidigare. Den var mycket bättre.

Du får gärna berätta vilka principer du använder i de olika strategierna. Fast kanske i en annan tråd. Är det statistiska fenomen sett på dagstaplar med data 4000 dagar bakåt fortfarande eller är du inne på andra tankar.
Själv har jag ägnat helgen till att simulera volymprofil utgående från ett daytradingperspektiv. Fungerar bra vissa månader och dåligt andra. Testade med en massa olika filter, men fick inte till något bra.

Med vänlig hälsning
Bertil