GNU R – interpretowany język programowania oraz środowisko do obliczeń statystycznych i wizualizacji wyników. Jest to projekt GNU podobny do języka i środowiska S stworzonego w Bell Laboratories (dawniejsze AT&T, obecnie Nokia) przez Johna Chambersa i jego współpracowników. R jako implementacja języka S została stworzona przez Roberta Gentlemana i Rossa Ihakę na uniwersytecie w Auckland[2]. Nazwa pochodzi od pierwszych liter imion twórców oraz jest nawiązaniem do języka S. GNU R rozprowadzany jest w postaci kodu źródłowego oraz w postaci binarnej wraz z wieloma dystrybucjami GNU/Linuksa. Dostępna jest także wersja dla Microsoft Windows i Mac OS.
Obszary zastosowań [ edytuj | edytuj kod ]
R jest podstawowym językiem programowania w bioinformatyce, spopularyzowanym głównie dzięki stworzonemu przez Roberta Gentlemana repozytorium Bioconductor[3]. Artykuły Gentlemana o R i Bioconductorze[4] należą do najczęściej cytowanych w bioinformatyce (ponad 4000 cytowań według Google Scholar). R nadaje się do przeprowadzania analiz w badaniach klinicznych[5][6].
R jest wykorzystywany w wielu firmach, w tym m.in. Facebook, Google, Merck, Altera, Pfizer, LinkedIn, Shell, Novartis, Ford, Mozilla czy Twitter[7]. Producenci komercyjnych pakietów statystycznych (SPSS, SAS, RapidMiner, Statistica) oferują dedykowane mechanizmy zapewniające ich współpracę z R[8][9][10].
Kod źródłowy R opublikowany jest na zasadach licencji GNU GPL. Dostępne są prekompilowane binarne wersje dla systemów Windows, Macintosh i wielu systemów uniksowych.
Istnieje kilka graficznych interfejsów dla R, wśród nich wymienić można RKWard, SciViews-R, Rcmdr, RStudio, JGR, Statistical Lab oraz R Commander. Wiele edytorów ma specjalne tryby pracy dla R, np. Emacs (Emacs Speaks Statistics), jEdit, Kate, Visual Studio (Microsoft R Tools for Visual Studio) i Tinn. Jest także wtyczka R plug-in dla Eclipse.
R dostarcza szeroką gamę technik statystycznych (liniowe i nieliniowe modelowanie, klasyczne testy statystyczne, analiza szeregów czasowych, klasyfikacja, grupowanie,...) i graficznych. W dodatku R jest rozszerzalne za pomocą dodatkowych pakietów oraz skryptów pisanych przez użytkownika.
Jedną z mocnych stron R jest łatwość, z jaką można tworzyć dobrze zaprojektowane wykresy z jakością nadającą się do publikacji. Dotyczy to także symboli i formuł matematycznych. Wiele uwagi poświęcono minimalizacji wyborów, jakie musi wykonać użytkownik, nadając formę wykresowi. Mimo istnienia ustawień domyślnych użytkownik ma możliwość pełnej kontroli wykresu.
Przykładowe skrypty [ edytuj | edytuj kod ]
Histogram wygenerowany za pomocą kodu z przykładu 1.
Generowanie liczb losowych i wykreślenie histogramu
# generowanie 3000 liczb losowanych z rozkładu normalnego x
Podstawowe statystyki – w trybie interakcyjnym obliczane są proste statystyki dla danych w wektorze x wygenerowanym w poprzednim przykładzie
> summary ( x ) Min. 1 st Qu. Median Mean 3 rd Qu. Max. -3.47300 -0.71500 -0.04161 -0.02642 0.63570 3.05000 >
Podstawowe operacje:
Przypisanie to
> x x [ 1 ] 2 > y y [ 1 ] 1 7 10 > sin ( y ) [ 1 ] 0.8414710 0.6569866 -0.5440211 > 1 : 100 [ 1 ] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [ 19 ] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [ 37 ] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 [ 55 ] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 [ 73 ] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 [ 91 ] 91 92 93 94 95 96 97 98 99 100 > sin ( 1 : 100 ) + 3 [ 1 ] 3.841471 3.909297 3.141120 2.243198 2.041076 2.720585 3.656987 3.989358 [ 9 ] 3.412118 2.455979 2.000010 2.463427 3.420167 3.990607 3.650288 2.712097 [ 17 ] 2.038603 2.249013 3.149877 3.912945 3.836656 2.991149 2.153780 2.094422 [ 25 ] 2.867648 3.762558 3.956376 3.270906 2.336366 2.011968 2.595962 3.551427 [ 33 ] 3.999912 3.529083 2.571817 2.008221 2.356462 3.296369 3.963795 3.745113 [ 41 ] 2.841377 2.083478 2.168225 3.017702 3.850904 3.901788 3.123573 2.231745 [ 49 ] 2.046247 2.737625 3.670229 3.986628 3.395925 2.441211 2.000245 2.478449 [ 57 ] 3.436165 3.992873 3.636738 2.695189 2.033882 2.260819 3.167356 3.920026 [ 65 ] 3.826829 2.973449 2.144480 2.102072 2.885215 3.773891 3.951055 3.253823 [ 73 ] 2.323228 2.014854 2.612218 3.566108 3.999520 3.513978 2.555887 2.006111 [ 81 ] 2.370112 3.313229 3.968364 3.733190 2.823924 2.076542 2.178182 3.035398 [ 89 ] 3.860069 3.893997 3.105988 2.220534 2.051718 2.754748 3.683262 3.983588 [ 97 ] 3.379608 2.426618 2.000793 2.493634 > mean ( sin ( 1 : 100 ) + 3 ) [ 1 ] 2.998728 > var ( sqrt ( 80 : 1 )) [ 1 ] 4.359722
Regresja liniowa:
Zmiennej x przypisujemy wartości 1,2,..,10, natomiast zmiennej y wartości funkcji liniowej o współczynniku nachylenia 3 oraz stałej 5 plus błąd losowy o rozkładzie normalnym (średnia=0, odchylenie standardowe=1). Komenda lm(y~x) dopasowuje do wygenerowanych danych model regresji liniowej.
> x y summary ( lm ( y ~ x )) lm ( formula = y ~ x ) Residuals : Min 1 Q Median 3 Q Max -2.2687 -0.6058 0.1234 0.8704 2.0585 Coefficients : Estimate Std. Error t value Pr ( >| t | ) ( Intercept ) 4.6991 0.9836 4.778 0.00139 ** x 3.0101 0.1585 18.989 6.12e-08 *** --- Signif. codes : 0 `***' 0.001 ` ** ' 0.01 `*' 0.05 `.' 0.1 ` ' 1 Residual standard error : 1.44 on 8 degrees of freedom Multiple R - Squared : 0.9783 , Adjusted R - squared : 0.9756 F - statistic : 360.6 on 1 and 8 DF , p - value : 6.121e-08
Regresja logistyczna: Przykładowe dane:
y
Komenda glm(cbind(y,N-y)~x,family=binomial) dopasowuje do danych model regresji logistycznej. Wynik estymacji (w kolumnie Estimate jest logarytm OR czyli ilorazu szans):
Call : glm ( formula = cbind ( y , N - y ) ~ x , family = binomial ) Deviance Residuals : [ 1 ] 0 0 0 0 Coefficients : Estimate Std. Error z value Pr ( >| z | ) ( Intercept ) -2.9444 0.4588 -6.417 1.39e-10 *** x2 0.5021 0.5886 0.853 0.393606 x3 1.2098 0.5375 2.251 0.024407 * x4 1.8458 0.5137 3.593 0.000326 *** --- Signif. codes : 0 `***' 0.001 ` ** ' 0.01 `*' 0.05 `.' 0.1 ` ' 1 ( Dispersion parameter for binomial family taken to be 1 ) Null deviance : 2.0424e+01 on 3 degrees of freedom Residual deviance : -2.2871e-14 on 0 degrees of freedom AIC : 24.455 Number of Fisher Scoring iterations : 3
Polskie książki o R [ edytuj | edytuj kod ]
Wiele wskazuje na to, że CA-Clipper 5.2 doczeka się wreszcie następcy. Nowy system będzie nosić nazwę CA-Visual Objects for Windows - słowo Clipper w ogóle się w niej nie pojawi! Czym będzie ten program i jakiego języka będą musieli nauczyć się jego użytkownicy?
Wiele wskazuje na to, że CA-Clipper 5.2 doczeka się wreszcie następcy. Nowy system będzie nosić nazwę CA-Visual Objects for Windows - słowo Clipper w ogóle się w niej nie pojawi! Czym będzie ten program i jakiego języka będą musieli nauczyć się jego użytkownicy?
Nowy język jest potomkiem Clippera - podobieństwo rodzinne będzie niezaprzeczalne, ale różnicy pokoleń nie da się zignorować. Ponadto kompilator, debugger i edytor nie będą osobno wywoływanymi programami, ale wejdą w skład zintegrowanego środowiska programistycznego działającego pod kontrolą Windows. Tworzone programy też będą przeznaczone do pracy w tym systemie. Nadal będą działać na plikach DBF, ale będą również mogły współpracować z innymi bazami danych za pośrednictwem mechanizmów ODBC (coraz powszechniej stosowana konwencja komunikacji między bazami).
Język obiektowy
Język programowania systemu CA-Visual Objects zawiera pełny zestaw środków programowania obiektowego. Programista nie musi - tak jak w CA-Clipperze 5.2 - ograniczać się do generowania obiektów (zbiorów logicznie powiązanych danych i programów) należących do czterech gotowych klas, ale może zdefiniować swoje klasy. Nowe klasy mogą być definiowane na podstawie już istniejących, gdyż CA-Visual Objects dostarcza środków językowych umożliwiających dziedziczenie przez nową klasę metod (podprogramów związanych z obiektami) i zmiennych wyspecyfikowanych w klasie zdefiniowanej wcześniej.
Nowy język zawiera oryginalne rozwiązanie, wzmacniające ochronę wewnętrznej struktury obiektów i pozwalające ukryć techniczne szczegóły ich działania. Są to specjalne identyfikatory związane z obiektem, określane jako zmienne wirtualne. Pod względem składniowym są one nieodróżnialne od nazw pól danych, jednak ich użycie w instrukcji podstawienia automatycznie uruchamia dowiązane do nich podprogramy.
Interfejs z prefabrykatów
CA-Visual Objects służy do pisania programów dla Windows. Pojawiają się tu dwa problemy: tworzenie złożonego graficznego interfejsu użytkownika (GUI) z zachowaniem konwencji Windows oraz wykonanie sterowane zdarzeniami (event driven), tzn. uruchamianie odpowiednich podprogramów w momentach uzależnionych od działań użytkownika (przesunięcie kursora, wciśnięcie przycisku itp.) a nie od układu rozkazów w programie. Programowanie obiektowe wyjątkowo dobrze nadaje się do rozwiązywania tych problemów.
System jest wyposażony w duży wybór gotowych klas do obsługi interfejsu użytkowego (GUI). Zawiera struktury danych i podprogramy niezbędne do opisu współpracy z myszą, realizacji techniki drag-and-drop oraz koordynacji i "animacji" okien dialogowych, menus, browserów ("przeglądarek" - tabel podobnych do arkusza kalkulacyjnego), formatek i innych obiektów ekranowych.
Obiekty z których można budować programy sterowane zdarzeniami są zawarte w bibliotece CA-Common View. Zawiera ona także obsługę komunikatów o zdarzeniach generowanych przez użytkownika i Windows.
Nadmiar szczęścia
Dziedziczenie to mechanizm pozwalający na wielokrotne wykorzystanie raz zdefiniowanych algorytmów i struktur danych (code reuse). Przypuśćmy np. że działanie i strukturę prostego okienka edycji tekstu opisano w definicji klasy Edytor. Wyobraźmy sobie, że chcemy stworzyć edytor do pisania od prawej do lewej (eksport do Arabii Saudyjskiej?). W tym celu tworzymy definicję nowej klasy pochodnej od klasy Edytor, powiedzmy EdytorOdwracający. W definicji klasy pochodnej musimy opisać tylko algorytm rozmieszczania kolejnych wprowadzanych liter. Kompilator zakłada, że pozostałe akcje, których opis pominięto, są dziedziczone, tzn. mają przebiegać zgodnie z algorytmami opisanymi w definicji klasy podstawowej - w tym wypadku klasy Edytor.
Dziedziczenie pozwala uniknąć powielania kodu. Pamiętajmy jednak, że program użytkowy średniej wielkości może zawierać kilkadziesiąt definicji klas. Dlatego ważne jest, aby znalezienie fragmentu kodu było łatwiejsze niż jego powtórne napisanie, aby programista miał kontrolę nad zależnościami łączącymi poszczególne fragmenty programu i wreszcie - aby panował nad zjawiskiem propagacji zmian, w efekcie którego np. modyfikacja wprowadzona w klasie Edytor rzutuje na działanie klasy EdytorOdwracający, a także na działanie wszystkich innych klas pochodnych.
Kolejne wyzwanie stanowią składniki interfejsu graficznego - wewnętrznie złożone "zlepki" kodu, zmiennych i elementów graficznych, zwykle uzależnione od struktury i zawartości obsługiwanej bazy danych, wzajemnie powiązane siecią zmiennych relacji funkcjonalnych, geometrycznych i logicznych. Ich złożoność bardzo utrudnia utrzymanie stałej kontroli nad strukturą większych programów. Wydruki, notatki i edytor tekstowy już nie wystarczają.
Edytory i browsery
Aby umożliwić utrzymanie kontroli nad kodem programów o narastającej złożoności, producent wyposażył system CA-Visual Objects w graficzne środowisko wspomagania programisty (IDE) oraz w system określany jako składnica lub repozytorium (repository).
Środowisko programisty zawiera - obok kompilatora i debuggera - edytory i tzw. browsery. Browser jest to interakcyjne narzędzie, zwykle w postaci tabeli lub drzewa napisów, umożliwiające użytkownikowi przegląd dużych zbiorów jakichkolwiek elementów opatrzonych nazwami. Norton Commander jest przykładem prostego browsera do przeglądu plików i katalogów. Browsery w CA-Visual Objects służą do przeglądania aplikacji i ich składników.
Edytory środowiska CA-Visual Objects umożliwiają nie tylko działania na tekstach źródłowych, ale także graficzne opracowywanie okien, menu i formatek specyfikacji pól (kolumn) baz danych. W skład środowiska wchodzi też interakcyjny graficzny generator raportów CA-RET. System umie przetworzyć graficzne i tabelaryczne projekty elementów interfejsu utworzone pod kontrolą edytorów na fragmenty tekstu źródłowego, które przy użyciu edytora tekstowego podlegają dalszej obróbce.
CA-Visual Objects jest wyposażony w browsery zapewniające dostęp do aplikacji, klas, modułów i tzw. jednostek (entities), tzn. okien, menu, raportów, definicji zmiennych, struktur (rozumianych podobnie jak w języku C), funkcji oraz specyfikacje pól w bazach danych. Browser klas wyświetla ich nazwy w postaci drzewa, którego struktura odpowiada hierarchii klas podstawowych i pochodnych. Kliknięcie myszką na powierzchni nazwy w oknie browsera powoduje wyświetlenie wskazanego elementu pod kontrolą odpowiedniego edytora.
Repozytorium
Repozytorium (albo inaczej składnica) jest to podsystem środowiska IDE współpracujący z jego interfejsem graficznym oraz wyposażony w wewnętrzną bazę danych, w której są przechowywane wszystkie elementy wyświetlane przez browsery i edytory. Jej zawartość jest dostępna tylko za ich pośrednictwem.
Repozytorium można opisać jako zautomatyzowany i rozbudowany odpowiednik tzw. make-files (znanych m.in. z C i Clippera) oraz obsługujących je programów narzędziowych, gdyż przechowuje ono informacje o powiązaniach między składowymi programów i jest odpowiedzialne za nadzorowanie i aktualizację tych informacji oraz - częściowo - za spójność definicji przechowywanych składników.
Repozytorium współpracuje z kompilatorem zlecając mu przy zmianie składnika programu - np. deklaracji zmiennej - powtórną kompilację wszystkich fragmentów zależnych od zmienionego składnika - np. wszystkich podprogramów wykorzystujących przedefiniowaną zmienną. Wspomniany już podział aplikacji na małe jednostki (entities) umożliwia bardzo oszczędne działanie repozytorium, określone przez zasadę minimalnej rekompilacji: powtórna kompilacja dotyczy tylko tych jednostek, które zawierają odwołanie do zmienionego składnika zwykle są one mniejsze od aplikacji, a nawet modułu.
SQL, serwery, drajwery ...
Visual Objects standardowo działa na plikach o tradycyjnym formacie clipperowym (DBF z indeksami NTX). Dostęp do innych baz jest możliwy dzięki wbudowanym mechanizmom wykorzystującym pośrednictwo ODBC (Open Data Base Connectivity) oraz tzw. wymiennym drajwerom baz danych - RDD (Replaceable Database Drivers). Obok standardowego drajwera "rozumiejącego" pliki indeksowe NTX producent ma dostarczać (w cenie pakietu przynajmniej dwa dodatkowe: do indeksów NDX (dBase III) i MDX (dBase IV).
RDD są to biblioteki DLL utworzone przez CA bądź innych producentów, zawierające funkcje najniższego poziomu obsługi baz danych. Wszystkie instrukcje manipulacji danymi są tłumaczone na ich wywołania, dlatego funkcje te muszą być opatrzone nazwami zdefiniowanymi przez CA i rozumianymi przez CA-Visual Objects. Obok funkcji każdy RDD powinien zawierać tablicę z ich adresami. Biblioteki RDD mogą tworzyć hierarchię - jeśli w tablicy na pozycji przypisanej konkretnej funkcji znajduje się adres zerowy, to system szuka adresu na tej samej pozycji w drajwerze kolejnego poziomu.
Zasady działania baz relacyjnych (SQL) są inne niż baz Clippera, dBase itp., określanych nieraz jako nawigacyjne. Aby ułatwić programistom czytelny zapis operacji na bazach obu typów, Computer Associates wyposażyła swój produkt w gotowe klasy obiektowe nazywane serwerami danych (data servers). Obiekty tych klas współpracują z drajwerami RDD. Wywołania metod realizowanych przez serwery klasy SQLSelect mają postać formuł języka SQL, a metody klasy DBServer są bardzo zbliżone do funkcji Clippera 5.2.
To wszystko może brzmieć niepokojąco dla użytkowników Clippera przyzwyczajonych do korzystania z tradycyjnych konstrukcji tego języka, pochodzących z wersji Summer 87 albo nawet z dBase'a III. Czy będą mogli korzystać z CA-Visual Objects nie zmieniając z dnia na dzień swoich przyzwyczajeń? I czy będą mogli w miarę szybko przenieść stare aplikacje pod nowy system? Raczej tak.
... a co z normalnym SAY-GET?
Mimo unowocześnienia języka tradycyjne konstrukcje nie będą z niego usunięte. Komendy pamiętające jeszcze czasy dBase'a będą, podobnie jak w wersji 5.2, dostępne dzięki plikowi nagłówkowemu z definicjami przeznaczonymi dla preprocesora. Możliwe będzie programowanie hybrydowe, łączące SQL z funkcjami Clippera 5.2 lub z ich wersjami obiektowymi.
Kolejna dobra (?) wiadomość: programowanie z użyciem tradycyjnych Xbase'owych konstrukcji składniowych (np. @...SAY...GET) jest możliwe dzięki obiektom emulującym terminal alfanumeryczny. Obiekty te są zaszyte na tyle głęboko (konkretnie: poniżej warstwy definicji preprocesora), że można z nich korzystać nie wiedząc o ich istnieniu.
Obok obiektów i SQL pojawią się dwie kolejne nowości: zmienne o typie ustalanym raz na zawsze w momencie deklaracji i struktury (zbliżone do struktur w języku C), czyli zmienne złożone z pól o różnej wielkości opatrzonych nazwami, rezydujące w pamięci operacyjnej. Ci programiści, którzy nie przepadają za deklarowaniem zmiennych i ścisłą kontrolą typów przez kompilator mogą jednak programować "po staremu".
Nowy kompilator ma działać znacznie szybciej od starego. Zawdzięcza to zupełnie innej (chociaż wcale nie nowatorskiej) konstrukcji. Instrukcje będą tłumaczone bezpośrednio na kod maszynowy. Jeszcze w wersji 5.2 używano translatora generującego kod pośredni, wymagający interpretacji w trakcie wykonania.
Mamy pomysł, który został odpowiednio przeanalizowany pod względem użyteczności oraz priorytetów. Co dalej? Należy się zastanowić, czy realizujemy go czy nie. Pytanie może wydawać się zupełnie idiotyczne, no bo jak to… mam pomysł i nie realizuję go? Jak podają eksperci, firmy odnoszące największe sukcesy odrzucają większość początkujących projektów. Dlaczego tak się dzieję? No cóż, nie ma się co łudzić, że pewnego dnia wstaniemy i wpadniemy na genialny pomysł, który zrewolucjonizuje podbije świat. Takie pomysły potrzebują czasu aby można je było określić. Czasem kilka innych pomysłów nakieruje nas małymi kroczkami na ten jeden, jedyny słuszny. Zobaczcie co robi Google, jak wieść gminna niesie, programiści są zobligowani do spożytkowania 20% czasu pracy na pracę nad własnymi projektami. Co więcej z tych projektów są rozliczani (czy rzeczywiście coś robili). Co się dzieje z tymi projektami dalej? Przecież to mogą być zupełnie niepotrzebne rzeczy, które nawet nie pasują do polityki firmy. Takie projekty są weryfikowane i w większości odrzucane jednak mały procent z nich wchodzi do „produkcji”, stają się rozwijane i upubliczniane. Tak stało się między innymi z listą zadań w gmail-u. Dlatego namawiam Cię do spisywania swoich pomysłów, analizowania ich i odrzucania tych, które są bez przyszłości. Małymi kroczkami dojdziesz do tego jednego upragnionego Grala. Być może to będzie coś na miarę Skype-a lub Facebook-a a może coś mniejszego ale dającego twórcy – Tobie – satysfakcję.
Wracając do mojego projektu. Odpowiedź na pytanie o realizację zawarłem poniekąd w poprzednim poście. Więc sprawa jest prosta. Realizuję. W tym celu należy przygotować sobie środowisko pracy. Dopiero tutaj proponuję zastanowić się nad technologią.
Dlaczego dopiero tutaj? Dlatego aby nie mieszać pomysłu na software z jego implementacją. Jeśli mamy skrystalizowany pomysł, jeśli będziemy wiedzieli co chcemy uzyskać i jak ma to „coś” pracować, łatwiej będzie nam wybrać technologię (jeśli mamy taki wybór). W moim wypadku technologia wynika bezpośrednio z chęci jej poznania a nie z potrzeby stworzenia komercyjnej aplikacji, która będzie dostępna dla milionów użytkowników. Gdyby ta aplikacja miała być dostępna szeroko to pewnie poszedł bym w kierunku C++ oraz WinAPI, tutaj jednak priorytety są trochę inne.
Środowisko pracy czyli co będziemy potrzebować:
Narzędzie programistyczne Narzędzia zwiększające możliwości wybranego narzędzia programistycznego Repozytorium źródeł Automatyczna kompilacja Miejsce przechowywania zadań do wykonania oraz informacji o błędach Miejsce do publikacji wersji ….
Listę pozostawiam otwartą bo być może macie sugestie odnośnie tego co jeszcze może być przydatne.
Jak ta lista wygląda w przypadku DesktopInfo
Leave a Comment