Periodtider

[petersi]

Rikard, har ni övervägt det här med samplingsteoremet när ni utvecklat NAT?

[Bertil]

Samplingsteoremet är ju viktigt om man har en jämn sinusformad störning. Säg att man skall mäta en signal med samplingsfrekvensen 60 Hz och råkar ha en kraftig störning på 50 Hz på mätsignalen. Då kommer mätresultatet att visa att man istället har en lågfrekvent störning under 50 Hz.
Vid aktiehandel så har man nästan aldrig perfekta sinusformade rörelser, så samplingsteoremet är inte så viktigt. Vad som är viktigare är ju att om man bara tittar på close på 1 timmarsstaplar så försvinner mycket användbar information. Nu förstår jag varför de som använder 1 timmarsstaplar är så intresserade av köp och säljvolym för där får man ju en slags medelvärdesbildning.
mvh
Bertil

[Rikard Nilsson]

Rikard, har ni övervägt det här med samplingsteoremet när ni utvecklat NAT?

Jo naturligvis, men tidigare har vi varit tvungna att ta hänsyn till tekniska begränsningar (främst i AT8), medan vi nu samplar varje sekund och därmed får med allt data som Nordnet skickar ut. Vi når alltså inte en samplingfrekvens av bandbredd x2 men frågan är om det skulle spela någon roll när vi inte får data snabbare en varje sekund. Dessutom körs ju inte scripten fullt så ofta. Man skulle kunna säga att data samplas med mer än fubbla frekvensen mot scriptkörningsfrekvensen. Jag tycker det är aningen akademiskt eftersom den stora majoriteten av tradingsystem tittar i betydligt längre perspektiv än enstaka sekunder.

[petersi]

Samplingsteoremet är ju viktigt om man har en jämn sinusformad störning. Säg att man skall mäta en signal med samplingsfrekvensen 60 Hz och råkar ha en kraftig störning på 50 Hz på mätsignalen. Då kommer mätresultatet att visa att man istället har en lågfrekvent störning under 50 Hz.
Vid aktiehandel så har man nästan aldrig perfekta sinusformade rörelser, så samplingsteoremet är inte så viktigt. Vad som är viktigare är ju att om man bara tittar på close på 1 timmarsstaplar så försvinner mycket användbar information. Nu förstår jag varför de som använder 1 timmarsstaplar är så intresserade av köp och säljvolym för där får man ju en slags medelvärdesbildning.
mvh
Bertil

Samplingsteoremet är oberoende av utseendet på kurvan. Det är bara att fouriertransformera signalen så har man ampitud, frekvens och fasläge för alla de sinusar som bygger upp signalen. dvs alla kurvformer är uppbygda av sinuskurvor.

[petersi]

Jo naturligvis, men tidigare har vi varit tvungna att ta hänsyn till tekniska begränsningar (främst i AT8), medan vi nu samplar varje sekund och därmed får med allt data som Nordnet skickar ut. Vi når alltså inte en samplingfrekvens av bandbredd x2 men frågan är om det skulle spela någon roll när vi inte får data snabbare en varje sekund. Dessutom körs ju inte scripten fullt så ofta. Man skulle kunna säga att data samplas med mer än fubbla frekvensen mot scriptkörningsfrekvensen. Jag tycker det är aningen akademiskt eftersom den stora majoriteten av tradingsystem tittar i betydligt längre perspektiv än enstaka sekunder.

Akademiskt eller ej, om det finns en möjlighet att förbättra tradingsystemen med kunskapen om att samplingsteoremet kan ha en inverkan, så borde det åtminstone analyseras för att senare avfärda det om det inte har någon påverkan. Om det har någon påverkan så är det just de långsammare tidsperspektiven som påverkas mest eftersom de undersamplar mest

[Rikard Nilsson]

Det finns inget sätt att förbättra samplingen ytterligare, vi har nått den tekniska gränsen med nuvarande API. Jag håller inte med om att de långsammaste systemen är mest känsliga för samplingshastigheten. Tvärtom som jag ser det.

[LillWicke]

Alla som håller på med skriptning vet att den innevarande stapeln körs i realtid och att det senaste ticket används för beräkning.

Alla som håller på med scriptning vet att du nu blandar ihop två skilda saker med varandra.

NAT:s realtids-körning och NATS:s scriptkörning, jag skrev särskilt i mitt inlägg att jag menade scriptkörningen.

[petersi]

Alla som håller på med scriptning vet att du nu blandar ihop två skilda saker med varandra.

NAT:s realtids-körning och NATS:s scriptkörning, jag skrev särskilt i mitt inlägg att jag menade scriptkörningen.

