Vraag:
Hoe een statistisch analyseproject efficiënt beheren?
chl
2010-09-21 01:39:08 UTC
view on stackexchange narkive permalink

We horen vaak over projectmanagement en ontwerppatronen in de informatica, maar minder vaak bij statistische analyse. Het lijkt er echter op dat een doorslaggevende stap in de richting van het ontwerpen van een effectief en duurzaam statistisch project erin bestaat de zaken georganiseerd te houden.

Ik pleit vaak voor het gebruik van R en een consistente organisatie van bestanden in afzonderlijke mappen (onbewerkt gegevensbestand, getransformeerd gegevensbestand, R-scripts, figuren, notities, enz.). De belangrijkste reden voor deze benadering is dat het gemakkelijker kan zijn om uw analyse later uit te voeren (bijvoorbeeld wanneer u bent vergeten hoe u toevallig een bepaalde plot produceerde).

Wat zijn de best practices voor statistisch projectbeheer , of de aanbevelingen die u zou willen geven vanuit uw eigen ervaring? Dit geldt natuurlijk voor alle statistische software. ( één antwoord per bericht, graag )

Ik stem om deze vraag af te sluiten als off-topic omdat het over projectmanagement gaat
@Aksakal: Ik denk dat je een beetje hard bent.:) Het is relevant voor "* mensen die geïnteresseerd zijn in statistieken *".Ook de 70+ stemmen suggereren sterk dat standaardgebruikers deze vraag interessant en nuttig vonden.
Ik denk dat dit hier als onderwerp moet worden overwogen.
@gung Zou je misschien een antwoord willen toevoegen aan die Meta-thread zodat we het kunnen bespreken?
Zeven antwoorden:
#1
+80
chl
2010-09-30 15:44:48 UTC
view on stackexchange narkive permalink

Ik stel een korte reeks richtlijnen samen die ik heb gevonden over SO (zoals voorgesteld door @Shane), Biostar (hierna, BS) en deze SE. Ik heb mijn best gedaan om het eigendom van elk item te erkennen en om het eerste of meest positieve antwoord te selecteren. Ik heb ook mijn eigen dingen toegevoegd en items gemarkeerd die specifiek zijn voor de [R] -omgeving.

Gegevensbeheer

  • Een project maken structuur om alle dingen op de juiste plaats te houden (gegevens, code, cijfers, etc., giovanni / BS)
  • Wijzig nooit onbewerkte gegevensbestanden (idealiter zouden ze moeten worden gelezen) alleen), kopieer / hernoem naar nieuwe bij het maken van transformaties, opschonen, enz.
  • Controleer de gegevensconsistentie ( whuber / SE)
  • Beheer scriptafhankelijkheden en gegevensstroom met een build-automatiseringstool, zoals GNU make ( Karl Broman / Zachary Jones)

Codering

Analyse

  • Vergeet niet om de seed die je hebt gebruikt in te stellen / vast te leggen bij het aanroepen van RNG of stochastische algoritmen (bijv. k-means)
  • Voor Monte Carlo-onderzoeken kan het interessant zijn om specificaties op te slaan / parameters in een apart bestand ( sumatra kan een goede kandidaat zijn, giovanni / BS)
  • Beperk jezelf niet tot één plot per variabele, gebruik multivariate (Trellis) displays en interactieve visualisatietools (bijv. GGobi)

Versiebeheer

  • Gebruik een soort revisiebeheer voor eenvoudig volgen / exporteren, bijv Git ( Sharpie / VonC / JD Long / SO) - dit volgt uit leuke vragen gesteld door @Jeromy en @Tal
  • Maak regelmatig een back-up van alles ( Sharpie / JD Long / SO)
  • Houd een logboek bij van uw ideeën of vertrouw op een issue tracker, zoals ditz ( giovanni / BS) - gedeeltelijk overbodig met het vorige item aangezien het beschikbaar is in Git

Editing / Reporting

Terzijde: Hadley Wickham biedt een uitgebreid overzicht van R-projectbeheer, inclusief reproduceerbare voorbeelden en een uniforme filosofie van data .

