2013-03-25 19 views
21

Wszystko,Jak pobrać dane intraday giełdowe R

Czekam na pobieranie danych seryjnych albo z Yahoo czy Google na 15 - 60 minutowych odstępach na tyle historii, jak mogę. Doszedłem z surowego roztworu w następujący sposób:

library(RCurl) 
tmp <- getURL('https://www.google.com/finance/getprices?i=900&p=1000d&f=d,o,h,l,c,v&df=cpct&q=AAPL') 
tmp <- strsplit(tmp,'\n') 
tmp <- tmp[[1]] 
tmp <- tmp[-c(1:8)] 
tmp <- strsplit(tmp,',') 
tmp <- do.call('rbind',tmp) 
tmp <- apply(tmp,2,as.numeric) 
tmp <- tmp[-apply(tmp,1,function(x) any(is.na(x))),] 

Biorąc pod uwagę ilość danych szukam importować, martwię się, że może to być kosztowne obliczeniowo. Ja również nie dla życia mnie, zrozumieć, jak znaczniki czasu są kodowane w Yahoo i Google.

Moje pytanie jest dwojakie - jaki jest prosty, elegancki sposób szybkiego przechwytywania danych dla serii zasobów do R i jak zinterpretować oznaczanie znaczników czasu w plikach Google/Yahoo, z których będę korzystał?

+0

Daje mi ona błąd autoryzacji podczas próby użycia getURL. Używam go sam dla niektórych stron aukcyjnych, a ja korzystam z funkcji aplikacji Emacs, aby uruchamiać kod w określonym przedziale czasu. Może nawet edytować tekst podczas programowania. Nie wiem, czy część czasu jest nadal nierozwiązana? – PascalVKooten

Odpowiedz

21

Postaram się odpowiedzieć na pierwsze pytanie. Proszę zauważyć, że to moja interpretacja i mogę się mylić.

Korzystanie z linku podanego w przykładzie https://www.google.com/finance/getprices?i=900&p=1000d&f=d,o,h,l,c,v&df=cpct&q=AAPL dostaję następujące dane:

EXCHANGE%3DNASDAQ 
MARKET_OPEN_MINUTE=570 
MARKET_CLOSE_MINUTE=960 
INTERVAL=900 
COLUMNS=DATE,CLOSE,HIGH,LOW,OPEN,VOLUME 
DATA= 
TIMEZONE_OFFSET=-300 
a1357828200,528.5999,528.62,528.14,528.55,129259 
1,522.63,528.72,522,528.6499,2054578 
2,523.11,523.69,520.75,522.77,1422586 
3,520.48,523.11,519.6501,523.09,1130409 
4,518.28,520.579,517.86,520.34,1215466 
5,518.8501,519.48,517.33,517.94,0 
6,518.685,520.22,518.63,518.85,565411 
7,516.55,519.2,516.55,518.64,617281 
... 
... 

Uwaga pierwsza wartość z pierwszej kolumny a1357828200, moja intuicja, że ​​to ma coś wspólnego z POSIXct. Stąd szybka kontrola:

> as.POSIXct(1357828200, origin = '1970-01-01', tz='EST') 
[1] "2013-01-10 14:30:00 EST" 

Tak więc moja intuicja wydaje się być poprawna. Ale czas wydaje się być wyłączony. Teraz mamy jeszcze jedną informację w danych. TIMEZONE_OFFSET=-300. Więc jeśli zrekompensujemy nasze znaczniki czasu o tę kwotę, powinniśmy uzyskać:

as.POSIXct(1357828200-300*60, origin = '1970-01-01', tz='EST') 
[1] "2013-01-10 09:30:00 EST" 

Pamiętaj, że nie wiedziałem, o które dane dnia prosiłeś. Ale szybkie sprawdzenie Google Finance ujawnia, to były rzeczywiście poziom cen w dniu 10 stycznia 2013 r

enter image description here

Pozostałe wartości z pierwszej kolumny wydają się być pewnego rodzaju przesunięcie od pierwszej wartości wiersza.

1

Dlaczego nie ładować danych z Quandl? Na przykład.

library(Quandl) 
Quandl('YAHOO/AAPL') 

Aktualizacja: przepraszam, mam sobie sprawę, że tylko codziennie dane są pobierane z Quandl - ale zostawiam moją odpowiedź tutaj jako Quandl jest naprawdę łatwy do kwerendy w podobnych przypadkach

3

Tak więc pobieranie i standaryzacja danych skończyło się na tym, że było to więcej niż niedźwiedź, niż przypuszczałem - około 150 linii kodu. Problem polega na tym, że choć Google udostępnia dane z ostatnich 50 dni szkoleniowych dla wszystkich zasobów giełdowych, znaczniki czasu w dniach nie są ustandaryzowane: indeks "1" może na przykład odnosić się do pierwszego przyrostu po raz drugi pierwszego dnia handlowego w zbiorze danych. Co gorsza, zapasy, które handlują jedynie niewielkimi ilościami, mają tylko pozycje, w których rejestrowana jest transakcja. W przypadku dużych wolumenów, takich jak APPL, nie ma problemu, ale w przypadku małych nakładek o małej objętości oznacza to, że w przypadku Twojej serii zabraknie dużej, jeśli nie większości danych. Było to problematyczne, ponieważ potrzebowałem wszystkich serii papierów wartościowych, aby dokładnie się do siebie dopasować w analizie, którą wykonuję.

Na szczęście nadal istnieje ogólna struktura danych. Korzystanie z tego linku:

