Stigande kurva.

Två sätt att skriva samma sak, nämligen att kurvan stiger i detta fallet.

mvk5:=mov(c,5,s)
kurvaStiger:=gt(ROC(mvk5,1,%),0)
kurvaStiger:=gt(mvk5,aref(mvk5,1))

Fråga 1.
Måste dessa två uttryck alltid ge exakt samma resultat?

Fråga 2.
Finns det några synpunkter på vilken funktion som är mest resurskrävande för datorn, parentesdjup m.m.?

[lfm]

Eftersom den ena räknar om till procent kan ev. bli någon decimaldel annorlunda. Men alla beräkningar i Friendlys scripthantering använder s k dubbel precision eller 64 bits flyttal. Det är väl 17 siffrors noggrannhet eller så.

#1. Som princip borde de bli väldigt lika resultat. Men enbart en subtraktion och konstatera större eller inte, eller först procentuell beräkning kan ge skillnad. Det skulle förmodligen gå att konstruera exempel som skulle ge skillnad, men förmodligen med väldigt långa medelvärden så skillnaden i nivå bara skiljer i 13:e decimalen eller så.
#2. Den som också kräver procentberäkning blir tyngre än den som bara jämför två storheter, som blir subtraktion av två storheter.

[lfm]

Kom på en sak om prestanda.

I detta fallet där defintionen gör att mov() placeras i två upplagor i scriptet då aref() användes gör att det blir två separata beräkningar av medelvärdet.

Använd minnesreferens med enbart likamed inom intradayprefix så läggs medelvärdet upp med två värden, bara en gång.


mvk5=mov(c,5,s)
k1=gt(ROC(mvk5,1,%),0)
k2=gt(mvk5,aref(mvk5,1))

mov() körs och två värden läggs i minnet, nuvarande och förgående period.

aref() refererar till detta minnet och plockar ett värde bort, och de jämförs.

ROC() refererar också till minnet här, och beräknar två procentuella värden. Det blir nog tre medelvärden som läggs upp t.o.m eftersom två procentuella skillnader skall tas fram. Så mov() får leverera tre värden i det fallet. Du ser vid syntaxtest att ena varianten tar ett värde mer på stacken(den med ROC).

[Åke Sturefelt]

Tack Lasse, då vet jag hur jag skall tänka fram över.

Men detta med minnesref. Skulle man "slösa bort" dessa till så här korta skrivningar som i exemplet då är de snart slut. Det finns ju ett endligt tal för hur många man kan använda.

[Magnus]

Lustig sak det där med körningen för referenserna. Gäller det alla andra funktioner också att när AT kör kollar den om det behövs data från flera olika tidpunkter för just den funktionen/dataserien och att referens då är snabbare?


Det är förresten onödigt att jämföra mov(c,p,s) om man man börjar fundera på prestanda. Då är det snabbare att jämföra dagens värde med värdet som är p perioder bakåt istället. Alla de övriga värdena är gemensamma i summorna för medelvärdena och tar ut varandra, som här med p=5:

(c0+c1+c2+c3+c4)/5 - (c1+c2+c3+c4+c5)/5 = (c0-c5)/5

Alltså:
...
k2:=gt(c,aref(c,5))


Det kanske inte är lika pedagogiskt när man sitter och spanar efter hur glidande medel stiger och sjunker för att komma på något klurigt, men å andra sidan är det kanske bra att ha i bakhuvudet att stigande/sjunkande medel inte betyder mer än så heller.

[lfm]

Låt säga att du har ett ställe som behöver två olika längder på dataserie, t.ex två olika uppmjukade stochastic:

st1:=stoch(21)
ms1:=mov(st1,7,s)
ms2:=mov(st1,13,s)

Här stoppas st1 in på två olika ställen och det måste köras en stoch(21) som levererar dels 7 värden, och på andra stället 13 värden.

Med minnesrefar

st1=stoch(21)
ms1=mov(st1,7,s)
ms2=mov(st1,13,s)


Här kollar kompilatorn att st1 behöver som mest 13 st, och levererar det i en körning. Sedan kan ms1 och ms2 köra sina medel på detta från samma plats i minnet.

Detta gäller alla minnesreferenser att kompilatorn kör två pass för att undersöka dependencies mellan alla delar.


Sedan är det en intressant synpunkt på att optimera när man använder aritmetiska medel som du visar på.

Dock så fort du byter till linjärt viktat(W), eller exponentiellt viktat(E) medel så kan den förenklingen inte göras. Det är bara vid lutning på arimetiskt medel(S).