Komma eller punktum er bare første forhindring når du skal indlæse tal fra tekst

Det tætteste, vi kommer på enighed om, hvordan vi skriver tal, er, at decimalerne skal markeres med enten et komma eller et punktum.

3.142 - er det pi med tre decimaler eller står der tretusindeethundredeogtoogfyrre?

De fleste, som har arbejdet med tal og computere er nok opmærksomme på, at deres danske matematikbog og computerterminalen ikke er helt enige om, hvilket tegn der skal markere skillepunktet mellem et heltal og dets decimaler. Men det er bare begyndelsen på problemerne med at fortolke tal.

Det er oplagt at antage, at der må være en SI eller ISO standard, og at det nok er amerikanerne, som igen er skøre og har valgt at bruge punktum i stedet for komma. Så enkelt er det imidlertid ikke.

Det nærmeste, vi kan komme på en form for videnskabelig konsensus, er en resolution fra den 22. konference om mål og vægt, som slår fast, at decimaler skal markeres med enten et punktum eller et komma. Så ingen hjælp fra videnskaben.

I Canada har det ført til, at normen er at bruge et punktum, når man skriver på engelsk, men et komma, når man skriver på fransk. I Schweiz er det almindeligt at bruge punktum, når man skriver beløb i schweizerfranc, men komma til alle andre tal.

Wikipedias liste viser en næsten ligelig fordeling på verdensdele og lande - dog med lidt flere lande, der bruger komma, men til gengæld flere mennesker, der bruger punktum.

Problemet er, at det derfor kræver, at man holder styr på, hvilket land et tal kommer fra, hvis man eksempelvis skal trække det ind fra en tekst i et stykke software.

Læs også: String eller Int? Script-smutter får Netto til at sende sms til forkerte numre

10,00,00,000 og 1,0000,0000

Selv et regneark er nødt til at holde styr på sprogindstillingerne for at undgå, at der opstår forvirring om komma og punktum, hvis arket åbnes i en udenlandsk version af programmet.

Decimalmarkøren er dog blot det første problem, man kan støde på. Den samme resolution fra de kloge folk, der holder styr på metersystemet, specificerer meget diplomatisk, at man aldrig skal bruge komma eller punktum til at markere grupper af cifre i et tal.

Det er almindelig praksis at øge læsbarheden af store heltal ved - på dansk - at tilføje et punktum mellem hver faktor 10³. Altså eksempelvis 100.000.000. På andre sprog er det almindeligt at skrive det som 100,000,000. Den korrekte måde at øge læsbarheden på i videnskabelige tekster er imidlertid 100 000 000, men det giver et nyt problem, når det overføres fra papir til digital.

For et mellemrum er ikke bare et mellemrum. Anbefalingen er, at man benytter et non-breaking space, altså et mellemrum, som ikke påvirkes af linjeskift. Dem er der mindst to af i Unicode, og det er oplagt at benytte U+202F i stedet for U+00A0.

Dermed er det ikke overstået, for jo, der er konsensus om at lave denne opdeling i grupper af tre cifre i et heltal, men så alligevel ikke. Blandt andet gør to lande med tilsammen mere end 2,5 milliarder indbyggere det lidt anderledes - men selvfølgelig ikke anderledes på den samme måde.

I Kina kan man støde på, at der er grupper af fire cifre i stedet. Så 100 millioner skrives som 1,0000,0000 - og helt enkelt er det så alligevel ikke, for forklaringen bag de fire cifre er, at kineserne har et ord (wàn på mandarin) for 10.000, så for dem giver det mening at tælle i titusinder. Men de har også et ord for 100 millioner (yì), så en milliard er ti hundredemillioner.

Forklaringen er næsten den samme i Indien, hvor der er ord for 100.000 (lakh) og for ti millioner (crore). Så i Indien skriver de hundrede millioner som ti timillioner, hvilket bliver til 10,00,00,000. Inderne sætter altså et komma for hvert to cifre - bortset fra de første tre cifre.

Komma og punktum for viderekomne

Så burde der være styr på, hvornår der sættes kommaer, punktum og mellemrum, men de er ikke de eneste tegn, der kan findes i tal. Der er en række andre tegn, som bruges i stedet for, men som heldigvis kun sjældent optræder elektronisk.

Eksempelvis kan man støde på brugen af apostroffer til at adskille grupper af cifre i større tal, så 100 millioner skrives 100'000'000,00. Det ville selvsagt give en ekstra udfordring for den, der skulle fortolke det i elektronisk form, hvis der optræder citationstegn i et tal, som normalt bruges til at markere start og afslutning på tekststrenge. C++ er dog i stand til at håndtere det, hvis man skulle støde på det.

Ovenstående ses blandt andet i håndskrift i Schweiz, og selvfølgelig kan man finde nærmest det modsatte, blot man tager til Spanien, hvor man i håndskrift kan støde på 100.000.000'00, hvor apostroffen altså markerer adskillelsen ved decimalerne.

Dertil kommer de mere eksotiske forskellige prikker, hvor den mest almindelige er den, der også bruges som gangetegn eller til prikproduktet i matematik. Af samme årsag er den ikke længere almindelig som decimalmarkør. Der findes også en mere højtflyvende prik ˙, som igen hovedsageligt ses i håndskrift i Italien.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (39)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Juul Mortensen

brug en double der holder tallet i to dele, heltal og decimaler og angiv tallet med et cifre i den første del og resten i decimaldelen gange 10 i en potens, så slipper man for de forskellige ønsker om tegne til at adskille heltal og decimaler samt til de tegn der skal øge læsbarheden :-)

  • 0
  • 0
Christian Nobel

.. ville være med på decimalkommaet (og det metriske system, og et ikke tåbeligt dato format, og og og...), så ville meget være vundet.

Især fordi at i vel alle databaser benyttes decimalpunktum, så man er nødt til at forholde sig til problematikken.

Hvis man i første omgang kunne enes om at "forbyde" brugen af grupperingstegn, så der kun var et ikke tal i strengen, som så altid markerede at hvad kom efter var decimaler, så ville vi være et skridt på vejen.

  • 4
  • 0
Hans Schou

og han læste denne artikel, ville han sige: Det kan ikke passe og det er ikke den første april i dag.

Iøvrigt bruger alle børnenes lommeregnere, også dem på apps, punktum som decimaladskiller. Så lad os bare blive ved det, og afskaffe Dansk Standard hvis der er sådan en.

  • 1
  • 0
Torben Mogensen Blogger

Inden vi slås om decimalkomma versus -punktum, kunne vi måske først blive enige om at bruge samme system for mål og vægt. Ja, USA, det er jer vi venter på.

MHT lommeregnere, så kan mange af dem indstilles til at vise decimalkomma i stedet for decimalpunktum (hvilket dog ikke ændrer tasten, der er et punktum uanset).

  • 1
  • 0
Christian Nobel

Om at afskaffe decimalkommaet? Slet ikke. Og tag semikolon som adskiller med i faldet.

På papir skriver mine børn stadig komma, så det er kun på blandede danske/udenlandske web-sider hvor de må døje med ikke at vide om det skal være komma eller punktum.

Har du læst artiklen?

Det er da langt mere komplekst end som så, og man kan jo ikke sige, at set her, ud fra mit navlepillersynspunkt så kan man bare lige....

Vi lever i en globaliseret verden, derfor er man nødt til at tænke globalt, og på en global målgruppe - og et forkert placeret komma kan faktisk have fatal betydning hvis vi løfter blikket lidt, og ikke kun tænker på underholdningsweb.

Om det så er en rund dut eller en aflang dut der udgår decimalkommaet er jeg sådan set ligeglad med, men der skal være et og kun et tegn som entydigt repræsenterer det, så det ikke er nødvendigt at gætte på hvad den anden part tror det kan være.

Og hvad er problemet med semikolon, hvis vi vel at mærke abstraher fra hele problematikken om at der bruges almindelige gængse legale skrifttegn i en anden kontekst til lave strengmarkering og karakteradskillelse?

  • 1
  • 1
Jesper Louis Andersen

Programmeringssproget OCaml har stjålet en god ide fra nogen af de ældre sprog (jeg kan ikke lige huske hvilket der er tale om på stående fod, men det går ret langt tilbage). Du kan simpelthen bare skrive:

# 1_000_000;;  
- : int = 1000000

Og det parses på oplagt vis. Ideen er at du indfører et helt andet tegn en de normale så du kan adskille cifre, uden at du kommer i karambolage med komma vs punktum for tegnsætning. Det er ikke en dårlig ide.

Jeg stemmer for at vi bare lærer verden at det er sådan man skriver tal fra nu af. Vi lærte stort set alle at bruge computere. Det er oplagt at mennesker også skal lære noget grundliggende programmering.

  • 1
  • 0
Keld Simonsen

En løsning, man kan komme langt med, er at når man gemmer tallene, så gemmer man også oplysninger om hvordan de er kodede. Det kan nemt gøres i regneark, dokumenter mv.

Jeg tror det er meget svært at udrydde de kulturelle forskelle, ligesom det er svært at få alle på kloden til at snakke Mandarin.

Der er faktisk internationale standarder, der fastlægger metoder for at bruge disse kulturelle konventioner, fx ISO 9945 POSIX, og ISO 30112 om internationalisering, og de allerfleste programmeringssprog kan benytte disse informationer. Informationen om de kulturelle konventioner, der er brugt til formattering af tallene, ligger i såkalte localer. Jeg har dog ikke info om at denne localeinformation bliver gemt sammen med regneark eller dokumenter iøvrigt, men sproget bliver som regel gemt, og sproget bestemmer ofte de talformatteringsregler, der er brugt.

Jeg er selv redaktør af ISO-standarden 30112, som nok er noget af det mest udførlige mht. at angive forskellige måder at formatere tal på. Denne standard er under revision, så forslag modtages gerne.

  • 2
  • 0
Christian Schmidt Blogger

Jeg er selv redaktør af ISO-standarden 30112, som nok er noget af det mest udførlige mht. at angive forskellige måder at formatere tal på. Denne standard er under revision, så forslag modtages gerne.

Er der et sted, man kan læse denne standard uden at skulle bløde 1300 kr.?

En anden standard er CLDR - Unicode Common Locale Data Repository, der rummer formateringsregler for tal (også i andre talsystemer), beløb, datoer (herunder ikke-gregorianske kalendere, fx jødisk, buddhistisk osv.), tidszoner mv., oversættelser af landenavne, valutaer mv. Se fx den danske locale.

  • 0
  • 0
Jesper Louis Andersen

En bedre løsning er at finde et ellers ubrugt Unicode-tegn til decimalkomma, gemme tal uden tusinderadskillelse og med det valgte tegn i stedet for decimalkomma/-punktum. Lokale kulturelle normer kan så bruges til at vise og indlæse tal -- men den interne repræsentation bør være uafhængig af disse.

Dette er generelt godt systemdesign. Den interne repræsentation bør være uafhængig af formatering. Formatering tilføjes efterfølgende når visning er påkrævet. I moderne systemer er der ikke nogen undskyldning fordi formateringskode er en lille del af systemet. Og instruktioner er nærmest gratis fordi du alligevel venter på at hive data ind fra memory det meste af tiden.

For kommatal bør man også overveje om en IEEE754 Double floating point er tilstrækkeligt til at gemme data med. Eller om tallet bør gemmes brudt i en tupel bestående af de to dele før og efter kommaet. Hvis du sidder med noget data gemt i SQL er typerne DECIMAL/NUMERIC ofte de rigtige at vælge hvis man ønsker en eksakt repræsentation.

  • 2
  • 0
