För mig verkar det som om skälen är två:

• tron ​​att kod bara är ett verktyg, en viss implementering är sekundär till idén eller algoritmen,
• den historiska återstoden (det var opraktiskt att skriva ut många sidor, särskilt eftersom ingen kunde kopiera och klistra in den).

Dessutom:

• många forskare verkar vara rädda för att visa sin kod offentligt, eftersom de är medvetna om dess dåliga kvalitet (se även Varför skriver många begåvade forskare hemsk programvara?), så de vill inte riskera rykte (för både kvalitet och fånga möjliga fel).

Dessutom är saker relaterade till nuvarande incitament i den akademiska världen (där publikationer, inte kod, är relaterade till ens karriärmöjligheter):

• delningskod kan innebära risk för att tas bort (istället för att mjölka samma kod i flera år),
• att rensa koden tar tid, vilket kan användas för att skriva en annan publikation.

Måste människor skicka sin kod privat till r åtminstone så att de kan reproducera experimentet om möjligt.

Vanligtvis - inte. Om koden inte offentliggörs har nästan ingen granskare kontrollerat dess existens. mycket mindre - korrekthet.

Men många forskare börjar märka problemet (och de ser hur öppen källkodskultur blomstrar). Så det finns nya initiativ som behandlar en sådan fråga, som Science Code Manifesto:

Programvara är en hörnsten i vetenskapen. Utan programvara skulle det tjugoförsta århundradet vara omöjligt. Utan bättre programvara kan vetenskapen inte utvecklas.

Eller t.ex. detta manifest. Försök att söka efter reproducerbar forskning eller titta på saker som knitr för R och detta introduktion till IPython Notebook, eller läs om med GitHub för vetenskap. Och det verkar som att det tar fart.

Vilket område pratar du om? Ett CS-papper som beskriver designen och prestandan hos en datorvisionsalgoritm skiljer sig från ett sociologipapper som använde ett kalkylblad för att knäcka demografiska data.

Gör de flesta tidskrifter / konferenser bara "lita på" att människor som skicka in papperet verkligen implementerade teorin och fick de exakta resultaten?

Ja. Antagandet är alltid att det inte finns något vetenskapligt bedrägeri involverat.

Jag har alltid haft den uppfattningen att alla experiment ska kunna reproduceras av andra, det är inte vetenskapligt motiverat.

Om algoritmerna beskrivs fullständigt i tidningen är resultatet reproducerbart. För att reproducera det måste du implementera algoritmen igen.

Jag började bara läsa några papper och tänkte nu, låt oss titta på koden och blev förvånad över att de flesta papper inte har någon kod att titta på, samtidigt som man gör anspråk på lite prestanda eller är bättre än andra papper.

Förmodligen är bättre prestanda på grund av att den algoritm som beskrivs i tidningen är en mer effektiv algoritm. Till exempel, när man sorterar en stor mängd data, är en quicksort en bättre sorteringsalgoritm än en bubblasortering. Snabbsorten har O (n log n) -prestanda i genomsnitt, medan bubblasorten har O (n ^ 2), och detta gäller oavsett detaljerna i implementeringen.

Jag tror att en fråga som är relaterad till den som tagits upp av Piotr (+1) som är att forskningsfinansiering i allmänhet inte är tillgänglig för att täcka kostnaderna för att producera mycket pålitlig bärbar kod eller kostnaderna för att underhålla / stödja kod som produceras för "forskning kvalitet". Jag har funnit att detta är en viktig fråga när jag försöker använda kod som släppts av andra forskare inom mitt område. alltför ofta kan jag inte få koden att fungera eftersom den använder något tredjepartsbibliotek som inte längre är tillgängligt, eller som bara fungerar på en Windows-dator eller som inte längre fungerar på min version av programvaran eftersom den använder något föråldrat inslag i språket / miljön. Det enda sättet att komma runt detta är att implementera om rutinerna från tredjepartsbiblioteket så att all kod tillhandahålls som ett enda monolitiskt program. Men vem har tid att göra det i en underfinansierad "publicera eller förgås" -miljö?

Om samhället vill ha högkvalitativ kod som ska åtfölja varje uppsats, måste samhället göra medel tillgängliga så att bra programvarutekniker kan skriva och underhålla den. Jag håller med om att det här skulle vara bra, men det kostar inget.

