mboost-dp1
Microsoft
#OFFtopic
BTW - hvordan kan det være jeg ikke kan finde min "Vurdér indlæg"-dimmerknap?
Den er helt væk?!
BTW - hvordan kan det være jeg ikke kan finde min "Vurdér indlæg"-dimmerknap?
Den er helt væk?!
Er det mon pga. bagudkompatibiliteten i OOXML at vi ser fejl som denne?
Så vidt jeg har læst mig frem til er der uendeligt mange "hacks" i specifikationerne der kunne medføre noget der ligner dette.
Så vidt jeg har læst mig frem til er der uendeligt mange "hacks" i specifikationerne der kunne medføre noget der ligner dette.
det der er jo dumt.. at man laver samme fejl to gange.. Men alligevel... så burde det mennesket opdage at den laver fejl.. det kan man jo se på regne stykket.. Men så igen.. hvis man har rigtig mange regnestykker blandet sammen.. så opdager man det ikke.. måske sku programørene tage sig lidt sammen,,
hehe det er åbenbart kun excel 2007 der har denne fejl for windows lommeregner og openoffice calc 2.2 og min alm lommeregner får tallet 65535
hvor er det skidt. Jeg ved godt det er nemt at sige "de kunne jo bare have ..." men man skulle tro de havde gjort deres for at udradere fejlen for 12 år siden så man aldrig så den igen...
Hvem bruger Excel til noget vigtigt ? såsom regnskaber og statistik ?
Jeg kan ikke forestille mig at et firma med en omsætning hvor en halv milliard kunne bliver overset, ville bruge excel, hvis de gør burde de straffes med en våd søndags berlinger.
Jeg kan ikke forestille mig at et firma med en omsætning hvor en halv milliard kunne bliver overset, ville bruge excel, hvis de gør burde de straffes med en våd søndags berlinger.
Afrundingsfejl er et stort problem i mange applikationer, og kan håndteres på endnu flere måder. Der er efterhånden skrevet en del specialer om dette emne.
Har ikke undersøgt det nøjere, men jeg tror fejlen i Excel skyldes et overflow i en variabel på stacken. Dette burde selvfølgelig ikke kunne ske, og slet ikke to gange. Et eller andet sted er det gået galt i dokumentationen da fejlen blev rettet første gang.
I administrations- og regnskabsbranchen er Excel MEGET udbredt.
Har ikke undersøgt det nøjere, men jeg tror fejlen i Excel skyldes et overflow i en variabel på stacken. Dette burde selvfølgelig ikke kunne ske, og slet ikke to gange. Et eller andet sted er det gået galt i dokumentationen da fejlen blev rettet første gang.
I administrations- og regnskabsbranchen er Excel MEGET udbredt.
Det er ellers noget af en grum fejl. Er det ikke bare endnu et bevis på, at man altid skal vente lidt med at opgradere til det nyeste software...?
[indsæt rant om hvor godt OpenOffice er]
Sorry, kunne ikke lade være :p
[indsæt rant om hvor godt OpenOffice er]
Sorry, kunne ikke lade være :p
En yderligere interessant ting i denne sag, er hvordan fejlen i det hele taget opstår? Det må jo næsten have noget at gøre med et overflow, men så vidt jeg ved, så kan en 16 bit int indeholde tallet 65536 og altså også tallet 65535. ??
Måske har de indsat en "if" i koden:
Ja, det var en fejl ... jeg fortæller hele tiden mine medarbejdere, at de ikke skal indsætte lige netop den line!
:P
Måske har de indsat en "if" i koden:
if(numberA == 850 && numberB == 77.1) return 100000;
Ja, det var en fejl ... jeg fortæller hele tiden mine medarbejdere, at de ikke skal indsætte lige netop den line!
:P
#9 Vi bruger excel til at opstille regnskab i samtlige firmaer vi stiller regnskab op for så jo jeg vil nu sige det er meget udbredt.
Man bruger det selvfølgelig dog kun til fremvisnings delen - c5 osv har jo de rigtige tal gemt.
Derudover så var det jo hellere ikke excel der var skyld i fejlen på den halve milliard...
Man bruger det selvfølgelig dog kun til fremvisnings delen - c5 osv har jo de rigtige tal gemt.
Derudover så var det jo hellere ikke excel der var skyld i fejlen på den halve milliard...
Lidt Excel 2007:
850 77,05 65492,5
850 77,06 65501
850 77,07 65509,5
850 77,08 65518
850 77,09 65526,5
850 77,1 100000 <---- Hahaha
850 77,11 65543,5
850 77,12 65552
850 77,13 65560,5
850 77,14 65569
850 77,15 65577,5
Bedste WTF i meget lang tid :D Fantastisk!!!
850 77,05 65492,5
850 77,06 65501
850 77,07 65509,5
850 77,08 65518
850 77,09 65526,5
850 77,1 100000 <---- Hahaha
850 77,11 65543,5
850 77,12 65552
850 77,13 65560,5
850 77,14 65569
850 77,15 65577,5
Bedste WTF i meget lang tid :D Fantastisk!!!
Ganske imponerende...
Det gør jo en del ved troværdigheden af sådan et program.
Gad vide hvor mange flere fejl Excel og andre Microsoft-programmer indeholder af den type og kaliber.
Man skulle jo mene, at dette er så grundliggende en vigtig og basal funktion, at der bare ikke må indtræffe sådanne fejl. Ikke i 1995, og da slet ikke igen 12 år senere!
Pinligt! Det er vist det ord jeg finder mest passende :)
Det gør jo en del ved troværdigheden af sådan et program.
Gad vide hvor mange flere fejl Excel og andre Microsoft-programmer indeholder af den type og kaliber.
Man skulle jo mene, at dette er så grundliggende en vigtig og basal funktion, at der bare ikke må indtræffe sådanne fejl. Ikke i 1995, og da slet ikke igen 12 år senere!
Pinligt! Det er vist det ord jeg finder mest passende :)
Microsoft har "selvfølgelig" indrømmet fejlen, og man kan læse meget mere her på deres officielle blog.
#25
det har jeg godt forstået. Men vi har begge ret. Du siger at man skal vente med at opgradere til office 2007 da det altid er en god ide at vente til de værste fejl er fjernet. Men tænk hvis man statid sidder med office 95, og tænker, nu må alle fejl da være væk, jeg opgraderer. ha ha
see my point??
det har jeg godt forstået. Men vi har begge ret. Du siger at man skal vente med at opgradere til office 2007 da det altid er en god ide at vente til de værste fejl er fjernet. Men tænk hvis man statid sidder med office 95, og tænker, nu må alle fejl da være væk, jeg opgraderer. ha ha
see my point??
#28
Det var vist ikke mig der skrev det du nu kommenterer på ;)
Men for at give mit besyv med på jeres interne diskussion, så er der jo både fordele og ulemper ved at opgradere til seneste version af et givent program. Det kan løse mangler fra den forrige version. Det kan gøre din hverdag nemmere. Risikoen ved at bruge noget der ikke er testet igennem længere tid er som altid, at der er chance for at du møde såkaldte børnesygdomme.
Firmaer der bruger programmerne professionelt skal selvfølgelig være meget påpasselige, og de fleste har da også en klar strategi for udrulning af nye versioner - og endda også på update-niveau.
Men det er jo nærmest "stating the obvious"...
My 2 cents :)
Det var vist ikke mig der skrev det du nu kommenterer på ;)
Men for at give mit besyv med på jeres interne diskussion, så er der jo både fordele og ulemper ved at opgradere til seneste version af et givent program. Det kan løse mangler fra den forrige version. Det kan gøre din hverdag nemmere. Risikoen ved at bruge noget der ikke er testet igennem længere tid er som altid, at der er chance for at du møde såkaldte børnesygdomme.
Firmaer der bruger programmerne professionelt skal selvfølgelig være meget påpasselige, og de fleste har da også en klar strategi for udrulning af nye versioner - og endda også på update-niveau.
Men det er jo nærmest "stating the obvious"...
My 2 cents :)
Kald det spam:
0,31875 205600 100000
0,6375 102800 100000
1,275 51400 100000
2,55 25700 100000
5,1 12850 100000
10,2 6425 100000
20,4 3212,5 100000
40,8 1606,25 100000
81,6 803,125 100000
163,2 401,5625 100000
326,4 200,78125 100000
652,8 100,390625 100000
1305,6 50,1953125 100000
2611,2 25,09765625 100000
5222,4 12,54882813 100000
10444,8 6,274414063 100000
20889,6 3,137207031 100000
41779,2 1,568603516 100000
83558,4 0,784301758 100000
167116,8 0,392150879 100000
334233,6 0,196075439 100000
668467,2 0,09803772 100000
1336934,4 0,04901886 100000
2673868,8 0,02450943 100000
5347737,6 0,012254715 100000
10695475,2 0,006127357 100000
21390950,4 0,003063679 100000
0,31875 205600 100000
0,6375 102800 100000
1,275 51400 100000
2,55 25700 100000
5,1 12850 100000
10,2 6425 100000
20,4 3212,5 100000
40,8 1606,25 100000
81,6 803,125 100000
163,2 401,5625 100000
326,4 200,78125 100000
652,8 100,390625 100000
1305,6 50,1953125 100000
2611,2 25,09765625 100000
5222,4 12,54882813 100000
10444,8 6,274414063 100000
20889,6 3,137207031 100000
41779,2 1,568603516 100000
83558,4 0,784301758 100000
167116,8 0,392150879 100000
334233,6 0,196075439 100000
668467,2 0,09803772 100000
1336934,4 0,04901886 100000
2673868,8 0,02450943 100000
5347737,6 0,012254715 100000
10695475,2 0,006127357 100000
21390950,4 0,003063679 100000
this is an issue in a function that puts numbers in cells, so the values in Excel's memory are actually correct. Imagine A1 contains =77.1*850 ... Excel actually calculates the correct answer, and you can see that if you use VBA to check the value for A1 - it will be 65535. But in the function that takes that value and formats it to be displayed on the screen, for the values described above, there is a bug. Any calculations based off that cell will be accurate too. Hope that helps.
Hmm synes lidt det beviser at Microsoft gør mere for at lave tiltag der gør folk interesserede i deres produkter fremfor at sørge for at den egentlige funktionalitet er ok.
Nogen må undre sig over hvad man dog skal med et tal som 65535, og hvorfor man ikke bare kan smide det ud af talrækken og løser problemet.
* Højest opnålige rating i Dragon Warrior.
* Maximum antal items i Lineage 2.
* Størst muligt antal penge båret i Phantasy Star.
* Højest opnålige pointtal i Star Wars: TIE Fighter.
* Det højeste portnummer i TCP og UDP protokollerne.
* Det højeste antal deltagere i mange chatgrupper.
* Det højeste antal rækker i Microsoft Excel 2003.
#38
Når man ser på alle disse indicier, er det meget vel at Microsoft har gået ud fra, at 2^16-1 simpelt hen er det største tal i Verden, og de har så ville gøre det endnu mere tydeligt over for deres kunder ved at skrive det som 100.000.
* Højest opnålige rating i Dragon Warrior.
* Maximum antal items i Lineage 2.
* Størst muligt antal penge båret i Phantasy Star.
* Højest opnålige pointtal i Star Wars: TIE Fighter.
* Det højeste portnummer i TCP og UDP protokollerne.
* Det højeste antal deltagere i mange chatgrupper.
* Det højeste antal rækker i Microsoft Excel 2003.
#38
Når man ser på alle disse indicier, er det meget vel at Microsoft har gået ud fra, at 2^16-1 simpelt hen er det største tal i Verden, og de har så ville gøre det endnu mere tydeligt over for deres kunder ved at skrive det som 100.000.
Further testing showed a similar phenomenon with 65,536 as well.
Hvis du lægger 2 til tallet i stedet for 1, vil tallet blive vist korrekt.
Der er da intet mærkeligt i den fejl!
De startede jo på Longhorn, men besluttede så efter nogle år at smide alt de havde programmeret ud og starte på en frisk med Vista.
De har jo bare gjort det samme med Office 2007.
Der er sikkert en chef som har sagt:
Ud med alt koden til Office 2003 inklusiv fejlrettelser, vi starter på en frisk og programmerer det hele fra bunden af, så bliver sikkerheden bedre og vi kan opnå et godt ry softwarebranchen.
I virkeligheden tog de Office 95 op af skuffen og gav den en ny brugerflade - Det har vi beviset på nu :-D
De startede jo på Longhorn, men besluttede så efter nogle år at smide alt de havde programmeret ud og starte på en frisk med Vista.
De har jo bare gjort det samme med Office 2007.
Der er sikkert en chef som har sagt:
Ud med alt koden til Office 2003 inklusiv fejlrettelser, vi starter på en frisk og programmerer det hele fra bunden af, så bliver sikkerheden bedre og vi kan opnå et godt ry softwarebranchen.
I virkeligheden tog de Office 95 op af skuffen og gav den en ny brugerflade - Det har vi beviset på nu :-D
#38
Helt enig, den minimale testning man bør lave når man udsender et produkt man må forvente rammer knap en milliard brugere er en fuld test af inputs med et rimeligt antal decimaler fra 0 til hvor langt et skript nu kan komme på et par måneder.
Dvs. få en anden programmør til at designe et stykke software til (alene) at lave de samme beregninger som office gør, lav udregniingerne og sammenlign dem med office. Det er sådan en simpel test, og hver gang der er en modsætning så gå ind og sammenlign resultatet og vær sikker på at Excel har ret.
Det her er ganske enkelt latterligt, det beviser klart at Microsofts test afdeling har fejlet.
Offtopic:
Nu har jeg tilfældigvis lagt mærke til Diskys aktivitet i den her tråd, prøv at tjek den, han indsender ikke indlæg, men han har tydeligvist læst tråden godt igennem, for der bliver godt nok evalueret... Mit spørgsmål er, hvorfor føler han et behov for åbenbart at forsvare Microosfts ære, i en sag hvor der ingen er at forsvare.
Det her er en kæmpe fejl, og den eneste måde at løse den er at rette fejlen og udsende en undskyldning, for der er INGEN grund til at et produkt på det niveau bør have den slags fejl, især ikke med det prisskilt.
Helt enig, den minimale testning man bør lave når man udsender et produkt man må forvente rammer knap en milliard brugere er en fuld test af inputs med et rimeligt antal decimaler fra 0 til hvor langt et skript nu kan komme på et par måneder.
Dvs. få en anden programmør til at designe et stykke software til (alene) at lave de samme beregninger som office gør, lav udregniingerne og sammenlign dem med office. Det er sådan en simpel test, og hver gang der er en modsætning så gå ind og sammenlign resultatet og vær sikker på at Excel har ret.
Det her er ganske enkelt latterligt, det beviser klart at Microsofts test afdeling har fejlet.
Offtopic:
Nu har jeg tilfældigvis lagt mærke til Diskys aktivitet i den her tråd, prøv at tjek den, han indsender ikke indlæg, men han har tydeligvist læst tråden godt igennem, for der bliver godt nok evalueret... Mit spørgsmål er, hvorfor føler han et behov for åbenbart at forsvare Microosfts ære, i en sag hvor der ingen er at forsvare.
Det her er en kæmpe fejl, og den eneste måde at løse den er at rette fejlen og udsende en undskyldning, for der er INGEN grund til at et produkt på det niveau bør have den slags fejl, især ikke med det prisskilt.
SmackedFly:
Ikke for at brokke mig vildt over din testmetode, men ville en lidt mere effektiv test ikke være på sin plads? Dvs. hvor du tester grænseværdier som: limit-1, limit, limit+1, -1, 0, 1 og ellers gentage testen for alle datatyper der anvendes i det berørte område (dvs. hvis man internt bruger uint16 tester man naturligvis også med in16, uint32 osv.). På den måde kan man nøjes med en brøkdel af testene men afsløre de allerfleste fejl.
Ontopic:
Det er en brøler der bare ikke må ske, men som desværre kan ske. Det der undre mig, er at det er en floating point operation der er FUBAR. Normalt ville man lade det valgte sprog implementere operationen (af netop denne grund).
En ting der bare gør det endnu mere underligt: ROUND() og "+" (sikkert flere operationer) ændre hukommelsesområdet til 100.000 (ifølge kommentarer i den officelle blog), mens "-" ikke medfører denne overførsel af værdier, så noget kunne tyde på at Excel bruger sin egen implementation af noget floating point beregning med udskiftning af underliggende datastrukturer.. wierd at best :-/
Ikke for at brokke mig vildt over din testmetode, men ville en lidt mere effektiv test ikke være på sin plads? Dvs. hvor du tester grænseværdier som: limit-1, limit, limit+1, -1, 0, 1 og ellers gentage testen for alle datatyper der anvendes i det berørte område (dvs. hvis man internt bruger uint16 tester man naturligvis også med in16, uint32 osv.). På den måde kan man nøjes med en brøkdel af testene men afsløre de allerfleste fejl.
Ontopic:
Det er en brøler der bare ikke må ske, men som desværre kan ske. Det der undre mig, er at det er en floating point operation der er FUBAR. Normalt ville man lade det valgte sprog implementere operationen (af netop denne grund).
En ting der bare gør det endnu mere underligt: ROUND() og "+" (sikkert flere operationer) ændre hukommelsesområdet til 100.000 (ifølge kommentarer i den officelle blog), mens "-" ikke medfører denne overførsel af værdier, så noget kunne tyde på at Excel bruger sin egen implementation af noget floating point beregning med udskiftning af underliggende datastrukturer.. wierd at best :-/
#44
Absolut, hvis det var en kursusopgave i algoritmik ville det være rigeligt. Vi er helt enige i at der er bedre testmetoder hvis tid er en faktor, men med et stykke software der tilbringer næsten et halvt år i beta og RC stadie, hvorfor skulle man så ikke gå længere.
Du har dog ret, det er selvfølgelig grænsetilfældene der er afgørende, problemet med at teste efter grænsetilfælde er at man jo stadig lige først skal udtænke hvad der er grænsetilfælde.
Jeg kunne iøvrigt ikke være mere enig i det du siger om at bruge sprogets funktioner til at implementere det, hvorfor i alverden lave sine egne datatyper, medmindre man selvfølgelig skal bruge datatyper af en størrelse som sproget ikke kan håndtere uden modifikationer.
Absolut, hvis det var en kursusopgave i algoritmik ville det være rigeligt. Vi er helt enige i at der er bedre testmetoder hvis tid er en faktor, men med et stykke software der tilbringer næsten et halvt år i beta og RC stadie, hvorfor skulle man så ikke gå længere.
Du har dog ret, det er selvfølgelig grænsetilfældene der er afgørende, problemet med at teste efter grænsetilfælde er at man jo stadig lige først skal udtænke hvad der er grænsetilfælde.
Jeg kunne iøvrigt ikke være mere enig i det du siger om at bruge sprogets funktioner til at implementere det, hvorfor i alverden lave sine egne datatyper, medmindre man selvfølgelig skal bruge datatyper af en størrelse som sproget ikke kan håndtere uden modifikationer.
i alle sammenhænge er fejl ikke et problem fordi de opstår eller er blevet lavet.
Det interessante er hvad man gør for at rette op på fejlen.
Det interessante er hvad man gør for at rette op på fejlen.
En anden sjov ting at lægge mærke til er hvis du skriver =4,1-4
Det burde jo give 0,1 og ikke andet!
Men sætter du minimum 16 decimaler efter kommaet vil du se at Excel ikke regner rigtigt.
Det er da sjovt hvordan den afrunder det. I dette eksempel er der da slet ingen tvivl om at det skal give 0,1 og absolut ikke andet!!
Det er vel også en bug der vil noget (selvom de færreste arbejder med 16 decimaler)
Det burde jo give 0,1 og ikke andet!
Men sætter du minimum 16 decimaler efter kommaet vil du se at Excel ikke regner rigtigt.
Det er da sjovt hvordan den afrunder det. I dette eksempel er der da slet ingen tvivl om at det skal give 0,1 og absolut ikke andet!!
Det er vel også en bug der vil noget (selvom de færreste arbejder med 16 decimaler)
76,8 65280
76,85 65322,5
76,9 65365
76,95 65407,5
77 65450
77,05 65492,5
77,1 100000
77,15 65577,5
77,2 65620
77,25 65662,5
77,3 65705
77,35 65747,5
77,4 65790
Indsæt dette i et regneark, vis i et diagram.. Godt nok viser Excel, at værdien er 77,1;100000 - men den vises på samme linie som de andre...
/Al
76,85 65322,5
76,9 65365
76,95 65407,5
77 65450
77,05 65492,5
77,1 100000
77,15 65577,5
77,2 65620
77,25 65662,5
77,3 65705
77,35 65747,5
77,4 65790
Indsæt dette i et regneark, vis i et diagram.. Godt nok viser Excel, at værdien er 77,1;100000 - men den vises på samme linie som de andre...
/Al
Fejlen blev først rapporteret i microsoft.public.excel gruppen. Der er i linket en række eksempler på særheder omkring denne bug, f.eks. at VBA udregner korrekt. Og at udregninger baseret på det forkerte resultat (100.000) er forskellige efter regneart og værdi der regnes med.
Som flere andre har antydet ser det ud til at være en display-fejl mere end en beregningsfejl.
Som flere andre har antydet ser det ud til at være en display-fejl mere end en beregningsfejl.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund