Markowitz modeliui reikalingas statistikas geriau įsivertink pats, bent jau žinosi, už kokį periodą ir kad naudoji teisingas formules.

Rodiklius irgi geriausia skaičiuoti pačiam, siekiant išlaikyti pelno ar ko kito apibrėžimo vienodumą, bet čia jau daugiau darbo, tai galima būtų pateisinti ir jau paruoštų skaičių naudojimą. Paskutinio laikotarpio P/E gali rasti čia.

Handrail, labai "gražus" antras paveiksliukas Skirstinių skirtumus tik vizualiai tikrinai ar ir kaip nors įmantriau?

Galiu visaip pažiūrėt, bet tiek algoritmui, tiek analizei tai nėra svarbu iš esmės. Tas paveiksliukas biškutį galvą turėtų pakrutint ir priverst pamąstyt "ir kas iš to". Nieko daugiau. Šiaip jei domina, galiu dar kažką prasukt Va žiūrėk, dar vienas paveiksliukas, kuris tau turėtų patikti ir nustebinti. Bent jau man taip buvo.

Hmz... O PACF kaip atrodo?

Realybėje taip nebūna ... Jei teisingai supratau, kas pavaizduota tame paveiksliuke, tai man čia labiau panašu į klaidą skaičiavimuose: kur nors įsivėlė bereikalingas ženklo keitimas (daugyba iš -1), todėl ir gavosi kas antra reikšmė skirtingo ženklo...

Karolina, mano kompiuteriukas per 45min pac neprasuko. Ryt gal pabandysiu per ilgiau.
Egi, kad į kurią pusę ne taip ir svarbu ten.. Biški įdomesnių dalykų gi yra. O dėl skaičiavimų klaidos- nebent OANDA duomenys prasti. Nes ne ant vieno kompo testinau. Tai tuo atveju, jei OANDA atsiuntė blogą DATA, tada taip- klaida.

Va, pagaliau prasuko pac. Prikabinu. Irgi gana įdomūs rezultatai.

