Dane w formacie R¶

Wsparcie plików R (R.Data) zostało dodane w DVN 3.5.

Zawartość:

Uwagi ogólne
Wymagania dotyczące formatowania danych
Typy danych a inne obsługiwane formaty (Stata, SPSS)
Wartości czasu w R

Uwagi ogólne ¶

R cieszy się coraz większą popularnością w środowisku badaczy i świecie akademickim. Jest to bezpłatne oprogramowanie o otwartym kodzie źródłowym (w przeciwieństwie do pakietów SPSS i STATA). W związku z tym rośnie ilość danych dostępnych wyłącznie w formacie R.

Wymagania dotyczące formatowania danych ¶

Dane muszą być sformatowane jako ramka danych programu R (data.frame()). Aktualnie jeśli plik .RData zawiera wiele ramek danych, przeanalizowana zostanie tylko pierwsza z nich.

Typy danych a inne obsługiwane formaty (Stata, SPSS)¶

Typy Integer, Double oraz Character ¶

Obsługa tych typów jest intuicyjna i prosta. Powstałe kolumny pliku TAB, miary rozkładu i sygnatury UNF powinny być identyczne z tymi, które powstały w wyniku przetworzenia tych samych wektorów z plików w formatach SPSS i Stata.

Rzeczy unikalne dla R:

R umożliwia bezpośrednią obsługuję brakujących wartości (Missing Values) dla wszystkich powyższych typów. Brakujące wartości zakodowane w wektorach R zostaną rozpoznane i zapisane w plikach TAB, uwzględnione w wygenerowanych miarach rozkładu i analizie danych. Należy jednak pamiętać, że Dataverse dla oznaczenia brakującej wartości, przechowuje w pliku TAB pusty ciąg znaków, podczas gdy w R w tym samym celu używane jest „NA”.

Oprócz brakujących wartości, R dla wartości zmiennoprzecinkowych rozpoznaje również oznaczenie NaN oraz dodatnią i ujemną nieskończoność. Obecnie są one poprawnie obsługiwane przez Dataverse.

Trzeba też zauważyć, że w przeciwieństwie do formatu Stata, który traktuje liczby zmiennoprzecinkowe typu „float” oraz typu „double” jako odrębne typy danych, wszystkie wartości zmiennoprzecinkowe w R są typu „double”.

Typ Factor w R ¶

W Dataverse typ Factor języka R jest traktowany jak zmienna kategorialna.

Należy pamiętać o tym, że zarówno w programie Stata, jak i w SPSS, wartość zmiennej kategorialnej może być zarówno ciągiem znaków, jak i mieć charakter numeryczny. W R natomiast wszystkie wartości typu Factor są łańcuchami znaków, nawet jeśli reprezentują one liczby. Zatem również wartości wynikowe typu Factor w Dataverse zawsze będą ciągami znaków.

Należy również zauważyć, że typ Factor w R nie ma wbudowanej obsługi etykiet opisowych typu SPSS lub STATA. Jest to potencjalnie mylące, ponieważ w języku R również używane jest słowo „etykieta” („label”). Jednak w kontekście typu Factor w języku R nadal odnosi się do treści danych. Np. przy tworzeniu zmiennej typu Factor z „etykietami” opisującymi poparcie dla określonych partii politycznych, np. „demokrata”, „republikanin”, „niezdecydowany”, te ciągi stają się rzeczywistymi wartościami wynikowego wektora. W Dataverse wartości te zostaną zapisane w pliku rozdzielanym tabulatorami. Obiekt Dataverse DataVariable reprezentujący wektor będzie typu „Character” i będzie zawierał 3 obiekty VariableCategory („demokrata”, „republikanin” etc.) zarówno w przypadku CategoryValue, jak i CategoryLabel.

Wartości logiczne ¶

Wartości boolowskie (logiczne) są obsługiwane.

Ograniczenia R w porównaniu do SPSS i STATA ¶

Najbardziej zauważalną cechą R jest to, że nie ma on standardowego mechanizmu do definiowania opisowych etykiet dla zmiennych w postaci ramki danych. W Dataverse, podobnie jak w Stata i SPSS, zmienne mają różne nazwy i etykiety; etykiety zastrzeżone są dla dłuższego, opisowego tekstu. W przypadku zmiennych pobieranych z ramek danych R nazwa zmiennej będzie używana zarówno dla „nazwy”, jak i „etykiety”.

Istnieją opcjonalne pakiety R umożliwiające stosowanie opisowych etykiet zmiennych; w jednej z przyszłych wersji można dodać obsługę takiego mechanizmu. Oczywiście działałoby to tylko dla plików R, które zostały utworzone za pomocą takich opcjonalnych pakietów

Podobnie wartościom kategorialnym R (zmiennym typu „factor”) również brakuje opisowych etykiet. Uwaga: Jest to potencjalnie mylące, ponieważ zmienne typu factor w R w rzeczywistości mają „etykiety”. Jest to kwestia terminologii - etykieta w ich przypadku jest w rzeczywistości tym samym, co „wartość” zmiennej kategorialnej w SPSS, Stata czy Dataverse; zawiera rzeczywiste, znaczące dane dla danej obserwacji. NIE jest to pole zarezerwowane dla tekstu objaśniającego, czytelnego dla człowieka, tak jak w przypadku „etykiety” SPSS/Stata.

Analiza zmiennej typu „factor” w R z etykietami poziomu „MALE” (mężczyzna) i „FEMALE” (kobieta) spowoduje utworzenie zmiennej kategorialnej z „MALE” i „FEMALE” zarówno w wartościach, jak i etykietach.

Wartości czasu w R ¶

Sekcja została wydzielona ze względu na unikatowy sposób obsługi czasu w języku R.