Du verkar tro att vi bör begära kod, för utan kod kan något galet resultat, oavsett om det är bedrägeri eller ärligt misstag, släppas in i tidningen. Men detta är inte så. Inkludering av kod är en trevlig-att-ha-funktion, inte en måste-ha-funktion. De andra svaren antar tyst detta och förklarar de (bra och inte så bra) orsakerna som leder till den nuvarande situationen med ovanligt inkluderad kod. Jag tror att jag kan komplettera dem genom att förklara varför det inte är en måste-ha-funktion.

För teoretiska resultat behöver du inga empiriska verktyg som kod för att reproducera dem, som andra nämnde (t.ex. bevisa att en algoritm har ett bättre stort O-beteende än en annan). Naturligtvis finns det också empiriska resultat, som inte kan replikeras på det sättet.

Men dina granskare kommer att förvänta sig vad din idé kommer att resultera i. Om den nuvarande bästa prestandan för att wugging zums är 3 zums / s, och du lägger till en mindre tweak och rapporterar 300 zums / s, kommer din granskare ska märka att ditt anspråk är ovanligt och göra något (eventuellt kräva att skicka in igen med koden). Detta är inte idiotsäkert, men med flera granskare per papper är det effektivt eftersom storleken på de mest empiriska resultaten är förutsägbar när granskaren ser idén och förstår hur den fungerar.

För denna typ av papper har både ärliga och oärliga misstag goda chanser att fångas, med dåliga resultat för ärliga forskare (rykteförlust, särskilt om de fångas efter publicering) och sämre resultat för oärliga forskare (slut av karriär om bevisat!). Ju större misstaget är (mätt i felstorleken) desto större är chansen att fångas. Det är mindre troligt att du kommer att fastna om din algoritm hanterar 4 zums / s och du rapporterar 5 zums / sekund, än om du rapporterar 300 zums / s. Så, forskare undantas från att skicka in felaktiga papper, lämna mindre felaktiga i den inlämnade poolen, och granskarna fångar mycket av resten.

Det finns fall där det är helt okänt varför en observation är som den är, och i dessa fall är det mycket viktigt att beskriva den exakta testuppsättningen perfekt. Men jag har aldrig sett denna typ av papper inom datavetenskap, det är förknippat med naturvetenskap. Så ingen kod där. Även om du fick sådana resultat inom datavetenskap (t.ex. observerade du att användare kan läsa ett 12000 ord EULA på mindre än 30 sekunder, vilket strider mot vanliga läshastighetsobservationer, och du har ingen förklaring för det), är det osannolikt att inkludera koden du använde för att få resultatet kommer att vara relevant för replikering.

För att sätta ihop det, bland en stor massa datavetenskapliga artiklar, behöver de teoretiska och de naturfenomen-observationerna inte inkludera kod för replikering, och de återstående innehåller endast en låg procent av felaktiga men icke-fångade papper. Sammantaget leder detta till att en acceptabelt låg nivå av felaktiga papper skickas in. Att begära att koden ska följa med kommer att öka kvaliteten för en pappersklass, men det kommer att öka en redan hög kvalitetsnivå. Det är inte det att den nuvarande kvaliteten inte blir för låg om den inte har den här funktionen.

Eftersom vissa forskare inte gillar att tänka på den verkliga världen och granskare inte vill ha besväret.

(Vad som är nästa är lite av en rant)

Jag har nyligen gjort en undersökning av en specifik typ av geometri-relaterade algoritmer. I alla tidningar beskrivs programmet som att det fungerar perfekt men när jag frågade källkoden från ett dussin författare blev saker fula.

50% av programvaran saknade viktiga annonserade funktioner. Till exempel fungerar programvaran bara i 2D medan papperet visar 3D-exempel. (Vilket i mitt fall verkligen gör saker mycket svårare). Efter att ha frågat varför dessa funktioner saknades hade de vanligtvis aldrig implementerats eller implementerats men visat sig vara instabila / inte fungerar. För att vara tydlig: det var 100% omöjligt att generera de resultat som visas i papperet med programvara som ofta till och med förbättrades efter att papperet släpptes.

75% av programvaran skulle inte fungera perfekt i normala fall . I mitt fall berodde detta vanligtvis på att algoritmen var utformad med "perfekta siffror" i åtanke men algoritmen implementerades med hjälp av normala flytpunktsnummer och därmed hade representationsproblem som resulterade i stora fel. Bara ett fåtal papper nämnde dessa problem och endast två försökte (delvis) ta itu med dem.

85% av programvaran skulle inte fungera i scenarier som är särskilt utformade för att hitta problemfall. Låt oss vara ärliga; om en "bara" student kan hitta ett scenario om några veckor som helt bryter din algoritm vet du förmodligen redan om detta.