Ten slotte biedt Oliver Kirchkamp in zijn R-georiënteerde Workflow van statistische data-analyse een zeer gedetailleerd overzicht van waarom het adopteren en gehoorzamen van een specifiek workflow helpt statistici om met elke ot samen te werken haar, terwijl de gegevensintegriteit en reproduceerbaarheid van de resultaten wordt gewaarborgd. Het bevat verder enige bespreking van het gebruik van een weef- en versiecontrolesysteem. Stata-gebruikers kunnen de The Workflow of Data Analysis Using Stata van J. Scott Long ook nuttig vinden.

Goed gedaan, chl! Zou het oké zijn? door jou als ik dit op mijn blog publiceer? (Ik bedoel, deze tekst is cc, dus dat kon ik, maar ik wilde hoe dan ook je toestemming :)) Proost, Tal
@Tal Geen probleem. Het is verre van een volledige lijst, maar misschien kunt u op een later tijdstip andere nuttige links samenvoegen. Voel je ook vrij om je op een betere manier aan te passen of te reorganiseren.
+1 Dit is een mooie lijst. Je zou kunnen overwegen "dit te accepteren" zodat het altijd bovenaan staat; aangezien het CW is, kan iedereen het up-to-date houden.
@Shane Nou, ik ben je veel dank verschuldigd voor het geven van een eerste antwoord met zo nuttige links. Voel je vrij om toe te voegen / aan te passen zoals je wilt.
Ik heb het hier opnieuw gepubliceerd. Geweldige lijst! http://www.r-statistics.com/2010/09/managing-a-statistical-analysis-project-guidelines-and-best-practices/
Ik zou voor Mercurial stemmen in plaats van Git als tool voor versiebeheer. Ik heb gemerkt dat het gemakkelijker te gebruiken is en dat de gebruikersgemeenschap niet zo hard is. (Op de Mac is MacHG een geweldige GUI-front-end voor Mercurial.) Welk versieprogramma je ook gebruikt, een GUI-front-end is erg handig en krachtig voor het volgen en beheren van dingen.
@Wayne Bedankt daarvoor. Oliver Kirchkamp besprak het gebruik van SVN; Ik merkte dat ik [RCS] (http://www.gnu.org/software/rcs/) vaak gebruikte voor verschillende dingen, maar ik heb goede dingen gehoord van Hg. Ik ben het ermee eens dat een GUI een pluspunt kan zijn, hoewel ik voornamelijk werk vanaf de commandoregel en Emacs. ([GitHub for Mac] (http://mac.github.com/) is trouwens niet zo slecht.)
@CHL: Op het eerste gezicht is het gemakkelijk te denken dat een GUI het voor een beginner eenvoudigweg gemakkelijker maakt om te gebruiken, maar ik heb gemerkt dat de kracht van de GUI (tenminste MacHG) is dat hij dynamisch is. Ik houd MacHG de hele tijd open en ik kan in één oogopslag zien welke bestanden er in een project zitten en welke zijn bijgewerkt. Klik op een bestand om te zien wat er is gewijzigd. Het helpt vooral als ik van project verander, om me eraan te herinneren waar ik was.
Dit zou echt kunnen doen met de toevoeging van een beschrijving van het gebruik van een Makefile voor het beheren van gegevensmunging en caching. Als iemand er een kent, voeg deze dan toe. Zo niet, dan zal ik proberen er binnenkort een op te schrijven, zodra ik er mijn hoofd omheen heb.
@naught101 Karl Broman heeft een aantal tutorials over het gebruik van GNU-tools en R in zijn "Tools for Reproducible Research", http://kbroman.github.io/Tools4RR/.
interessant - uw antwoord is een zeer uitgebreide gids voor code- / bestandsbeheer.niet te veel in termen van nagaan of je de belangrijkste onderzoeksvragen of outputvereisten ook daadwerkelijk hebt beantwoord
#2
+21
Shane
2010-09-21 01:42:22 UTC
view on stackexchange narkive permalink

Dit geeft niet specifiek een antwoord, maar misschien wil je deze gerelateerde stackoverflow-vragen eens bekijken:

Misschien ben je ook geïnteresseerd in John Myles White's recente project om een ​​statistische projectsjabloon te maken.

Bedankt voor de links! De vraag staat open voor elke statistische software - ik gebruik Python en Stata van tijd tot tijd, dus ik vraag me af of bevestigde gebruikers daar interessante aanbevelingen kunnen doen.
Absoluut; hoewel ik eraan zou willen toevoegen dat de aanbevelingen in de bovenstaande links echt van toepassing kunnen zijn op elk statistisch project (ongeacht de taal).
Zeker ja! Ik heb mijn vraag tegelijkertijd bijgewerkt.
#3
+8
user88
2010-09-25 20:45:58 UTC
view on stackexchange narkive permalink

Dit overlapt met het antwoord van Shane, maar naar mijn mening zijn er twee belangrijke pijlers:

  • Reproduceerbaarheid ; niet alleen omdat u niet zult eindigen met resultaten die "op de een of andere manier" zijn gemaakt, maar ook omdat u de analyse sneller kunt uitvoeren (op andere gegevens of met licht gewijzigde parameters) en meer tijd hebt om na te denken over de resultaten. Voor een enorme hoeveelheid gegevens kunt u uw ideeën eerst testen op een kleine "speelset" en vervolgens gemakkelijk uitbreiden met de volledige gegevens.
  • Goede documentatie ; becommentarieerde scripts onder versiebeheer, sommige onderzoeksjournaals, eventicketsysteem voor meer complexe projecten. Verbetert de reproduceerbaarheid, maakt het opsporen van fouten eenvoudiger en het schrijven van eindrapporten is triviaal.
+1 Ik hou van het tweede punt (ik gebruik roxygen + git). Het eerste punt doet me ook denken aan de mogelijkheid om uw code aan een andere statisticus te geven die uw resultaten in een later stadium van het project zonder enige hulp kan reproduceren.
Reproduceerbaarheid?Gegevens bevatten sowieso een willekeurige fout, dus who cares.Documentatie?Twee mogelijke antwoorden: 1) We hebben het te druk, we hebben geen tijd voor documentatie of 2) we hadden alleen budget om de analyse uit te voeren of te documenteren, dus kozen we ervoor om de analyse uit te voeren.Denk je dat ik een grapje maak?Ik heb deze opvattingen bij vele gelegenheden gezien / gehoord - over projecten waarbij levens op het spel stonden.
#4
+4
Carlos Accioly
2010-09-21 08:00:48 UTC
view on stackexchange narkive permalink

van Belle is de bron voor de regels van succesvolle statistische projecten.

#5
+1
Wes McCardle
2010-10-01 05:58:05 UTC
view on stackexchange narkive permalink

Slechts mijn 2 cent. Ik vond Notepad ++ hiervoor nuttig. Ik kan aparte scripts (programmabesturing, gegevensopmaak, etc.) en een .pad-bestand voor elk project bijhouden. De .pad-bestandsoproep zijn alle scripts die aan dat project zijn gekoppeld.

Je bedoelt, notepad ++ met het gebruik van npptor :)
#6
+1
Christian Sauer
2014-04-09 14:58:39 UTC
view on stackexchange narkive permalink

Hoewel de andere antwoorden geweldig zijn, zou ik nog een sentiment willen toevoegen: vermijd het gebruik van SPSS. Ik heb SPSS gebruikt voor mijn masterscriptie en nu voor mijn vaste baan in marktonderzoek.

Tijdens het werken met SPSS was het ongelooflijk moeilijk om georganiseerde statistische code te ontwikkelen, vanwege het feit dat SPSS slecht is in het verwerken van meerdere bestanden (je kunt zeker meerdere bestanden verwerken, maar het is niet zo pijnloos als R ), omdat je datasets niet in een variabele kunt opslaan - je moet "dataset activeren x" -code gebruiken, wat een totale pijn kan zijn. De syntaxis is ook onhandig en moedigt steno aan, waardoor code nog onleesbaarder wordt.

#7
  0
hugke729
2018-06-09 09:04:29 UTC
view on stackexchange narkive permalink

Jupyter Notebooks, die werken met R / Python / Matlab / etc, zorgen ervoor dat je niet meer hoeft te onthouden welk script een bepaald cijfer genereert. Dit bericht beschrijft een nette manier om de code en de afbeelding naast elkaar te houden.Door alle cijfers voor een paper of scriptiehoofdstuk in één notitieboekje te bewaren, is de asccoiated code zeer gemakkelijk te vinden.

Zelfs nog beter, omdat je bijvoorbeeld door een dozijn cijfers kunt scrollen om het cijfer te vinden dat je zoekt.De code wordt verborgen gehouden totdat deze nodig is.



ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 2.0-licentie waaronder het wordt gedistribueerd.
Loading...