https://www.google.com/finance/getprices?i=1800&p=1000d&f=d,o,h,l,c,v&df=cpct&q=AAPL 

i zmieniając giełdowy na końcu daje ostatnich 50 dni dni sesyjnych w dniu 1 przyrostu/2-godzinowym. Znaczniki czasu POSIX, bardzo pomocnie zdekodowane przez @geektrader, pojawiają się w kolumnie datownika w odstępach 3-tygodniowych. Chociaż indeksy znaczników czasowych nie zawsze odpowiadają w dogodny sposób 1: 1 (prawie podejrzewam, że było to celowe ze strony Google'a), istnieje wzorzec. Na przykład w przypadku serii półgodzinnych, które obejrzałem w pierwszym dniu notowania z trzytygodniową inkrementacją, mają jednolite indeksy czasowe w okolicy 1:15. Może to być 1:13, 1:14, 2: 15 - wszystko zależy od zasobów. Nie jestem pewien, jakie są 14 i 15 pozycje: podejrzewam, że są one albo codziennymi podsumowaniami, albo informacją po godzinach. Chodzi o to, że nie ma spójnego wzoru, na którym można się zaciągnąć. Pierwszy znaczek w dniu szkolenia, niestety, nie zawsze zawiera dane otwarcia. To samo dotyczy ostatniego wpisu i danych zamknięcia. Odkryłem, że jedynym sposobem, aby dowiedzieć się, co faktycznie reprezentuje dane handlowe, jest porównanie liczb z serią na mapach Google. Po dniach bezskuteczności próbując dowiedzieć się, jak podważyć dane z mapy 1: 1, zdecydowałem się na strategię "ballpark". Zrobiłem dane APPL (bardzo duże wolumeny obrotu) i ustaliłem jego indeksy czasowe w ciągu każdego dnia handlowego jako wartości referencyjne dla całego rynku. Wszystkie dni miały co najmniej 13 inkrementów, co odpowiada 6,5 ​​godzinnemu handlowi, ale niektóre miały 14 lub 15. W tym przypadku po prostu obcięto, biorąc pierwsze 13 indeksów. Stąd użyłem pętli while, aby w zasadzie przejść przez pobrane dane każdego ticketa giełdowego i porównać jego indeksy czasowe w danym dniu szkoleniowym ze znacznikami czasowymi APPL. Zachowałem nakładkę, wypełniłem luki brakującymi danymi i wycinałem niepokrywające się części.

Brzmi jak zwykła poprawka, ale w przypadku niewielkich wolumenów z rzadkimi danymi transakcji istniały dosłownie dziesiątki specjalnych przypadków, które musiałem upiec i wiele danych do interpolacji. Mam pewne dziwaczne wyniki dla niektórych z tych, które wiem, że są nieprawidłowe. W przypadku dużych wolumenów, średnich i dużych spółek, rozwiązanie to działało doskonale: w większości przypadków seria była bardzo dobrze zsynchronizowana z danymi APPL i idealnie pasowała do ich profili Google Finance.

Nie ma możliwości obejścia faktu, że ta metoda wprowadza pewne błędy, i nadal potrzebuję dopracować metodę zapasowych małych spółek. To powiedziawszy, przesunięcie serii o pół godziny lub wypełnienie luki pojedynczym przyrostem czasu wprowadza bardzo niewielką ilość błędów w stosunku do ogólnego ruchu rynku i zapasów. Jestem pewien, że ten zestaw danych, który mam, jest "wystarczająco dobry", aby umożliwić mi uzyskanie trafnych odpowiedzi na niektóre pytania, które mam. Kupowanie tych rzeczy w celach komercyjnych kosztuje dosłownie tysiące dolarów.

Myśli lub sugestie?

+1

Interactive Brokers nie kosztuje tysięcy dolarów i możesz uzyskać dane śróddzienne dla tysięcy akcji, obligacji, kontraktów terminowych, opcji walutowych, opcji itp. Zobacz [Pakiet IBrokers] (https://code.google.com/p/ibrokers/source/checkout) i mój pakiet [twsInstrument] (https://r-forge.r-project.org/R/?group_id=1113). Inne przemyślenia: https://stat.ethz.ch/pipermail/r-sig-finance/2013q1/011417.html – GSee

+0

to wygląda dobrze. aby zaimplementować te pakiety, potrzebujesz konta ibrokers, prawda? w tej chwili jestem z optionshouse i będę musiał oprzeć się na moim rozwiązaniu, które pozwoli skreślić Google na krótką metę. spójny dostęp do danych w wysokiej rozdzielczości stanowi dla mnie kolejną zachętę do zmiany. – Aaron

+0

Tak, potrzebujesz konta IB. Uważam, że istnieje opłata za utrzymanie w wysokości od 10 do 20 USD miesięcznie, ale ta opłata nie zostanie naliczona, jeśli wydasz tyle samo w prowizji. – GSee

0

Dla strefy czasowej, spróbuj:

as.POSIXct (1357828200, pochodzenie = '1970-01-01', tz = Sys.timezone (location = TRUE))

(TZ będzie automatycznie dostosowuj się do Twojej lokalizacji)

+0

To stare pytanie z zaakceptowaną odpowiedzią. Czy możesz dodać, dlaczego twoja odpowiedź jest lepsza/inna? – Szeki

+0

To jest międzynarodowa odpowiedź. Nie trzeba dostosowywać się do stref czasowych w ramach funkcji as.POSIXct. (Dodając tz = Sys.timezone (location = TRUE)) – sempedocles

Powiązane problemy