Videnskabelige rapporter indeholder fejl på grund af Excel
more_vert
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Teknologiens Mediehus kan findes markedsføring fra samarbejdspartnere.

Videnskabelige rapporter indeholder fejl på grund af Excel

En uhensigtmæssig funktion i programmet Microsoft Excel er skyld i, at 3.600 rapporter, der er blevet publiceret i blandt andre Nature, Science og PLos One, indeholder graverende fejl i de supplerende info om forskningen.

Der er tale om 3.600 rapporter om genetik, som ifølge en analyse fra tidsskriftet Genome Biology indeholder fejl, fordi Excel automatisk har konverteret navnene på gener til datoer eller tilfældige tal.

Eksempelvis bliver genet ‘Septin 2’ typisk forkortet til SEPT2. Et andet gen ‘Membrane-Associated Ring Finger (C3HC4) 1, E3 Ubiquitin Protein Ligase’ bliver forkortet til MARCH1.

Bliver disse forkortelser indtastet i Excel, er regnearket programmeret til at opfatte dem som datoer. Derfor bliver SEPT2 i en standard-indstilling til 2-sep og bevaret som datoen 9/2/2016.

Endnu værre er, at der ikke er nogen nem måde at rette dette på, når formateringen først er sket, skriver The Washington Post.

Er nødt til at huske tekstformatering hver eneste gang

Man kan forsøge at ændre formateringen fra ‘generel’ til ‘text’, hvilket man skulle tro ville ændre den formaterede tekst tilbage til det først indtastede. Men i stedet bliver den indtastede tekst nu ændret til, at kolonnen indeholder en celle med værdien '42615'. Det er Excels interne numeriske kode for 9/2/2016.

Genet MARCH1 bliver derfor også til 1-mar og gemt som 42430 af Excel.

Ekstra frustrerende er det, bemærker Genome Biology, at det ikke er muligt at slå denne automatiske konvertering fra i Excel. Det vil altså sige, at godt nok kan problemet omgås ved, at forskerne husker at formatere kolonner om til tekst, før de taster noget. Men det skal de altså gøre hver gang. Altid. Hver eneste gang.

Og selv forskerne inden for eksempelvis genetik er fejlbarlige ligesom alle os andre. De har altså højst sandsynligt sommetider glemt at markere en kolonne som tekst. Resultatet var ifølge Genome Biology, at hver femte rapport, de undersøgte, indeholdt fejl forårsaget af denne Excel-konvertering.

Anbefaler alternativer til Excel

Problemet er endda gammelt. Det blev identificeret for hele 10 år siden, men plager altså stadig forskningsverdenen. Også på andre forskningsfelter end genetik optræder fejlen.

Heldigvis er der en løsning. Men den kræver altså, at forskerne skrotter Excel. De skal også skrotte open source-programmer som LibreOffice Calc og Apache OpenOffice Cals. Her optræder den samme datofejl nemlig.

Det gør den til gengæld ikke hos Google Sheet, bemærker Genome Biology. De anbefaler også alternativer i form af programmer designet til statistiske undersøgelser såsom R eller Python.

Emner : Genteknologi
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Hvis ikke jeg tager fejl, så er ' standard for indtastning af tekst på samme måde som = er for formler og vises ikke. Så hvis de f.eks. skrev 'SEPT2 istedet, vil indholdet tolkes som tekst uden at de skal ændre format manuelt.

  • 6
  • 3

Regneark i almindelighed og Excel i særdeleshed har efter min erfaring den store svaghed at de lægger en stor del af arbejdet med at flytte data og formatere det over på brugeren, og dermed åbner op for flere menneskelige fejl. Dertil kommer så selvfølgelig i Excels tilfælde alle mulige "hjælpsomme" funktioner som den ovenfor beskrevne der gør det rigtig svært at sikre sig at data stadig konsekvent er som man gerne vil have det.

I et regneark lavet ved copy paste fra forskellige filer, m.m. kan man også ved revision af data/databehandling tit glemme at rette dele af databehandlingen, fordi man skal gentage en masse ting manuelt og fordi det er svært at overskue. Og så kan der opstå fejl. I hvert fald hvis man er et rodehovede, som jeg...

Jeg har selv haft stor succes med at følge den gode gamle regel med at have rådata og behandlede data i separate filer. Det fås f.eks. ved at skrive et script der tager rådata som input (typisk output fra måleinstrumenter) og spytter behandlede data/grafer/rapporter ud i den anden ende. Opdager man en fejl, retter man i scriptet og kører det igen. Får man nye data tilføjer man en inputfil og kører scriptet igen og får derfor en ensartet databehandling.
Derudover er et script i et passende højniveausprog typisk langt mere overskueligt end regnearks cellebaserede databehandling.
Begge dele reducerer antallet af fejl.

Selvfølgelig kan man bruge regnearkenes script-funktioner til både at loade og behandle data helt analogt til det ovenstående, og det er da også en udemærket idé hvis man kan lide at programmere i BASIC.

  • 22
  • 0

Det er vi nogle data-nørder der har lært på den hårde måde, dvs. ved at gentage at glemme at formattere inden man fylder data i.

Det HAR taget meget af min tid, selv efter jeg fandt ud af det. Så det vil helt sikkert også tage tid fra folk der ikke er data-nørder. Beklager.

  • 5
  • 0

Tillad mig at rette overskriften: "Videnskabelige rapporter indeholder fejl på grund af forkert brug af Excel"
Nu passer det en del bedre.

"Det vil altså sige, at godt nok kan problemet omgås ved, at forskerne husker at formatere kolonner om til tekst, før de taster noget. Men det skal de altså gøre hver gang. Altid. Hver eneste gang."

Er det forskere, eller 7. klasse børn der her tales om? Det kan da ikke passe at folk med så høj uddannelse ikke kan overkomme noget så simpelt? Eller sætte en apostrof foran al tekst?

Jeg kan simpelthen ikke tage den her artikel, eller forskerne seriøst. Det er til grin at forsøge at give Excel skylden, fordi man ikke kan finde ud af at bruge det.

Og ellers kan man jo lave en skabelon, hvor man har markeret hele arket og ændret alle celler til "text"....

  • 10
  • 12

Selvfølgelig har du da altid styr på input og output, så du ikke 'kommer til' at rette i inputdata. Inputdata er urørlige, og alle trin i den videre process skal kunne gentages/verificeres med eventuelle nye algoritmer.

Så de 3200 artiklers data kan da selvfølgelig gennemgå en opdatering med rettelse af fejl og mangler.

  • 5
  • 0

Jeg kan simpelthen ikke tage den her artikel, eller forskerne seriøst. Det er til grin at forsøge at give Excel skylden, fordi man ikke kan finde ud af at bruge det.


Denne idé om autoformatering af tekst stinker langt væk af dårligt design. Den er et symptom på en syg tanke om at software skal gætte brugerens hensigt ud fra indtastning af en vilkårlig tekst. Hvis vi skal placere "skylden", så ligger den hos de software designere, som har fået den idé og implementeret den uden at overveje konsekvenserne.

  • 13
  • 4

Hvis vi skal placere "skylden", så ligger den hos de software designere, som har fået den idé og implementeret den uden at overveje konsekvenserne

Sǻ sandt, som det er skrevet.

Da vi for alvor begyndte at bruge computere i 1970erne, var det en nærmest religiøs ide, som blev banket ind i knolden på alle softwaredesignere, at menneskene skulle tænke, og at maskinerne skulle levere rutinearbejdet.

Den sygelige idé med at implementere mislykkede gæt om, hvad brugeren nok har tænkt sig at gøre, og hvad brugeren nok skal bruge data til, koster enorme mængder af kostbar tid til at overveje og eksperimentere med, hvordan et eller andet skodprogram måske omformaterer mine data, tid som i stedet skulle have være brugt til at tænke over resultater.

Den designer, som finder på at omformatere "Membrane-Associated Ring Finger (C3HC4) 1, E3 Ubiquitin Protein Ligase" til MARCH1 bør tvinges over i en anden karriere, f.eks. noget med en plasticpose og en cigaretskodopsamledims.

  • 7
  • 6

Jeg synes nogen af kommentarerne over drager den fejlagtige konklusion, at hvis man er forsker, så har man automatisk et stort kendskab til brugen af Excel og alle de finurligheder Microsoft har fundet på.

Ingeniører kan måske sidde og ryste på hovedet over dette (specielt hvis man er vokset op med Microsoft Office), men vi glemmer, at det ikke er alle som har brugt dette redskab siden gymnasiet og igennem en lang uddannelse. I mit daglige arbejde møder jeg en del, som ikke naturligt formår at sætte sig ind i hvordan software fungerer. Jeg kan ikke forestille mig andet end at dette også gør sig gældende i forskningsverdenen.

  • 6
  • 0

Jeg har mange gange været så heldig at Excell har gættet rigtigt når jeg har lavet en fejl i min indtastning, og det syns jeg er fint, men der har så sandelig også været eksempler på det modsatte.

For mig at se er den største fejl at der ikke er mulighed for at vælge de forskellige automatiske formateringer fra.

Så kunne forskerne bruge tiden på forskning istedet for Excell-gymnastik, og jeg kan stadig få rettet mine indtasntingsfejl, lige som vi helst vil.

  • 3
  • 0

Jeg er forsker - og jeg har brugt Excel i mange år. Men jeg kan godt genkende en fejl når et numerisk analyseresultat er OCT16....
Man kikker sine tal igennem for åbenlyse fejl, eller indbygger en kontrolsøjle (f.eks min og max). Det kan jo have vidtgående konsekvenser.

  • 1
  • 0

Jeg giver Albert Nielsen og Jørgen Henningsen helt ret.

Excel er efter min mening notorisk håbløst omkring dette. Jeg laver jævnligt noget, hvor jeg har csv filer som input, og både når man gerne vil have felter som f.eks. dato, eller når man ikke vil det er der faldgruber. Hvis excel taler engelsk men Windows har dansk tidsformat bliver f.eks. 15-oct-15 ikke til en dato, i ting som 10/11/12 kan man aldrig vide, hvad der er dag, måned og år, og at få en sekvens af cifre, f.eks. et telefonnummer uden mellemrum, til at blive en tekst (og ikke et tal) er også ret besværligt. Andre eksempler er at 23:13 bliver til et klokkeslet medens 24:15 bliver til et tidspunkt (1. jan 1900 kl. 00:15), 23:60 bliver til et tal, 24:60 bliver til en tekst. Og hvis man er i et skudår og Windows står til fransk bliver 29fev til en dato, ellers til en tekst.

Det er ikke nok, som Nicolai Knudsen skriver, at finde ud af, hvordan software fungerer, når det er SÅ komplet ugennemskueligt, hvordan det rent faktisk fungerer. Og find lige dokumentationen!

  • 9
  • 0

En endnu mere graverende fejl i Excel, som er håbløs at opdage, er komma-separering.

Vi arbejder i en international virksomhed, og når vi en sjælden gang er tvunget til at arbejde i Excel, er det et tilbagevendende problem at enkelte medarbejdere har opsat Windows til at bruge ',' som decimaltals operator (dansk standard). Selv vores automatiserede scripts, der læser Excel direkte, kan modtage en celle-værdi der burde have været '110.02' men bliver til '11002' hvis det lige er en forkert computer som kører scriptet.

  • 4
  • 0

Nu har jeg prøvet og prøvet og jeg kan altsså ikke få MARCH1 til at give andet i min celle end MARCH1 og Excel - det kære væsen - foreslår ikke nogen dato-tabel eller noget som helst iøvrigt.
Givet, jeg har også sat den op til stort set ingen form for autokorrektur eller AutoFormatAsYouType. Så jeg vil mene at det ganske fint kan slås fra.
Noget andet er et forskere åbenbart ikke ser deres resultater igennem. Det er nyt for mig.