R stara się traktować wartość czasu jako instancję czasu rzeczywistego. Odmienne podejście spotkać można w programach SPSS i Stata, gdzie dopuszcza się reprezentacje wartości czasu takie jak np. „Sep-23-2013 14:57:21”. Należy zauważyć, że przy braku wyraźnie określonej strefy czasowej tej wartości nie można dokładnie odwzorować na punkt w czasie rzeczywistym. R obsługuje czasy w sposób „Unix’owy”: wartość jest konwertowana na czas Greenwich (GMT lub UTC) wyrażony w sekundach od początku epoki Unix’a, a wynikowa wartość liczbowa jest przechowywana w pliku danych; w razie potrzeby dostosowuje się strefę czasową w czasie rzeczywistym.

Sprawa staje się niejednoznaczna i myląca, gdy R wyświetla tę wartość czasu: jeżeli strefa czasowa nie została jawnie zdefiniowana, R dostosuje wartość do bieżącej strefy czasowej. Wynik jest często sprzeczny z intuicją: jeśli utworzysz wartość czasu, np.:

timevalue <-as.POSIXct("03/19/2013 12:57:00", format = "%m/%d/%Y %H:%M:%OS");

na komputerze ze skonfigurowaną strefą czasową dla San Francisco, wartość będzie różnie wyświetlana na komputerach w innych strefach czasowych; na przykład na Zachodnim Wybrzeżu jako „12:57 PST”, ale jako „15:57 EST” w Bostonie.

Jeśli ważne jest, aby wartości były zawsze wyświetlane w ten sam sposób, niezależnie od bieżących stref czasowych, zaleca się jawne zdefiniowanie strefy czasowej. Można to zrobić w następujący sposób:

attr(timevalue,"tzone")<-"PST"

lub

timevalue<-as.POSIXct("03/19/2013 12:57:00", format = "%m/%d/%Y %H:%M:%OS", tz="PST");

Teraz wartość będzie zawsze wyświetlana jako „15:57 PST”, niezależnie od strefy czasowej systemu operacyjnego, na którym jest wyświetlana… ALE TYLKO jeśli system operacyjny, na którym zainstalowany jest R, faktycznie poprawnie interpretuje strefę czasową „PST”, czego nie można zagwarantować! W przeciwnym razie system po cichu dostosuje zapamiętaną wartość GMT do bieżącej strefy czasowej, ale nadal wyświetli ją z dołączonym znacznikiem „PST”! Innymi słowy, R dobrze się sprawdza przechowując wartości czasu w jednoznaczny i niezależny od platformy sposób, ale nie daje żadnej gwarancji, że wartości te będą wyświetlane w sposób przewidywalny lub intuicyjny.

Zaleca się stosowanie długich/opisowych form stref czasowych, jako że zwiększa to prawdopodobieństwo ich poprawnego odczytania na większości komputerów. Na przykład lepiej jest posłużyć się zwrotem „Japan” zamiast „JST”. Innym możliwym rozwiązaniem jest stosowanie GMT lub UTC (jest bardzo prawdopodobne, że zostaną poprawnie rozpoznane przez dowolny system) lub notacji UTC+<PRZESUNIĘCIE>. Nadal jednak żadne z powyższych rozwiązań nie gwarantuje poprawnej, jednoznacznej obsługi wartości czasu w danych R. Dość kłopotliwe jest to, że R po cichu modyfikuje wartości czasu, gdy nie rozpoznaje podanego atrybutu strefy czasowej, ale nadal dołącza go do zmienionej w ten sposób wartości czasu. (Zagadnienia te są szczegółowo omawiane na forach związanych z językiem R, w tym miejscu nie podejmujemy się próby ich podsumowania. Chodzi jedynie o to, by zdać sobie sprawę, że jest to złożony problem!).

Jeśli chodzi o sposób analizy plików R przez Dataverse, należy pamiętać, że odrzucony zostanie plik R z wartościami czasowymi, których strefy czasowe nie zostaną rozpoznane. Dzieje się tak, aby uniknąć (niektórych) potencjalnych problemów opisanych powyżej.

Zaleca się również przejrzenie wszystkich wektorów zawierających wartości czasowe przetworzonych przez Dataverse, a także porównanie wyników otrzymanych w plikach TAB z oryginalnymi wartościami w ramce danych R, aby upewnić się, że zostały one przetworzone zgodnie z oczekiwaniami.

Innym potencjalnym problemem jest UNF. Sposób działania algorytmu UNF sprawia, że te same wartości daty/godziny ze strefą czasową i bez niej (np. „12:45” i „12:45 EST”) prowadzą do różnych wartości UNF. Biorąc pod uwagę, że wartości czasu w Stata/SPSS nie mają stref czasowych, ale WSZYSTKIE wartości czasu w R je mają (tak, wszystkie – jeśli strefa czasowa nie została jawnie zdefiniowana, domyślnie przyjmuje się wtedy strefę UTC!). Oznacza to, że niemożliwe jest posiadanie 2 wektorów wartości czasowych, w Stata/SPSS i R, które dawałyby ten sam UNF.

Sugestia: jeśli ważne jest utworzenie wersji SPSS/Stata i R tego samego zbioru danych, które po przetworzeniu dadzą to samo UNF, można zdefiniować zmienne czasowe jako ciągi w ramce danych R i zastosować notację formatującą YYYY-MM-DD HH: mm: ss. Jest to formatowanie stosowane przez algorytm UNF do normalizacji wartości czasu, więc wykonanie powyższego działania pozwoli uzyskać ten sam UNF co w przypadku wektora tych samych wartości czasu w programie Stata.

Uwaga: wartości daty (tylko daty, bez czasu) powinny być obsługiwane dokładnie tak samo, jak w programach SPSS i Stata, i powinny generować te same UNF.