Kompas čia nei prie ko, jei klaida yra skaičiavimo formulėse/algoritme arba duomenyse... Handrail, ką tu ten įdomesnio įžvelgi? - Tai, kad autokoreliacija, didėjant "laiko atstumui" (Lag'ui) tarp verčių, greitai slopsta??? - Man tai savaime suprantamas dalykas ir todėl nekelia jokios nuostabos: juk negali Tick'as stipriai (anti-)koreliuoti su Tick'u, esančiu prieš keletą minučių, keletą valandų ar netgi dienų. Man kur kas įdomesnis rezultatas, kad autokoreliacijos ženklas kaitaliojasi -, +, -, + ir t.t.
Taip, tu teisus: ženklo kaitaliojimasis gali būti susijęs ne su klaida skaičiavimuose, bet gali būti įtakotas įeitinių duomenų. Handrail, o kokie Tick'iniai duomenys buvo naudojami tyrime: Bid Tick'inė laiko eilutė, Ask Tick'inė laiko eilutė, (Bid+Ask)/2 Tick'inė laiko eilutė, Last (nežinau, ar Oanda pateikia Last kainą - ^la galėtų patikslinti) Tick'inė laiko eilutė ar dar kokia nors kita? Man kilo viena tokia hipotezė, dėl ko galėjo atsirasti ta "švytuoklė" (-, +, -, + ir t.t.): jei buvo naudojama "kombinuota" Bid ir Ask Tick'ų laiko eilutė, kurioje Bid ir Ask kainas Oandos API išduoda ne vienalaikiškai (ne vienu laiko momentu), o paeiliui (Bid, o paskui Ask arba atvirkščiai), ši perturbacija kaip tik ir galėjo iššaukti ženklo kaitaliojimąsį, nes 99.(9)% atvejų Bid < Ask.

Egi, ten kiek atsimenu BID exportinau. Arba ASK. Bet greičiausiai bidas eina. Pats ką matau įdomaus, tai kad AC iki 20 lago nepataiko į band'us. PAC jau nuo ~10 pataiko. Čia man gana įdomu. Kad tiek daug lagų. Nes imant weekly/daily visai kitas vaizdas. Bet čia obvious. O dėl to +-+- tai man šian dėstytojas pateikė vieną hipotezę.
Pagal jį, tokį patterną išmestų STOCK variable, kuris mažėja su laiku. Pvz vedybos. Jei turim kaimą su 100 laisvų žmonių ir šiandien 2 susituokia, tai rytoj beliks 98 laisvi. Čia pagal jį gali būt panašiai. Kažkas užbidina, tada bidų kiekis sumažėja.
Šiaip netikiu, kad data bloga būtų.. Aš turiu bėdą, kad mano šitas kompiuteriukas netempia analizės ir man vis reik susiveikt padorų kompą ir persimetinėt duomenis, kad galėčiau tikrint. O tai laiko užima. Bet pabandysiu gal prie progos ant kitų tickinių duomenų iš OANDA paleist ir pažiūrėt, ką gausiu. Ir šiaip duomenyse daug vietų kai kas ticką kaina nepasikeičia, tai bid ir ask nelabai gali būt exportuoti. Kiek žiūrėjau tikrai nepanašu į tai.

Dovanok, Handrail, nepagalvojau, kad PACF skaičiavimas gali taip ilgai užtrukti, tiesiog man buvo smalsu, ar moving average procesą gavai, ar ir autoregresijos komponentė yra. Na ką, stacionarų prognozuojamą procesą išpešei, sėkmės toliau Man tik įdomu, kas bus, kai realybėj nepavyks uždaryt pozicijos ties konkrečiu tiku, o tik keliais tikais vėliau...

Dėl ženklo šokinėjimo mano nuomonė būtų tokia. Teorija sako, kad AR(1) proceso autokoreliacijos funkcijos reikšmes galima paskaičiuoti pagal rekursiją koeficientas*acf(lag-1). Tai jeigu koeficientas prie grąža(t-1) yra neigiamas, gaunasi "švytuoklė" (iš esmės Egis teisus dėl daugybos iš -1, bet tai nėra klaida). Su 2,5 mln. stebėjimų didžiųjų skaičių dėsnis suveikia labai gražiai ir empirinės autokoreliacijos tampa artimos teorinėms. Aišku, turint ARMA(20,10) rekursija ne tokia triviali, bet principas turėtų būti panašus (kažkaip neteko matyti išvedimų sudėtingesniem modeliam).

Darant analogiją su vedybom, kiek pamenu iš market microstructure, tai tokie paprasti kainos-kiekio priklausomybės modeliai empiriškai nepasitvirtino...

Beje, dieninių/savaitinių/... duomenų koreliacijos, aišku, bus kitokios: tikinių duomenų didesnis pastovumas (persistence) - gerai žinomas faktas (stylized fact). Kitaip ir negali būti, jeigu jau net plika akimi pastebi, kad karts nuo karto bid ar ask kaina nesikeičia. Klausimas tik, kaip tuo pasinaudoti

Kiekviename OANDOS tick'e yra tiek Bid, tiek Ask kaina. Paskutiniai EUR/USD tick'ai gauti per API:


Jei Handrail naudojo istorinius OANDOS duomenis, juose taip pat pateikiama Bid/Ask kaina.

Egis_1974, bene ir tu "išviniojai" OANDOS tick'ų protokolą, kad kalbi apie nevienalaikiškumą ?

Dalis tiesos tame yra, bet tik dalis. Idėmiau pažiūrėjus, tick'ai ateina blokais, todėl apie nevienalaikiškumą kalbėti, mano manymu, pagrindo nėra.

La, aš tik vieną kainą exportinau. EUR/USD atrodo geriau. Bet neturiu paveiksliuko. Ten švytuoklės nėra. Tai net nežinau kas čia su tuo XAU atsitiko tikrai.
Karolina, uždarymas ant konkretaus ticko nėra toks jau svarbus. Bet whatevz, jei kažką gausiu- pasidalinsiu

OANDA neleidžia rinktis, kokia kaina bus eksportuojama. Paduoda iškart abi. Bent jau ši paslauga. XAU istorinių duomenų parsisiuntimui šiuo būdu jie neduoda.

Truputi nukrypom nuo temos. Man atrodo tu kapstaisi nevisai ten, kur kažką rasi. Žinoma, savišvietai tokie kapstymaisi labai naudingi. Tai labai padeda formuojant adekvatų rinkų veikimo suvokimą, taigi ir adekvačius lūkesčius.

Nemanau, kad tavo dėstytojo hipotezė teisinga. Karolina glaustai įvardino vieną iš priežasčių. Na, bet nesiginčysiu, nes akivaizdžių, lengvai paaiškinamų įrodymų neturiu...


O tai kokia tokio Tick`o prasmė, jei nepasikeičia nei Bid, nei Ask? Ar tu čia turėjai galvoje, kad kartais Bid išlieka nepakitęs, o kartais - Ask, bet niekada nebūna, kad nei viena iš Bid/Ask kainų nepasikeistų?

Tai, kad duomenyse yra tiek Bid, tiek Ask, dar nereiškia, kad Handrail abi šias kainas naudojo savo tyrime. Dėl to ir pasiteiravau jo, kurią kainą (arbą jų kombinaciją) jis analizavo.
Mano hipotezė apie Bid/Ask kainų nevienalaikiškumą būtų pasitvirtinus, jei Handrail į vieną laiko eilutę būtų įtraukęs ir Bid, ir Ask. T.y., jei būtų analizuota panaši seka (imu realias Tick'ų kainas iš ^la žinutės):

Grafiškai ši seka atrodytų taip:
Dėl to, man ir kilo idėja, kad autokoreliacijos ženklo kaitaliojimasis ("švytuoklė") gali būti įtakotas tokios periodinės perturbacijos. Būtų įdomu užmesti akį į Tick`inius duomenis, iš kurių buvo gauta "švytuoklė". Handrail, gal galėtum čia įkelti nedidelį Tick`inių XAU duomenų fragmentą?



O tu jau "išvyniojai"? ...
Aš Oandos API nenaudoju, bet kalbu iš analogijos su InteractiveBrokers. Tenais visos Tick`inės kainos perduodamos, naudojant tą patį Event'ą - skiriasi tik identifikatorius, kuris nurodo, kokio tipo kaina gauta: Bid, Ask, Last, High, Low ar kt. InteractiveBrokers Bid ir Ask kainas laiko skalėje dažniausiai perduoda poromis (su minimaliu vėlinimu tarp Bid ir Ask), tačiau nėra patikimo būdo abi šias kainas "suporuoti", nes nėra jokio identifikatoriaus, kuris leistų nustatyti, jog tas Bid`as ar anas Ask`as priklauso tam pačiam Tick'ui, o poruoti vien tik pagal laiką, nemanau, kad yra gera idėja... Aplamai, laikausi nuomonės, kad Bid ir Ask poruoti nereikėtų, nes realioje rinkoje Bid ir Ask kitimas nėra labai griežtai surištas, priešingai nei pas FX dilingo "virtuves" su fiksuotu Spread`u. Dėl to, jei aš Bid ir Ask kainas, gautas iš InteractiveBrokers API, iškart išvedinėčiau į log failą, gautųsi kažkas panašaus į tokią seką:



Sutinku. Visi duomenys iš serverio į kompiuterį bet kokiu atveju patenka nuosekliai (kalbu apie nanosekundžių/mikrosekundžių lygmenį), tačiau jei Oandos API yra realizuotas patikimas mechanizmas, leidžiantis suporuoti Bid ir Ask, ir jei Oanda Bid/Ask duetą pateikia kaip nedalomą Tick'ą, tuomet iš tikro nėra pagrindo kalbėti apie nevienalaikiškumą.

Taip, nuo temos truputį nukrypta, tačiau tinkamesnės temos tokiai diskusijai nelabai radau. Smagu truputį "pamankštinti" smegenis ...

Egi, prašau, fragmentas duomenų, plius vizualiai x-time, y-prc.

">http://www.lrytas.lt/verslas/karjera-ir-rinkodara/diplomas-geriausiems-lietuvos-darbdaviams-bevertis.htm

Iš pateikto fragmento nesimato jokių ženklų, kurie galėtų sukelti "švytuoklę". Į akis krito tik tai, kad 2-o paveiksliuko "prc" stulpelyje (1-as iš kairės) duomenys nesutampa idealiai su duomenimis stulpelyje, kuris yra 1-as iš dešinės. Gal čia taip ir turi būti???

Stata apvalina keistokai. Bet abejoju, kad būtent čia esmė..