Och jag menar precis det här...

När det gäller exempelvis mov(c) så samplas den funktionen på de tidigare staplarnas close, men för den innevarande stapel används istället den senaste 5sekunders close:en för beräkning i scripten. Tidigare 5sek-closer i innevarade stapel har däremot ingen betydelse. Det innebär att den innevarande stapel får en väldigt stor tyngd i hur kurvan "ser ut" om man exempelvis kör en mov(c,3) i i1( upplösning.

Fast jag uttrycker det kanske inte med samma finess som dig LillWicke

[LillWicke]

Ok, petersi, eftersom du skrev ditt inlägg alldeles under mitt uppfattade jag det som ett generalangrepp på det jag skrev.

Skönt att vi är överens, åtminstone i denna fråga.

[Bertil]

Jag har ytterligare en fundering om periodtider. Istället för att starta en ny tråd så hakar jag på denna tråd.

De flesta script som jag använder bygger ju på break-out under ett fåtal minuter. Scripten går med i1 . Då jag simulerar i Analysbänken får jag stora skillnader mellan 1 och 5-sekunderssimuleringarna. Jag får även skillnader mellan 5-sekunderssimuleringarna och skarpa körningar (fast de jämnar ut sig över tid).

Man kan ju välja periodtid (hur ofta man skall ta stickprov på kursen) från 1 till godtyckligt stort heltal räknat i minuter.

Man kan även använda i0 då registrerar man varje förändring av kursdata som skett de senaste 5 sekunderna. Detta innebär dock att man går från synkron körning till asynkron körning av scripten. Tar man mov(c,5) så är det medelvärdet av de 5 senaste avslutskurserna. Är det 5*5=25 sekunder tillbaka eller 5 dagar (om man har derivat som nästa aldrig har avslut) vet man inte. Köp och säljkurser ändrar sig heller inte alltid synkront.

Finns det någon här som kör i0 och får script som fungerar som tänkt?

Då jag började testa i0 för ett drygt år sedan trodde jag att det fungerade på samma sätt som i1 fast med periodtiden 5 sekunder istället för 1 minut.

Jag översatte då mina script från i1) mov(c,3) till i0) mov(c,36) men det blev ju annorlunda. (Se ovan för förklaring).

Vad jag är ute efter är alltså script som fungerar på samma sätt som i1 fast att man tar stickproven lite oftare, t.ex varje 30 s eller 15 s.
Det är kanske så att i måste följas av ett heltal. Men i någon inifil står kanske att heltalet skall betyda 60 sekunder, som man kan ändra till t.ex 30 s? Fast då kanske det blir följdfel som man inte kan justera själv.

Det man egentligen vill ha är förstås möjligheten att skriva t.ex i0.25) och få script där medelvärdesbildning mm sker var 15:e sekund.

Med vänlig hälsning
Bertil

[Rikard Nilsson]

i0 betyder att varje tick ses som en period. Scripten körs fortfarande asynkront (vi har ingen synkron scriptexekvering ännu), men betraktar tex mov(c,5,s) som de senaste 5 pristicken som de 5 perioderna som utgör medel. Just 5 sek har ingen relevans i i0(), det är bara det asynkrona scriptexekveringsintervallet som är default i programmet, men som numera går att ställa i ini-filen.



PS: Diagrammet nedan sträcker sig över knappt 15 minuter och ritar 100-perioders enkelt medelvärde i tickupplösning så att man får lite perspektiv.

[Bertil]

i0 betyder att varje tick ses som en period. Scripten körs fortfarande asynkront (vi har ingen synkron scriptexekvering ännu), men betraktar tex mov(c,5,s) som de senaste 5 prisförändringarna som de 5 perioderna som utgör medel. Just 5 sek har ingen relevans i i0(), det är bara det asynkrona scriptexekveringsintervallet som är default i programmet, men som numera går att ställa i ini-filen.

Vid i1 tar man ju alla stickproven på c,b,s mm vid samma tillfälle. Det uppfattar jag som synkront. Alla värden vid Aref(dataserie,1) är ju också från samma tillfälle. Såg att du svarade innan jag hann lägga till min editering. Se sista raderna i inlägget ovan.
Med vänlig hälsning
Bertil

[Rikard Nilsson]

Jo, men scriptexekveringen är inte synkron. Den är asynkron som tiden det tar att exekvera plus loopdelay (5000 ms från början).

[Bertil]

Kan man på samma sätt som man kan ändra loopdelay (5000 ms default) ändra i1 från 60000 ms default till något mindre värde, eller blir allt kaiko då?
Med vänlig hälsning
Bertil

[Rikard Nilsson]

Nix, det går tyvärr inte.