Konstiga signaler

[Henric]

I simulatorn och vet ej live.

Jag provade att lägga till ett villkor med en indikator och några andra villkor. Tider, etc. Jag tyckte att det inte stämde och provade att ha kvar villkoret utan att det ska kunna påverka något annat. Jag fick inte samma signaler som att köra helt utan villkoret. Det finns inga fel i kompilatorn och jag provade att byta namn för att vara säker på att namnet inte krockar med något annat. Samma problem. Till sist körde jag villkoret i en egen modell och sparade värdet i en cell. Då fungerar villkoret som tänkt i originalmodellen. Jag upptäckte problemet, men generellt skulle det kunna bli felaktiga signaler utan att man märker något. Vad kan det vara och har någon haft samma problem?

[Rikard Autostock]

Kommentarer vet vi kan ställa till det.

[Henric]

Inga kommentarer. Ha Ha...
Det enda som skiljer när det fungerar är att värdet från indikatorn hämtas från en global cell med sparat värde från en annan ordermodell som inte triggar.

[Rikard Autostock]

Ok, då jag har inga kommentarer...haha

Svårt utan att ha sett någon kod....

[Henric]

.......
villkor=gt(rsiws(2),60)
.......

Lägger jag till denna rad som inte används någon annan stans får jag helt andra signaler.

Det verkar som att det är rsi som skapar buggen. Är det deja vu. Har för mig att det skrivits om detta tidigare. Byter jag till stoch() blir det samma signaler med och utan villkoret.

Edit: Jag har testat lite mer. Jag är 100% säker på att det just är rsiws som skapar problem och att projektet ger konstiga signaler. Detta utan att själva villkoret används som trigger eller i andra beräkningar. Samma sak händer ej med tex stoch(). Jag har provat att bygga om projektet för att vara säker på att inget är korrupt.
Jag har även provat med några script och samma sak händer inte. Längden är bara två perioder så något med minnet eller liknande borde det inte vara.
Varför just rsiws skapar problem i bland är underligt. Kan det beror på scriptens läng eller i vissa sammanhang, etc. Någon att vara vaksam på om man tycker att något inte stämmer.

Edit: Något med själva namnet som spökar i kombination med något annat?

[Henric]

Jag fortsätter min monolog. Vem som helst kan råka ut för detta utan att de vet om det. Man ska nog inte ta med en klackspark. Hittade ytterligare en konstighet och jag börjar tro att det är felaktig data som kan skapa problem i beräkningar (det vet jag ju inte). Det sker ju ingen varning från kompilatorn.

Som jag skrev tidigare kan en rad som sedan INTE används någon annan stans eller ingår i någon annan beräkning skapa helt olika signaler.

Skapar problem: villkor=gt(stoch(100),60)
Skapar inte problem: villkor=gt(stoch(10),60)
Skapar problem: villkor=gt(rsiws(2),60)

[Lord S]

Spelar det någon roll vart i skriptet du lägger in raden?

[Henric]

Jag fick problem med rsi på ett ställa och stoch på ett annat.

Om lägger ner tid skulle man kunna gå bakvägen. Behålla villkoret som skapar problem. Sedan utesluta andra villkor tills det fungerar. Problemet då är att hålla reda vad som är riktiga och vad som är felaktigs signaler. Scriptet ändras hela tiden.

[Bertil]

Jag har märkt som Henric påpekar i det första inlägget
att om man mellanlagrar i en global cell och sedan testar
på värdet i den globala cellen så hjälper man kompilatorn
att låta bli att lägga krokben på sig själv.

Alltså testa med att spara rsiw värdet i en global cell
och på nästa rad utför testen på den globala cellen.
Jag tror att det är den totala beräkningsmängden i scriptet
som får bägaren att rinna över för kompilatorn.

Mvh
Bertil

[Henric]

Exakt. Det är så jag har gjort.

Nu vet jag inte vad den totala beräkningsmängden är. Det finns ju massor av saker som kompilatorn testar. Mitt script är ganska långt. Många saker som inte är med live. Ändå inte i stil med dina script, Bertil.

1. Det blir knöligt, men får duga som temporär lösning. Det gäller sedan skarpt att den modell som bara lagrar värden kör först i samma insamling så att triggermodellen alltid har färska värden. Gäller särskilt i börja av en stapel. Glöm minut animering, vilket jag ändå inte använder.

2. Blir det helt galet eller error så märker man det. Annars vet man ju varken ut eller in.

3. Om man vet i vilka situationer det händer eller hur man upptäcker skulle det underlätta.

Edit: Nu förutsätter vi att det beräkningsmängden. Som sagt vet ju inte vad beräkningsmängden innebär och det är det som är problemet. Jag har tidigare testat modeller där värden skrivs och beräknas i hundratals celler. Detta för att få många kombinationer till en modell. Som att slå ihop optimerade värden för att få fram signal och styrkan i signalen. Detta utan problem.

[Henric]

Jag har märkt som Henric påpekar i det första inlägget
att om man mellanlagrar i en global cell och sedan testar
på värdet i den globala cellen så hjälper man kompilatorn
att låta bli att lägga krokben på sig själv.

Alltså testa med att spara rsiw värdet i en global cell
och på nästa rad utför testen på den globala cellen.
Jag tror att det är den totala beräkningsmängden i scriptet
som får bägaren att rinna över för kompilatorn.

Mvh
Bertil

I detta fall tror jag inte det handlar om beräkningsmängden. Signalerna kan bli konstiga i början av körningen. Jag tror inte heller det beror på de sista villkoren som jag lade till(enligt problembeskrivning tidigare), utan att det helt enkelt kan bli konstiga signaler när beräkningar görs då det fattas data i intradagsdatabasen. Dvs funktioner och indikatorer tittar på historisk data. De underligaste är att det är när indragsdatabasen saknar data även om look-back tittar på dagsstpalar. Använder man tex ett bolinger med 20 perioder måste det finnas 20 dagars intradagsdata bakåt i tiden. Kör man ett 200 dagars medelvärde måste det finnas 200 dagars intradagsdata. Annars kan det bli skumma signaler och man tolkar det negativt. Blir det bättre tänker man inte på det blir det sämre så reagerar man.

[Henric]

Jag kan lösa problemet genom att sätta startdatum i simulatorn innan själva körperioden börjar. Sedan att scripten inte får trigga innan körperioden. Tex om en simulering börjar 2009-01-01 väljer jag startdatum 2008-07-01.

Förslag ät att någon check görs innan själva simuleringen börjar och att simulatorn gör detta per automatik.

Om den första signalen blir konstig eller att den t.o.m. kommer innan körperioden börjar beror det på att startdatumet för simuleringen är en dag då börsen är stängd. Lösningen är som i första stycket eller att flytta fram startperioden till första börsdag. Vid multi-asset vet jag inte vad som händer.