Att inte tillhandahålla kod gör det möjligt att ljuga och till min avsky (jag är ny till den akademiska världen) görs detta extremt ofta. Min handledare blev inte ens förvånad. Testkod är dock mycket arbete så detta beteende kommer förmodligen att vara okontrollerat en stund till.

Som biträdande redaktör för en tidskrift (överbryggande statistik och psykologi) bad jag författarna att skicka in koden när de föreslog nya algoritmer och procedurer och skickade sedan koden till experterna i det statistiska paketet för att kontrollera att (en ) koden gör vad papperet beskriver, och (b, sekundär) att det är en bra kod (robust till dåliga ingångar, beräkningseffektiv, etc.). Jag blev också ombedd att granska några artiklar för Stata Journal vars fokus är koden, och gjorde detsamma. Det fanns tillfällen då (a) misslyckades, så jag var tvungen att skicka tillbaka tidningen och säga att författarna var tvungna att anpassa metoden och koden. Det fanns tillfällen då (b) skulle misslyckas, och i fallet med Stata Journal skulle detta också innebära att papperet återlämnades. Det var tillfällen då koden inte skulle komma.

För det mesta skulle jag gärna dela min kod, men det är tillräckligt komplicerat (med interna metadatabaserade kontroller, anpassad utdata etc.) att en forskare som är mindre skicklig med paketen Jag använder kommer inte att kunna redigera det för att få det att fungera på sin dator.

Återgår till din huvudfråga - granskare är lat pressade för tiden och har sina egen forskning för att driva på sina tidskrifter, så få av dem försöker fullständigt verifiera resultaten. Så här är världen. Det kan hända att dessa professorer kan begära koden och ge den till sina doktorander att leka med, bryta och felsöka, eftersom detta skulle vara en bra utbildningsmöjlighet för de senare. Men återigen händer det inte så ofta, eftersom sekretessbestämmelserna för att acceptera granskarrollen vanligtvis hindrar en från att dela tidningen med någon annan.

Jag vill lägga till en lite annan synvinkel från ett experimentfält (kemi / spektroskopi / kemometrisk dataanalys).
Här börjar studien i laboratoriet (eller kanske i fältet), med en gammaldags typ av anteckningsbok. Gammaldags vanligtvis fortfarande papper + penna. Dataanalys görs ofta med GUI-program på ett interaktivt sätt. Dokument hålls precis som i labbet: papper + penna. Kanske med några sparade och / eller tryckta siffror. Som redan registrerades delen i labbet på detta sätt, att inte ha en loggfil eller ens ett skript av dataanalysen ses inte som ett problem. Hur som helst, att be om att koden ska publiceras är bara en del av vad du behöver för att köra analysen igen: du behöver också den faktiska informationen.
Redan förslaget att skriva in dataanalysen och åtminstone spara antingen en logg över matlab / R-sessionen eller skriv den i skriptform är fortfarande typ av ny (även om människor älskar knitr -genererade rapporter som jag producerar ...). Men IMHO-saker går ganska snabbt nu. Jag skulle säga att med verktyg som git och knitr är de största praktiska hindren nästan löst åtminstone för den typ av person som föredrar kod framför att klicka. Det är dock inte så att allt redan fungerar smidigt (överväga stora binära rådata och git , och jag medger uppriktigt sagt att jag inte har någon aning om hur jag praktiskt kan skapa en "riktig" databasserver på ett effektivt sätt att det håller reda på förändringar). Detta är ur mitt perspektiv som forskare som bara behöver verktyg för reproducerbarhet som användare - och därmed förstår jag mina icke-programmerande kollegor som ändå behöver analysera sina data: de har bara inte (eller vet av) verktygen som gör det möjligt för dem att logga sina analyser med rimlig ansträngning.

Den traditionella uppskattningen av var de stora svårigheterna lurar fokuserar också på lab-delen. Jag tror att många forskare inte är medvetna om reproducerbarhetsproblemen med beräkningarna / dataanalysen. För att vara ärlig delar jag vanligtvis den synvinkeln: IMHO i biospektroskopi är ett av de stora viktiga problemen det alldeles för låga antalet individer i studierna. Om du bara har 4 möss i studien kan den exakta hanteringen av uppgifterna inte påverka de praktiska slutsatserna för mycket. Det finns en grå zon där inte en korrekt validering kan påverka slutsatserna, men igen: alla jag känner som gör valideringen enligt den mest kända praxis stavar detta mycket uttryckligen - så igen (och accepterar en viss risk för falskt kasta bort få papper som "förmodligen inte reproducerbara") Jag brukar tro att de praktiska slutsatserna knappast påverkas.