Nøh, er der noget i Excel der irriterer mig i min hverdag hvor jeg bakser med KKS-numre, det er at dobbelt A (AA) konsekvent sorteres som et Å. På trods af engelske versioner af al software inklusive location set-up. Prøv selv at soreter flg: LAB05, LCA95, LBA10, LAA05. Det er plat umuligt at få LAA til at stå først i listen (eller sidst afh. asc/desc sortering)

Men ja, Excel's gætterier er ret håbløse som også Bjørn skriver ovenfor.

  • 1
  • 0

@Bjørn
Ja, den giver ganske rigtigt et "mar-01", men det var jo ikke det, man oprindeligt skulle skrive; det var jo MARCH1.

@Nicolai
Jeg har også en engelsk office version installeret + Win Location og sprog er sat til UK og engelsk. Hvad er dit setup siden det åbenbart lykkedes dig at sortere korrekt. Det vl jeg meget gerne vide.

  • 1
  • 0

Prøv selv at soreter flg: LAB05, LCA95, LBA10, LAA05. Det er plat umuligt at få LAA til at stå først i listen

https://snag.gy/utWRzT.jpg

Jeg har dog en engelsk version af Excel installeret, da jeg nægter at sætte mig ind i de danske funktioner og slet ikke de norske, hvor jeg arbejder.

Lidt sjov med datoer, hvor der er forskel på, hvornår der autoformateres:
https://snag.gy/nWrRzh.jpg

Der er også nogen, der snakker lidt om at kvalitetssikre sit arbejde. Det kan jeg egentlig kun være enig i, men hvis man importerer fx en kvart million inputs og det kun er en håndfuld af dem, som bliver påvirket af Excels autoformatering, så overrasker det mig ikke, hvis man overser det.

  • 1
  • 0

Nu har jeg prøvet og prøvet og jeg kan altsså ikke få MARCH1 til at give andet i min celle end MARCH1

Du har ret Ulf, og jeg tog fejl.

Når man læser artiklen i "Genome Biology" bliver det klart, at det er forskeren, og ikke Excel, der forkorter navnet på ‘Membrane-Associated Ring Finger (C3HC4) 1, E3 Ubiquitin Protein Ligase’, til MARCH1. Excel opfatter derefter MARCH1 som en dato.

Vi beklager den forringede kvalitet i forrige post.

  • 1
  • 0

Nøh, er der noget i Excel der irriterer mig i min hverdag hvor jeg bakser med KKS-numre, det er at dobbelt A (AA) konsekvent sorteres som et Å. På trods af engelske versioner af al software inklusive location set-up. Prøv selv at soreter flg: LAB05, LCA95, LBA10, LAA05. Det er plat umuligt at få LAA til at stå først i listen (eller sidst afh. asc/desc sortering)

Som med så mange andre udfordringer i Excel kan dit behov måske løses med en "hjælpekolonne".

Hvis du tilføjer nedenstående macro til dit ark og bruger den i en ny kolonne med inddata fra den kolonne du gerne vil sortere efter (dvs "=Xpand(B1)" for at hente data fra kolonne B), og derefter sorterer på hjælpekolonnen, burde du kunne opnå hvad du ønsker.

Den platfodede ide er, at indsætte mellemrum mellem hvert tegn, så du ikke bliver ramt af fortolkning af "dobbelt tegn". Hvis du også ønsker samme sortering af minuskler og versaler, kan du tilføje en "UCASE" af returværdien.

Ikke den smukkeste metode, men hvis hammeren virker... ;o)

Public Function Xpand(ByVal strIn As String) As String

Dim ix As Integer
Dim lstrOut As String

' NOTE:
' remove the underscore in "M_id" below before use!
' there is a problem including the text in the post without it...
For ix = 1 To Len(strIn)
lstrOut = lstrOut & M_id(strIn, ix, 1) & " "
Next ix

Xpand = lstrOut

End Function

  • 0
  • 0