529 / 736OHLCV

OHLCV

Otwarcie, maksimum, minimum, zamknięcie i wolumen określonego przedziału

Jana otwiera wykres bitcoina i zamiast długiej listy transakcji widzi świece. Każda streszcza pewien okres: od jakiej ceny się zaczął, jak wysoko i nisko cena dotarła, gdzie się zakończył i ile przehandlowano. To podsumowanie nazywa się OHLCV. Ułatwia zrozumienie przeszłości, ale nie zachowuje całego przebiegu handlu.

OHLCV oznacza Open, High, Low, Close i Volume: pierwszą cenę transakcji, najwyższą, najniższą, ostatnią oraz wolumen obrotu w danym przedziale. Dane dotyczą konkretnego rynku i okresu. Opisują zawarte transakcje, nie oferty, po których można kupić właśnie teraz.

Jana najpierw wybiera giełdę, parę i przedział czasu. Para mówi, co wymienia się na co, na przykład bitcoin na dolary. Kraken określa Open jako cenę pierwszej transakcji, a Close jako cenę ostatniej w przedziale. High i Low to osiągnięte maksimum i minimum. Jana widzi więc zakres oraz zmianę między początkiem a końcem bez czytania każdej transakcji. Żadna z tych cen nie jest automatycznie średnią ani aktualną ofertą w księdze zleceń. [1]

Oprócz ruchu ceny Janę interesuje, ile rzeczywiście przehandlowano. Kraken podaje Volume w aktywie bazowym pary, czyli dla BTC/USD w bitcoinach. Binance rozróżnia też wolumen w aktywie kwotowanym, tutaj dolarach, i osobno liczbę transakcji. Ilość bitcoinów, ich wartość w dolarach i liczba wykonań to różne wielkości. Duża liczba bez jednostki nie mówi, jak aktywny był rynek; najpierw trzeba wiedzieć, co liczy źródło. [1] [2]

Jana znajduje gdzie indziej inną świecę dzienną i podejrzewa błąd. Zanim wyciągnie wniosek, powinna porównać granice czasowe. Binance pozwala określać przedziały parametrem strefy timeZone, lecz startTime i endTime służące do wyboru danych nadal interpretuje w UTC, wspólnym światowym standardzie czasu. Doba zaczynająca się w innym momencie może zawierać inne transakcje. Samo słowo dzienny nie wystarcza: rynek, okres i znaczenie znacznika czasu muszą się zgadzać. [2]

Na wykresie na żywo najnowsza świeca potrafi zmieniać się na oczach czytelnika. Interfejs REST Kraken, przez który programy żądają danych, zawsze obejmuje bieżący, jeszcze niezakończony przedział. Jego Close oznacza na razie ostatnią znaną transakcję, nie ostateczne zamknięcie; wolumen również może rosnąć. Porównując zamknięte okresy, Jana musi odróżnić tę świecę w budowie. Inaczej zestawia zakończoną historię z dopiero powstającą wartością. [3]

Czasem w szeregu brakuje przedziału. Coinbase ostrzega, że historia może być niepełna, i nie publikuje świec dla okresów bez zdarzeń handlowych. Jana nie może więc uznać pustego miejsca za spadek ceny do zera. Najpierw musi ustalić, czy nie zawarto transakcji, czy brakuje danych. Przeniesienie poprzedniej ceny także nie tworzy nowej transakcji; jeśli wykres tak uzupełnia lukę, ta modyfikacja powinna być rozpoznawalna. [4]

Programowanie wykresu kryje kolejną pułapkę: skrót OHLCV nie gwarantuje kolejności pól odpowiedzi. Coinbase wymienia czas, Low, High, Open, Close i Volume. Kraken oddziela ponadto liczbę transakcji i VWAP, średnią cenę ważoną przehandlowaną ilością. Program musi odczytywać każde pole zgodnie z dokumentacją danego interfejsu. Zamiana wartości nie zawsze widocznie psuje wykres; może dać wiarygodnie wyglądającą krzywą o błędnym znaczeniu. [4] [1]

Z definicji Kraken można też wyprowadzić poprawną metodę łączenia przedziałów. Mając kompletne, kolejne i niepokrywające się okresy tego samego rynku, Jana bierze pierwsze Open i ostatnie Close. Dla High wybiera najwyższe maksimum, dla Low najniższe minimum, a porównywalne Volume sumuje. Średnia cen otwarcia dałaby coś innego. Najpierw trzeba sprawdzić chronologię, duplikaty i luki; sumowanie nie odzyskuje brakujących transakcji. [1]

Pola podsumowania Coinbase nie zachowują całej kolejności transakcji ani oczekujących ofert w księdze. Świeca może pokazać wysokie i niskie ceny, ale nie powie, które wystąpiły wcześniej. Gdy Jana sprawdza hipotetyczne zlecenie na danych historycznych, samo High i Low nie dowodzi kolejności dotknięcia progów ani rzeczywistego wykonania. OHLCV to przydatny obraz przeszłości, nie zamiennik szczegółowych zapisów lub potwierdzenia własnego zlecenia. [4]

Przykład · OHLCV

Jak Jana podsumowuje transakcje

W fikcyjnym zamkniętym przedziale kolejno przehandlowano 0.01 BTC po 100000 USD/BTC, 0.02 BTC po 100020 USD/BTC, 0.01 BTC po 99980 USD/BTC i na końcu 0.03 BTC po 100010 USD/BTC. Jana przyjmuje pierwszą cenę jako Open 100000, najwyższą jako High 100020, najniższą jako Low 99980, a ostatnią jako Close 100010, wszystkie w USD/BTC. Suma ilości daje Volume: 0.01 + 0.02 + 0.01 + 0.03 = 0.07 BTC. Wiersz szybko pokazuje zakres i łączną ilość, ale już nie ujawnia, że maksimum wystąpiło przed minimum. To nie są ceny na żywo ani gwarancja wykonania zlecenia Jany po tych cenach.

Pełniejszy obraz uzyskasz, czytając to hasło razem z Candlestick chart, Timeframe, Technical analysis, Order book, Backtesting, Volume weighted average price. Do tego hasła prowadzą również odsyłacze z Technical analysis, Timeframe, Candlestick chart, Simple moving average.

01Czy kolejne Open musi być równe poprzedniemu Close?

Nie. Kolejne Open to pierwsza rzeczywista transakcja nowego przedziału, nie obowiązkowa kopia starej ceny. Transakcje mogą następować po innej cenie, po przerwie w handlu lub z luką danych pomiędzy nimi.

02Czy odtworzę wszystkie transakcje z OHLCV?

Nie. Różne sekwencje mogą dać te same ekstrema, otwarcie, zamknięcie i wolumen. Do poznania kolejności potrzebne są dokładniejsze zapisy, a do oceny własnego zlecenia także dostępne oferty i reguły realizacji.

DOC · 001Kraken — WebSocket OHLCDokumentacja DOC · 002Binance — Spot Market DataDokumentacja DOC · 003Kraken — REST OHLCDokumentacja DOC · 004Coinbase — Product CandlesDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna