Microsoft erkender fejl i Excel

I sin officielle Excel-blog erkender Microsoft nu, at Excel 2007 viser resultatet af regnestykker, hvis sum ligger inden for bestemte intervaller, forkert.

Det er en fejl i Excel, som får regnearkene til at vise forkerte resultater. Det erkendte Microsoft i nat dansk tid i sin officielle blog om kontorprogrammet.

Ifølge David Gainer, der er Group Manager for Excel, er der tale om en displayfejl og ikke en regnefejl.

David Gainer forklarer, at Excel 2007 kan lagre 9,214*10^18 flydende tal. Fejlen vedrører et meget beskedent antal af dem: Seks tal i intervallet 65534,99999999995 og 65535, samt de seks tal i intervallet mellem 65535,99999999995 og 65536.

Når Excel 2007 skal vise et resultat af regnestykker, hvis sum giver et af de berørte tal, skriver programmet i stedet 100000.

Selv om Excel 2007 viser et forkert tal, er det dog det rigtige tal, der er lagret i cellen, så hvis A1 indeholder ?=85077,1? og A2 indeholder ?=A12? så vil A2 vise det rigtige svar 131.070.

Fejlen er, skriver David Gainer, opstået, da der blev lavet ændringer i Excel-beregningslogikken i forbindelse med Office 2007. Fejlen findes derfor ikke i tidligere versioner af Excel.

Ifølge Excel-bloggen arbejder Microsoft på en rettelse af fejlen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Poul-Henning Kamp Blogger

Når jeg bliver præsenteret for fejlbeskrivelser af denne art, så plejer jeg at udføre det jeg ubeskedent er begyndt at kalde "PH-testen":

Hvis jeg blev bedt om at implementere ting på denne måde, hvorledes ville jeg så gøre det ?

Det er klart at der er noget 2^16 involveret, men har de virkelig heltalsdelen som et 16 bit heltal og så kommadelen som, ja hvad ?

Det kan ikke være en 32bit binær kommadel, det ville ikke give 12 ciffrer...

Hvordan ville I implementere denne fejl ?

Poul-Henning

  • 0
  • 0
Poul-Henning Kamp Blogger

Det var ikke hvordan du ville gøre det rigtigt, PHtesten er hvordan du ville gøre det forkert på nøjagtig den måde som fejlen implementerer.

Enhver der kan tænke kan gøre det rigtigt, men at implementere en sådan fejl kræver ægte talent :-)

Poul-Henning

  • 0
  • 0
Christian Nobel

Denne artikel skriver:

"Fejlen er, skriver David Gainer, opstået, da der blev lavet ændringer i Excel-beregningslogikken i forbindelse med Office 2007. Fejlen findes derfor ikke i tidligere versioner af Excel."

Denne artikel (http://www.version2.dk/artikel/4192) skriver:

"Microsoft har tidligere rapporteret om denne fejl i forbindelse med Office 95, og tilsyneladende findes den ikke i officepakkerne 2000 og 2003, men nu fejlen dukket op igen i Office 2007."

Hvad skal man så tro på?

/Christian

  • 0
  • 0
Peter Holm Jensen

Øh med med gnumeric var bare fordi jeg lige ville nævne et godt alternativ, men apropos PHtesten så mindes jeg de glade dage i begyndelsen af 90'erne hvor borland havde lavet en assembler til x86 og hvor man kunne sætte et flag så den enten gjorde det rigtige eller som microsofts assembler - det er da PHtesten i praksis.

Peter

  • 0
  • 0
Claus Dræby

Jeg har både overfor denne fejl, og andre fejl jeg har oplevet i office pakken, konstateret at MS bare er bedre til at kode end jeg er.

Jeg kan ikke finde en lille stump kode der implementerer den ovennævnte fejl. Jeg er ikke engang sikker på at jeg kan gætte den bagvedliggende datamodel.

Det minder lidt om Fermats berømte sidste teorem, hvis bevis han skulle have syntes var lidt for stort til at stå i margen af et brev. Det moderne bevis viste sig at være kæmpestort. Så måske er det også tusindvis af sider kode, som undtagelser kan skjules i, der skal til for knække denne nød.

Men tak for at du har leveret et navn til teknikken Poul-Henning!

Claus

  • 0
  • 0
Død Profil

Udover at det ikke giver mening med 6 tal i hvert af de intervaller han snakker om - nærmere uendeligt uendeligt - så synes jeg at huske noget om noget så simpelt som præsentation af 32-bit tal hvor man ønskede 2x5 karakterer output, og hvor man skulle fiks-fakse lidt for at få 65535..99999 til at passe, og hvor man kunne ende med 100000 hvis man lige skrev 65536 i stedet for 65535 i sine udregninger. Hvordan præcist algoritmen var er dog snart 10 år tilbage og lidt blurry her om morgenen :-)

Mvh,
Søren

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