Å andra sidan ser jag på kraven som t.ex. Chemmical Communications som läggs ut om en ny kemisk substans ska publiceras Jag kan inte se varför det inte kan finnas datavetenskapliga tidskrifter som kräver koden på ett liknande sätt.
Som t.ex. det gör Journal of Statistical Software. (Jag är ganska säker på att det finns andra sådana tidskrifter, men jag känner dem inte.)

För mig faller detta i ett mycket större område med reproducerbarhetsfrågor. Naturligtvis, om dataanalysen inte kan reproduceras finns det stora problem.

Ännu en punkt: även om publikationer om programvara fortfarande är mycket sällsynta inom mitt område, hade jag nyligen en sådan uppsats för granskning. Tyvärr föreslås att mjukvaran distribueras genom att kontakta en av författarna - vilket jag självklart inte kunde göra som en anonym granskare.
Således kan den faktiska programvaran vara ännu mindre tillgänglig för granskare än för normala läsare!

Jag tror att de flesta läsare / granskare skulle hitta en tillräckligt detaljerad algoritm. Du skriver ditt papper som visar, oh, C ++ - kod, och jag använder SPSS i min butik - din kod är värdelös för mig. Inte för att de flesta läsare skulle njuta av att återimplementera koden (speciellt för icke-CS-papper), men med en specifik kod som körs på en specifik plattform, kommer det säkert att vara mycket röran att vada igenom. En algoritm reducerar den till det väsentliga.

Om mitt papper visar hastighetsförbättringen av min nya Quicksort-metod jämfört med standard Bubble Sort, skulle det vara lättare att stödja mina påståenden genom att visa algoritmer för de två metoderna. för O (n log n) vs O (n ^ 2) speedup. Om mitt papper handlar om befolkningsåldersfördelningar i rika kontra utvecklingsekonomier, såvida det inte finns ett riktigt snyggt trick som jag använde för att bearbeta data, skulle de flesta läsare förmodligen inte ens bry sig om algoritmen, utom i mycket breda penseldrag.

Det kommer att bero på ämnesområdet (allmänt, exempelvis datavetenskap) och det specifika delområdet (säg sorteringsmetoder), samt hur stor inverkan algoritmen som används har på resultaten, om algoritmen är nödvändig. Om jag visar kompilatorskillnader i Fortran-koden, skulle det vara bra att inkludera faktisk kod. Annars är själva koden sällan av intresse.

Detta är en vy från datavetenskap / teoretisk datavetenskap / matematik.

Fråga dig själv: vem är målgruppen för en akademisk uppsats?

Det är inte slutanvändare. Det är granskare ! Vill granskare ha kod? Beror på situationen. Ibland gör de det. Ofta gör de det inte.

Tänk på det här: varför matematiker inte ger formella bevis utan använder informella argument?

Det är kostnader kontra fördelar. Att tillhandahålla ett formellt verifierat bevis är möjligt men behöver vanligtvis för mycket arbete, arbete som författare inte är utbildade för och inte har mycket erfarenhet av. Å andra sidan, vad tjänar författarna på det? Hjälper det att övertyga granskarna om riktigheten i resultaten? Nej, vanligtvis föredrar granskare en kort informell förklaring som gör att de kan förstå och se varför resultatet är sant. Ett formellt bevis hjälper vanligtvis inte mycket. Det finns människor som inte gillar datorassisterade bevis som inte kan verifieras och förstås direkt av människor.

Samma kostnader jämfört med nytta tänkande gäller program. Om tillhandahållande av kod inte hjälper till att övertyga granskaren om papperets riktighet, varför slösar du bort resurser (tid / pengar / sidor / ...) för att göra det? Har granskare tid att läsa koder med tusentals rader för att kontrollera att det inte finns något fel i dem?

Å andra sidan är ibland mjukvaran som härrör från papperet av primärt intresse. Att ha koden är till hjälp för att verifiera anspråken. T.ex. du hävdar att du har en snabbare algoritm för SAT. Då är det bra att ange koden. I sådana fall anger författarna sin kod. Detta är främst i mer experimentella delar. Vi bryr oss inte om riktigheten i koden utan att få resultat bättre än befintliga algoritmer. I sådana situationer finns det vanligtvis standardvärden för att jämföra algoritmer. (Se till exempel SAT-tävlingar.) Om det inte finns etablerade riktmärken, varför publicera kod? Om det är ett teoretiskt resultat där de asymptotiska fördelarna sker över fall som är för stora för att testa, vad är fördelen med att ha koden? Mer med tanke på det faktum att stor kod som utvecklats av icke-professionella programmerare med stor sannolikhet är buggy? Att anställa professionella programutvecklare för att utveckla kvalitetskod är kostsamt ( den genomsnittliga årliga inkomsten för en person med en kandidatexamen i CS är cirka 100 000 i USA) (förutom eventuellt som doktorander;) och är vanligtvis inte har några vinster efteråt.

