Videnskabelige rapporter indeholder fejl på grund af Excel

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

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

Det er fordi din Excel er dansk! Der hvor problemet er, bruges nok en engelsksproget Excel som tolker 'MARCH1' som 1. marts, fuldstændig ligesom din tolker 'MARTS1' som 1. marts.

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.

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

Ligesom i Word mener jeg du kan sætte sproget i hvert enkelt regneark. Så hvis du har dansk support i Office (af hensyn til word) er det muligt at dine ark står til dansk. Tilsvarende med sorteringsproblemet

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

Der er imidlertid tale om navnet på ‘Membrane-Associated Ring Finger (C3HC4) 1, E3 Ubiquitin Protein Ligase’, som bliver forkortet til MARCH1.

Diverse regneark har da også tit snydt mig, meeen det er altså noget man opdager, inden man offentliggør ting, eller hvad?

Hvad er dit setup siden det åbenbart lykkedes dig at sortere korrekt. Det vl jeg meget gerne vide.

@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.

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.

Prøv "marts1"!

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.

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.

Men bare noget, som anvender Excel forkert?

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!

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.

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.

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.

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

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.

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.

...at brugerne ikke sætter sig ind dets virkemåde. De beskrevne problemer er opstået pga amatør agtig betjening. Det kan da ikke passe at et sådant tema fortjener spalteplads på ing.dk

R er nok mere egnet.https://en.wikipedia.org/wiki/Comparison_of_statistical_packageshttps://en.wikipedia.org/wiki/R_(programming_language)https://cran.r-project.org/

Regneark har sine begrænsninger.

Sig mig.... ser de ikke deres data igennem inden de publiceres??

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.

Enig!

Artiklen og eller "forskerne" er til grin.

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.

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"....

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.

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.