Nejlepší odpověď
Přepnul jsem ze stavu na R. Zde jsou moje postřehy:
Výhody:
- R je otevřený zdroj, budete mít přístup k některým opravdu skvělým algoritmům nebo softwaru, které lidé napsali pro problémy s výklenky.
- R má lepší vizualizace. Jakmile budete mít dobrý přehled o ggplot2, můžete to udělat docela úžasné věci s téměř jakýmkoli typem dat.
- Zjistil jsem, že R je snadnější pro psaní vlastních balíčků a funkcí.
- R je blíže komunitě statistik / strojového učení, takže najdete více podpory / balíčků než stata.
- Mám rád RStudio Gui, zvláště když pracuji na serveru.
- R poskytuje lepší podporu latexu.
- R má velmi aktivní komunitu a seznamy nápovědy – všechny moje otázky mi poskytly neuvěřitelně rychlou podporu.
- R pracuje s Big Data! Balíček RHadoop vám umožňuje psát vlastní skripty MapReduce pomocí funkcí R. Pokud se někdy budete muset zabývat velkými daty a můžete použít pouze Stata, budete v háji.
- Tady bývá mnohem více „hacků“ v R pro komplikované problémy, jako je síťová analýza, vlastní bootstrapy atd. Jakmile se vydáte pryč od vanilkových implementací, často jsem v procedurách v R našel zkratkové funkce, zatímco ve Statě si často musíte kódovat cestu ven.
Nevýhody:
- R je otevřený zdroj, možná budete muset chvíli počkat, než získáte přístup k novým algoritmům, pokud nedojde k aktivnímu vývoji.
- Stata je mnohem blíže ekonometrické komunitě a má mnohem více algoritmů, balíčků a implementací než R. Pokud jste ekonom, bude vás frustrovat nedostatek komplexnosti ekonometrických balíčků.
- Stata má skvělé grafické uživatelské rozhraní, které vám umožní interaktivně vybrat postup, který chcete spustit, a vyplní většinu podrobností za vás. To je skvělé, když používáte funkci, kterou jste nikdy dříve nepoužívali. R to opravdu nemá – mám pocit, že když používám RI am na Google polovinu času.
- Stata je rychlejší než R [1].
- Stahování modulů Stata je mnohem efektivnější proces. U modulů R v CRAN obvykle není problém (i když se při používání stroje Centos dostávám do potíží), existuje však několik základních balíčků, které na CRAN nejsou.
- Stata je standardní vizualizace a vykreslování je mnohem lepší než R.
- Stata má lepší standardní nápovědu – mám pocit, že si můžu přečíst nápovědu k jakékoli funkci a přesně zjistit, co třeba udělat, zatímco já se tak necítím pro několik balíčků R, které jsou špatně zdokumentovány.
- R má syntaxi „WTF“ a strukturu pojmenování balíků. Většina projektů s otevřeným zdrojem ano. Chybí mi jednoduchost statistických funkcí (reg, lm atd.).
[1] http://ekonometrics.blogspot.com/2011/04/speeding-tickets-for-r-and-stata.html
odpověď
Obecně platí, že když najdu příslovce “ očividně „ve větě najdu nějaké neopodstatněné prohlášení, které následuje. Tady nesouhlasím s tvrzením, že R má „bizarní syntaxi“. Každý vzdělaný programátor by raději kódoval v Haskellu nebo v nějakém Lispu, ale faktem je, že tyto jazyky nikdy nedosáhnou velkého publika. R je uvnitř Lisp (například můžete skutečně kódovat jazyk v R, ale ne v Pythonu), ale je dostatečně blízko vědeckému jazyku venku. Jak si všimnete, jako jazyk pro analýzu dat je R ve skutečnosti tím nejpřirozenějším a nejelegantnějším jazykem. Pokud o tom chcete důkaz, podívejte se na aktivitu kolem Pythonu a Julie: implementace datových rámců (pandy a data.frame v Jlia), vzorců (patsy), plyr (pandy). A přesto se všechny tyto funkce stále cítí poněkud naroubované na jiné jazyky. To, co lidé vnímají jako „bizarní“ nebo „nezbedné“, je buď výsledkem ústupku interaktivnímu používání (např. Upuštění od dimenze), nebo funkčního dědictví jazyka.
Souhlasím s tím, že R má spoustu oblasti ke zlepšení, ale většinou ne v jazykové syntaxi. Jistě, jeho konvence pojmenování jsou nekonzistentní; rychlost a správa paměti jsou známé problémy; a tak dále. Proč? Několik důvodů:
- Hlavní směrnicí společnosti R (podle jejího tvůrce Johna Chamberse) je výroba důvěryhodného softwaru. R klade velký důraz na přesnost a spolehlivost. Jeho základní statistické funkce jsou špičkové; dokonce i jeho základní grafický systém byl pečlivě promyšlen, od binování histogramu (není to triviální problém!) až po umístění textu. Rychlost nikdy nebyla velkým problémem, a to správně. Pokud by šlo o rychlost a efektivitu paměti, všichni bychom kódovali ve FORTRANU, který je také snadný a na vysoké úrovni. Zdrojový kód základny R je krátký (400 tis. LOC; pro srovnání, samotný Numpy má stejnou velikost) a velmi čitelný. Kód, kterému rozumíte a kterému můžete důvěřovat.
- Splus a R byly počaty v 80. a 90. letech, dlouho před dobou „velkých dat“ a nástupem strojového učení. R se ale zlepšilo. Správa paměti je mnohem lepší, pravděpodobně lepší než MATLAB. Má nějaký způsob, jak jít, ale některé věci lze zlepšit (např. Interní reprezentace dat).
- Základní vývojový tým má minimální obrat a mladým kodérům před 15 lety je nyní 50 let. Kromě toho jsou mnohem méně zapojeni do komunity a tvoří malebnou / mýtickou postavu, jako je Brian Ripley: profesor z Oxfordu odpovědný za 70\% + závazků, nikoli nejpřátelštější člověk na planetě a na seznamech adresátů R.
- R prosí o rychlý kompilátor JIT zaměřený na LLVM, ale tyto věci se nestávají přes noc. Potřebujete tým vynikajících a vzdělaných programátorů se znalostmi designu překladačů a tlumočníků, silnou pracovní morálkou (vytlačení produktu za pár let) a pokorou namísto vytváření vlastního projektu marnosti znovu implementovat stávající jazyk. Viz také # 3.