Christian Schmidt Blogger

Denne standard er under revision, så forslag modtages gerne.

Eksemplet på side 138 er forkert. currency_symbol ""

Skal være: currency_symbol "<.>"

Dette blev rettet i glibc for et par år siden: https://sourceware.org/bugzilla/show_bug.cgi?id=17692

(jeg ved godt, at dette forum ikke er rette sted at rapportere fejl, så det er blot tænkt som et illustrativt eksempel på standardiseringsarbejdet :-)

  • 2
  • 0
Michael T. Jensen

skal selv vælge om de vil benytte "." eller "," til decimaladskillelse - de skal blot være konsekvente. Det giver bare lidt udfordringer, når eksempelvis Word med Wordmat benytter "," mens geometriprogrammet Geogebra benytter ".".

Og hvordan formateres et koordinatsæt, hvor x og/eller y-værdierne ikke er heltal? Fortolk lige på (2,2,3)... Så er der nogen, der benytter ";" til at adskille x og y-værdien, men det er jo heller ikke kosher. Ovenstående eksempel bliver kun marginalt bedre af at skrive (2.2,3), med mindre eleven har været meget konsekvent igennem sin opgave.

Det er bare lidt lettere at lade eleverne benytte "." til decimaladskillelse ;-)

  • 2
  • 1
Torben Mogensen Blogger

Jeg tror at tal repræsenteres binært eller på en standardiseret måde, uafhængig af formatteringen i mange programmer, inkl regneark, og så er der for hvert felt tilknyttet en formateringsbeskrivelse.

Hvis bare det var så nemt. Heltal har forskellig antal bits -- i dag typisk 32 eller 64 bits, men 16, 31 og 63 bits findes også, og i nogle signalprocessorer bruges 24 eller 48 bits. Nogle sprog (f.eks. COBOL) bruger decimalrepræsentation og ikke binær repræsentation. Til kommatal bruger de fleste sprog og processorer IEEE repræsentation, men selv her er der flere muligheder: 32 bit, 64 bit og 128 bit repræsentationer. Endvidere bruger nogle signalprocessorer og ældre arkitekturer (mainframes) helt andre formater.

Men det vigtige er (i de fleste tilfælde) ikke at standardisere interne repræsentationer. Det er formater til kommunikation mellem maskiner, der skal standardiseres. Når tal (eller andet data) skal vises til eller skrives af mennesker, kan der bruges alskens lokale konventioner -- sålænge brugerne er klare over, hvilke konventioner, der bruges i de enkelte tilfælde.

Et enkelt tilfælde, hvor det giver god mening at standardisere de interne repræsentationer, er floating-point tal. Her blev IEEE standarden indført for at sikre, at beregninger udføres med samme præcision og afrundingsregler på alle maskiner, sådan at beregninger på to forskellige maskiner ikke pludselig afviger på fjerde ciffer.

  • 1
  • 0
Michael Cederberg

For kommatal bør man også overveje om en IEEE754 Double floating point er tilstrækkeligt til at gemme data med.

Problemet er at IEEE754 repræsentationen er at det er en base 2 repræsentation. Det betyder at man fx ikke kan repræsentere tal som 0.1 præcist. Det er således tæt ved ubrugeligt i situationer hvor man skal lave præcis aritmetik på tal som er indtastet af mennesker (men måske findes der mennesker der hellere vil indtaste floating point tal binært?).

Nogle sprog (f.eks. COBOL) bruger decimalrepræsentation og ikke binær repræsentation.

.NET har både base 2 floating point tal (double) og base 10 floating point (decimal) datatyper. Det er ret fornuftigt have begge dele og ikke blot vælge en af dem som normen ellers er. Desværre er der ingen udbredt standard for base 10 floating point.