Men behöver kod inkluderas i papper? Självklart inte! Det finns bättre sätt att publicera kod, t.ex. ha en länk i tidningen till en online-kopia (på deras hemsida eller ett offentligt arkiv som github). Varför skulle man föredra att inkludera en kod med tusentals rader i ett dokument som ska läsas av människor ?

Vanligtvis avser "prestanda" för kod "hur bra den skalas med storleken på problemet". Detta betyder enligt min mening att ett papper som hävdar "algoritm A är snabbare än algoritm B" behöver visa timing för både A och B _ för problem med olika storlek. Även om det fortfarande kan finnas ineffektivitet (och fel) i implementeringarna, kommer detta åtminstone att visa om den underliggande algoritmen är effektivare (lägre stor-oh).

Var programvaran är de nyckeln till papperet ( produkt, inte verktyget) Jag förväntar mig att den är tillgänglig (github eller annat). Så ett papper som säger "Jag kan sortera i ordning 1 / n genom att kerfugla dargibold-numret" måste visa hur det gjordes; papperet som hävdar "när jag sorterade dessa två datauppsättningar, den från Whoville hade större flubbits" behöver inte visa hur koden sorterades - de måste fokusera på att förklara vad som är viktigt med flubbits från Whoville.

Hämtad från boken SKIENA, S. The Algorithm Design Manual: Springer. 2008:

Efter en lång sökning upptäckte Chazelle [Cha91] en linjär tidsalgoritm för triangulering av en enkel polygon. Denna algoritm är tillräckligt hopplös för att implementera att den kvalificerar mer som ett existenssäker.

[Cha91] CHAZELLE, Bernard. Triangulering av en enkel polygon i linjär tid. Diskret & Computational Geometry , 1991, 6.3: 485-524.

Jag tror att författarna överväger kostnader och fördelar och undviker inlämning av kod när kostnaderna uppväger fördelarna.

Enligt David W. Hogg kostar det:

1. du kan bli avskaffad
2. du kan bli generad av din fula kod eller av att du inte kommenterar eller dokumenterar
3. måste du svara på frågor (och ofta dumma eller irrelevanta) om koden och spendera tid på att dokumentera
4. du måste överväga att dra förfrågningar eller på annat sätt behålla koden, eventuellt långt in i framtiden
5. du kan behöva slå ner dåliga och felaktiga resultat som genereras med din kod
6. ditt rykte kan drabbas om koden används felaktigt
7. kan det finnas lagliga (inklusive militära) och licensfrågor

Fördelarna är:

1. mer vetenskap blir klar, fler artiklar skrivs; alla mått på påverkan ökar
2. du får motivation att städa och dokumentera koden
3. resultaten blir (mer) reproducerbara och (mer) pålitliga
4. utomstående hittar fel eller göra förbättringar i din kod och leverera pull-förfrågningar
5. du får kredit och synlighet och bygga community
6. citatpriser kan öka
7. koden bevaras
8. -koden blir sökbar (inklusive av dig!) och säkerhetskopieras
9. det finns bra webbplatser för långvarig arkivering och gränssnitt
10. kan skapa prioritet på en idé eller känd teknik på en metod

Eftersom de flesta akademiska forskare inom tekniska områden inte kan koda för att rädda sina liv. I datorsyn hackar de bara något tillsammans i en enda Matlab-fil. De tycker om att kodning är för undergrader. De tror att det är under dem att slösa bort sin tid på sådana bagateller. De flesta av dem lärde sig aldrig bra mjukvaruteknik och förstår inte komplexiteten och skickligheten som krävs för att skriva bra kod.

Det största problemet är att detta stöds av forskare eftersom alla akademier bryr sig om publicerar, kvantitet över kvalitet. Framgång mäts av hur många citat du har, inte av hur bra dina bidrag är. I slutet av dagen, när de enda som citerar dig själva inte producerar något användbart, spelar det ingen roll. Det är inte vetenskap längre så mycket som det är "forskning för att göra forskning".