Beste antwoord
Ik heb de overstap gemaakt van stata naar R. Hier zijn mijn observaties:
Voordelen:
- R is open source, je hebt toegang tot een aantal echt coole geavanceerde algoritmen of software die mensen hebben geschreven voor nicheproblemen.
- R heeft betere visualisaties. Zodra je ggplot2 goed onder de knie hebt, kun je behoorlijk verbazingwekkende dingen met bijna elk type data.
- Ik heb R gemakkelijker gevonden voor het schrijven van aangepaste pakketten en functies.
- R staat dichter bij de gemeenschap voor stats / machine learning, dus je zult “meer ondersteuning / pakketten vinden dan stata.
- Ik ben dol op de RStudio Gui, vooral wanneer ik op een server werk.
- R biedt betere latexondersteuning.
- R heeft een zeer actieve gemeenschap en hulplijsten – ze hebben verbazingwekkend snel geholpen met al mijn vragen.
- R werkt met Big Data! Met het RHadoop-pakket kun je aangepaste MapReduce-scripts schrijven met behulp van R-functies. Als je ooit met big data te maken hebt en alleen Stata kunt gebruiken, ben je verpest.
- Er zijn meestal veel meer “hacks” in R voor gecompliceerde problemen zoals netwerkanalyse, aangepaste bootstraps, enz. Zodra je afstand neemt van vanille-implementaties, heb ik vaak sneltoetsfuncties gevonden in procedures in R, terwijl je in Stata vaak je weg naar buiten moet coderen.
Nadelen:
- R is open source, het kan zijn dat u een tijdje moet wachten om toegang te krijgen tot nieuwe algoritmen als er geen actieve ontwikkeling is.
- Stata staat veel dichter bij de econometrische gemeenschap en heeft veel meer algoritmen, pakketten en implementaties dan R. Als u een econoom bent, zult u gefrustreerd raken door het gebrek aan volledigheid van de econometrische pakketten.
- Stata heeft een geweldige GUI waarmee je interactief de procedure kunt kiezen die je wilt uitvoeren en de meeste details voor je kunt invullen. Dit is geweldig als je een functie gebruikt die je nog nooit eerder hebt gebruikt. R heeft dit niet echt – ik heb het gevoel dat wanneer ik R gebruik, ik de helft van de tijd op Google zit.
- Stata is sneller dan R [1].
- Het downloaden van statamodules is een veel meer gestroomlijnd proces Voor R-modules in CRAN is er meestal geen probleem (hoewel ik in de problemen kom als ik een Centos-machine gebruik), maar er zijn verschillende essentiële pakketten die niet op CRAN staan.
- De standaardvisualisatie en plotten van Stata is veel beter dan R.
- Stata heeft betere standaardhulp – ik heb het gevoel dat ik de hulp bij elke functie kan lezen en er precies achter kan komen wat ik moet doen terwijl ik dat niet zo voel voor verschillende R-pakketten die slecht gedocumenteerd zijn.
- R heeft een “WTF” -syntaxis en pakketnaamgevingsstructuur. De meeste open source-projecten doen dat. Ik mis de eenvoud van statafuncties (reg, lm, etc.).
[1] http://ekonometrics.blogspot.com/2011/04/speeding-tickets-for-r-and-stata.html
Antwoord
In het algemeen, als ik het bijwoord ” duidelijk “in een zin vind ik een of andere ongegronde verklaring die erop volgt. Hier ben ik het niet eens met uw bewering dat R “een bizarre syntaxis” heeft. Elke geschoolde programmeur zou het liefst coderen in Haskell of in een of andere Lisp, maar feit is dat deze talen nooit een groot publiek zullen bereiken. R is een Lisp van binnen (je kunt bijvoorbeeld eigenlijk coderen op de taal in R, maar niet in Python), maar komt dicht genoeg bij een wetenschappelijke taal buiten. In feite, zoals u opmerkt, als taal voor gegevensanalyse , is R eigenlijk de meest natuurlijke en elegante taal die er is. Als je hiervan bewijs wilt, bekijk dan de activiteit rond Python en Julia: implementatie van dataframes (pandas en data.frame in Jlia), formules (patsy), plyr (pandas). En toch voelen al deze kenmerken nog steeds enigszins geënt op de andere talen. Wat mensen als “bizar” of “wankel” ervaren, is ofwel het resultaat van concessie aan interactief gebruik (bijv. Afnemende dimensie), of van het functionele erfgoed van de taal.
Ik ben het ermee eens dat R veel gebieden die moeten worden verbeterd, maar meestal niet in de taalsyntaxis. Zeker, de naamgevingsconventies zijn inconsistent; snelheid en geheugenbeheer zijn bekende problemen; enzovoort. Waarom is dat? Een paar redenen:
- De hoofdrichtlijn van R (volgens de maker, John Chambers) is om betrouwbare software te produceren. R hecht veel waarde aan nauwkeurigheid en betrouwbaarheid. De belangrijkste statistische functies zijn van topklasse; zelfs het grafische basissysteem is zorgvuldig uitgedacht, van histogrambinning (geen triviaal probleem!) tot tekstplaatsing. Snelheid is nooit een grote zorg geweest, en terecht. Als snelheid en geheugenefficiëntie het probleem waren, coderen we allemaal in FORTRAN, dat ook gemakkelijk en hoogstaand is. De broncode van R-base is kort (400K LOCs; ter vergelijking: Numpy alleen heeft dezelfde grootte) en zeer leesbaar Code die u kunt begrijpen en vertrouwen.
- Splus en R werden bedacht in de jaren 80 en 90, ruim voor het tijdperk van “big data” en de opkomst van machine learning. Maar R is verbeterd. Geheugenbeheer is veel beter, waarschijnlijk superieur aan MATLABs. Het heeft nog een lange weg te gaan, maar bepaalde dingen kunnen worden verbeterd (bijv. Interne gegevensweergave).
- Het kernontwikkelingsteam heeft een minimaal verloop en de jonge programmeurs van 15 jaar geleden zijn nu in de vijftig. Bovendien zijn ze veel minder betrokken bij de gemeenschap en hebben ze een pittoresk / mythisch personage als Brian Ripley: een professor uit Oxford die verantwoordelijk is voor meer dan 70\% van de commits, en niet de vriendelijkste persoon ter wereld en op mailinglijsten van R.
- R smeekt om een snelle JIT-compiler die zich richt op de LLVM, maar deze dingen gebeuren niet van de ene op de andere dag. Je hebt een team van uitstekende en goed opgeleide codeerders nodig met kennis van compilers en tolkontwerpen, een sterke werkethiek (om een product binnen een paar jaar op de markt te brengen) en de nederigheid om een bestaande taal opnieuw te implementeren in plaats van hun eigen ijdelheidsproject te creëren. Zie ook # 3.