Ovenstående er selvfølgeligt ligegyldigt i situationer hvor man sampler virkligheden og hvor tallet i forvejen blot er en approximation til den faktiske værdi. Men i situationer hvor man fx snakker penge så er det ekstremt problematisk at sprog som C++ og Java ikke har nogen effektiv base 10 floating point representation.

  • 1
  • 1
Torben T. Nielsen

Sidst jeg var i Canada var jeg nær ikke kommet hjem med ene min datter. Udløbs-datoen i passet var skrevet som DD/MM/YY, men blev læst som MM/DD/YY af personalet i Vancouver lufthavn (begge endte med at være valide datoer).

Heldigvis kunne jeg med datoen i mit pas påvise at der måtte menes DD/MM/YY idet udløbsdatoen i mit pas ikke var en gyldig dato i MM/DD/YY formatet.

  • 3
  • 0
Rolf Andersen

Nu tjekkede jeg lige mit pas udstedt af Den Europæiske Union, Danmark, Københavns Kommune, og der er datoformatet DD MM YY (11 06 19), så man har ikke engang det lille hint om de forskellige skilletegn: . (punktum), eller / (skråstreg) eller - (bindestreg)

... der bliver bare brugt mellemrum, så EU overholder altså ikke selv EU's egen vejledning om datoformater, som jeg linkede til ovenfor, eller bare en ISO-standard ;)

  • 1
  • 0
Torben Mogensen Blogger

Men i situationer hvor man fx snakker penge så er det ekstremt problematisk at sprog som C++ og Java ikke har nogen effektiv base 10 floating point representation.

Til pengebeløb bør man slet ikke bruge floating point, men i stedet fixed-point (men, ja, i decimal). Endvidere har forskellige lande forskellige standarder for, hvordan beløb afrundes, så man kan ikke bare bruge en standardiseret afrundingsregel.

  • 0
  • 0
Marc Barnholdt

Hvad med konceptet om at én million kan skrives som 1e6, hvor det er et ti-tals system, men hvis man skriver 010 (i nogle sprog) så er det 8 fordi det er en oktal og 0x10 er 16 fordi det pludselig er 16 tals systemet.

og når man så får et regnestykke som (0x10/010)*1e6 som retteligt bør være to millioner, så bliver det rigtig svært at læse/parse.

  • 0
  • 1
Michael Cederberg

Til pengebeløb bør man slet ikke bruge floating point, men i stedet fixed-point (men, ja, i decimal).

Nogen gange er man nødt til at bruge floating point fx hvis man har meget store antal og meget små (eller præcise) priser. I så fald kan det være svært at have tilstrækkelig range på et fixpoint tal.

Endvidere har forskellige lande forskellige standarder for, hvordan beløb afrundes, så man kan ikke bare bruge en standardiseret afrundingsregel.

Automatisk afrunding skal man undgå i disse tilfælde - ellers kan man ligeså godt bruge doubles. Man skal vide hvad man gør med floating point tal - holde styr på tallenes størrelse. Ligegyldigt hvilken base det handler om. Men med fixedpoint skal man passe på overflow - endnu er næsten altid endnu værre.

  • 0
  • 1
Christian Nobel

Du skal betale for at se selve standarden ISo 30112

Jeg har altid undret mig over dette.

Hos DS skal man betale over 1000 kr for en nogen gange overmåde mager standard - man skulle tro at hvis man gerne ville have folk til at benytte en standard, så burde det være noget der lå i det fri, i stedet for en ruinerende historie, især hvis man har brug for flere standarder.

At DS så løfter det op på en nærmest kunstnerisk plan, som var det at beskytte kronjuvelerne, med Adobe inficeret DRM, specielle load moduler, låste PDF'er, og hvad har vi, gør det jo helt grotesk.

For hvad er meningen med en standard?

  • 2
  • 0
Log ind eller Opret konto for at kommentere