Lærer de om floating point i matematik ?
Blandt andet vås i medierne idag, er en historie om hvorledes regneark kan regne forkert.
Artiklen handler naturligvis om den episke diskussion i forbindelse med IEEE754 standardens valg af binær mantisse, istedet for decimal mantisse.
Jeg hører netop nu i min øresnegl at det gør artiklen ikke.
Den handler om at nu skal alle til at regne deres regneark efter, for ellers kan der "indsnige sig fejl".
Typisk er fejlen i størrelsesordnen 0.000000000001 for almindelige mennesker og 0.000001 for Stein Bagger og Skatteminister Jensen.
${RANT_OM_FOLKESKOLENS_MATEMATIK_UNDERVISNING}
${RANT_OM_JOURNALISTERS_HANG_TIL_EN_SENSATION}
${HISTORISK_REFERENCE_TIL_PENTIUM_CPUER}
${NEJ_HVOR_ER_JEG_TRÆT_AF_INKOMPETANCE}
phk
Om Poul-Henning KampSelvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (68)
Den her kommer jo op sådan ca. en gang hvert andet år, ligesom historien om at det pludselig er gået op for nogen at "tilfældige tal" - surprise! - ikke er så tilfældige endda, når man itererer tilstrækkeligt mange gange over sin simulation.
-
0 -
0
Dette kursus på Aalborg Universitet kan anbefales: http://www.math.aau.dk/~qvist/teaching/csb-09/
-
0
-
0
Delvist ikke.
Vi lærte selvfølgelig ret hurtigt om binær repræsentation og den indbyggede fejl man får ved konvertering fra decimal, men deciderede metoder til at undgå fejlene, eller rettere, floating point aritmetik er faktisk en af de ting der stort set er gået uden om os.
Hvilket egentligt er lidt sjovt, taget i betragtning at et af undervisernes yndlings eksempel på dårlig software, er den raket der talte tiden i 0,1 sekunders intervaller og ramte ved siden af pga. den akkumulerede fejl.
Så svaret er at vi kender til fejlen, ved hvornår den opstår, men nærmest ikke hvordan den minimeres eller undgåes. Perfekt! ;)
(7. semester SW ved AAU)
-
0
-
0
[rant]
I samme åndedræt kunne man evt. stille spørgsmålstegn ved, om folk egentligt læser hele artiklen, eller om de bare skal rante om dumme journalister.
Om hvordan man i Folkeskolen skal undervise i repræsentation af decimaltal på binær form... Ja selvfølgelig skal man det!
Og det er nu ikke så meget fordi, at tallene bliver repræsenteret forkert, men snarere at repræsentationen af fejlen optræder forskelligt alt efter, hvilken rækkefølge data forekommer i på regnearket.
[/rant]
-
0
-
0
Man skulle ikke håbe at man sidder og bruger Excel til at lave vigtige beregninger til f.eks brokonstruktion.
Det ville da ikke være noget stort problem.
Hvis fejlen udgjorde det citerede eksempels 1,6*10^-12 af broens længde på 1,6 km ville fejlen udgøre ca 3 nanometer. Den nøjagtighed ville nok ikke bekymre en civilingeniør, med mindre han designede microchips ;-)
-
0
-
0
På DTUs nu sammenlagte Numerisk Institut skelnede vi mellem matematik og regning - hvor sidstnævnte er udmærker sig ved at foregå med endelig hastighed og præcision.
James H. Wilkinson
- http://en.wikipedia.org/wiki/James_H._Wilkinson -
var en pioner indenfor numerisk analyse, altså regning på højt niveau.
Iøvrigt er endnu et problem med Computerworlds artikel, at de bruger tallet pi som eksempel på afrundingsfejl.
Dette trandenscente tal er et rigtigt dårligt eksempel eftersom mange praktiske opgaver i regneark kan klares med rationelle tal inklusiv kroner og ører skrevet som decimaltal.
En ti-øre skrevet som decimaltal (altså 0.1 kr.) kan nemlig ikke repræsenteres eksakt i det binære talsystem!
(Grunden er at 1/5 ikke kan skrives med et endeligt antal binære cifre).
Men det er da godt at der er mere vågne skribenter ved version2.dk.
-
0
-
0
Nu fik PHK vist vrisset lidt mere end han fik forklaret.
Hvis man ved en smule om emnet er det ingen overraskelse at disse unøjagtigheder opstår, ej heller at rækkefølgen gør en forskel.
Alle computere og programmer laver unøjagtigheder i kommatalberegninger, man kan forsøge at skjule dem ved at beregne unøjagtighed og afrunde resultater derefter, og netop dette tilfælde kan undgås ved at lave decimale beregninger i stedet for binære, men det betyde ikke at der ikke stadigvæk bliver lavet afrundingsfejl.
De tal som Excel regner med er 64 bit med 53 bit mantisse (hvoraf 1 er impliceret), det giver ca. 16 decimaler, og det er godt nok til næsten alt, inkl. broer og rumraketter.
Mht. tidtagning er 64 bit kommatal gode nok til at representere tid, men det kan give problemer hvis man summerer unøjagtige tal for at tælle tid.
Den omtalte artikel er en storm i et glas vand, problemet er kosmetisk.
-
0
-
0
Lad os hypotetisk antage, at der er en udregning, der afhænger af udregningen af to decimaltal. Er det så stadig et kosmetisk problem?
-
0
-
0
I det virkelige liv kan det medføre afrundingsfejl.
Jeg lavede engang et handelssystem til vekselerere, hvor der indgår vedhængende kuponrenter.
I det system havde jeg kun floating point at gøre godt med, og det var mindst et tilfælde hvor det gav en afrundingsfejl.
Det medførte en fejl på 1 øre, som ikke er penge som sådan, men den slags må bare ikke ske i den finansielle verden, så det er ikke en 'kosmetisk' fejl.
Jeg kan ikke huske det præcise tal, men lad os antage, at der skulle være xxx,125 men pga. floating point blev det til xxx,12499999....
Når dette tal afrundes til 2 decimaler skete fejlen.
Heldigvis har man inden for COBOL nogle andre data typer:)
-
0
-
0
Den omtalte artikel er en storm i et glas vand, problemet er kosmetisk.
Prøv nu at læse og forstå hvad PHK skriver.
Artiklen starter med
"En fejl i Microsofts regnearksprogram...".
Men det at hardwaren kun kan håndtere et begrænset antal cifre kan ikke beskrives som en programfejl.
PS. Hvis man skal addere et nogle tal som alle har samme fortegn, så kan man vise at afrundingsfejlen bliver minimal hvis tallene først sorteres og herefter adderes startende med det (absolut set) mindste tal. Men afrundingsfejl vil altid kunne forekomme.
-
0
-
0
Det er et meget kendt problem når det kommer til regnskaber. Da jeg var revisor elev sku man som regel "om bagved" for at få balancen til at "passe", før det blev sendt ud til kunden.
-
0
-
0
Jeg må hellere lige præcisere, det er den kosmetiske del af problemet som har fået Ming Lü til at beskæftige sig med det, og hans artikel er skrevet ud fra den forudsætning at det kosmetiske problem er ensbetydende med et praktisk problem.
Lad os hypotetisk antage, at der er en udregning, der afhænger af udregningen af to decimaltal. Er det så stadig et kosmetisk problem?
Fejlen er stadigvæk negligerbar, afhængig af de eksakte beregninger kan fejlen vokse for hver mellemregning, men under normale omstændigheder vil den ikke blive betydelig.
-
0
-
0
Morten Hattesen,
Forestil dig at du går ind i en slikbutik hvor de sælger slikkepinde til 10 øre, 20 øre osv. Du har en krone med og vil gerne have så mange forskellige slikkepinde som muligt. Du giver din krone til ekspedienten som slår den ind på kasseapparatet. Efter at have købt en af dem til 10 øre har du 90 øre tilbage. Så køber du en til 20 øre og har nu 70 øre tilbage. Den næste i rækken koster 30 øre og da du har købt den har du ikke 40 øre tilbage men kun 39,9999999999 øre på grund af en simpel afrundingsfejl.
I stedet for at have råd til 4 slikkepinde, har du nu kun råd til 3. Det er da en afrundingsfejl der er til at føle på.
-
0
-
0
Jeg har været udsat for noget af det samme med det regnskabssystem jeg bruger, e-conomic. På en faktura på 17.600 lægger e-conomic 4.400,02 kr. til i moms. Det føltes lidt pinligt at sende en faktura til kunden med så åbenlys en regnefejl på…
E-conomic-fyrene mente dog ikke der var tale om et problem – efter at have skrevet til dem om det var svaret:
Men det er en kendt kontroleret "bug" i e-conomic. Ud fra de udregnings principper vi har valgt. Du skal i denne sag. Manuelt bogføre øre diff. Væk fra debitor og til øre diff..
Der kan være mange grunde til at bruge floating-point beregninger, men det virker uforståeligt at vælge det til financiel software, da det jo ellers er en fremragende case for fixed precision.
-
0
-
0
Kære Jacob,
Ganske givet er problemet, hvis man ellers er opmærksom på den, temmelig let at undgå, men det var sådan set en læser, der satte det igang.
Jo, jeg er klar over problematikken, og umiddelbart er det ikke den store afsløring for folk, der har haft en uddannelse inden for datalogi eller informatik (jeg tror næppe, at Folkeskolens matematikundervisning vil gøre mere ved PHK's hentydning).
Men der er altså nogen, der ufortrødent overser problematikken, når de opbygger regneark.
Prøv evt. at dividere de forskellige fejlresultater fra decimaludregningerne med hinanden.
Og hvis det resultat så senere hen skal bruges i en anden udregning...
-
0
-
0
Prøv evt. at dividere de forskellige fejlresultater fra decimaludregningerne med hinanden.
Det er så en beregning hvor du netop forstærker unøjagtigheder, uanset deres kilde, det er ikke en beregning som du kan bruge til noget i virkeligheden, blot et stykke talfifleri hvor du får et pseudotilfældigt tal i stedet for NaN.
Nu bliver det så spændende at se hvor mange regnearkforbud der kommer rundt omkring i virksomhederne pga. en chef som har forstået halvdelen af en forvrøvlet artikel i Computerworld.
-
0
-
0
Fejlen er stadigvæk negligerbar, afhængig af de eksakte beregninger kan fejlen vokse for hver mellemregning, men under normale omstændigheder vil den ikke blive betydelig.
Jeg ved godt at investeringsregnskaber ikke nødvendigvis tæller som »normale omstændigheder«, men det er min erfaring at dér er det ikke holdbart med IEEE-flydende-komma-tal. 15 betydende cifre er simpelthen ikke nok til en mellemstor portefølje. Fejlene akkumuleres simpelthen hurtigt nok til at det ses.
-
0
-
0
Prøv evt. at dividere de forskellige fejlresultater fra decimaludregningerne med hinanden.
Der er forhåbentlig ingen der uden videre dividerer, hvis der er mulighed for at divisoren er nul.
Og hvis der ikke er mulighed for division med nul, så vil divisionens præcision stadig være et beskedent multiplum af maskinpræcisionen.
Hvis vi skal holde os til de simple regne-operationer, så skal man derimod undgå at trække store tal fra hinanden. For eksempel skal implementeringen af en løser til andengradsligningen med positiv diskriminant modificeres, så den ene rod findes ved addition, den anden ved division (istedet for subtraktion).
-
0
-
0
Jeg forstår ikke hvorfor Excel (og lignende programmer) ikke for længst er gået over til decimal aritmetik.
De 0,01% af tiden hvor det ikke er hurtigt nok på moderne hardware, er det alligevel kun sundt, hvis regnedrengene ringer efter en rigtig programmør, inden deres VBA-kode sender dem ud, hvor de ikke kan bunde.
-
0
-
0
Jeg forstår ikke hvorfor Excel (og lignende programmer) ikke for længst er gået over til decimal aritmetik.
En del af grunden er måske, at det ikke vil ændre på den grundlæggende begrænsning af præcisionen i hardwaren.
-
0
-
0
Det er så en beregning hvor du netop forstærker unøjagtigheder, uanset deres kilde, det er ikke en beregning som du kan bruge til noget i virkeligheden, blot et stykke talfifleri hvor du får et pseudotilfældigt tal i stedet for NaN.
Mon ikke at det skal være op til vedkommende, der rent faktisk sidder med et regneark, der afgører om bestemte parametre er betydningsfulde eller ej?
Du bekræfter jo, at en division netop forstærker unøjagtigheder, og netop derfor er det vel meningen, at dem som i sidste ende sidder med regnearket skal være opmærksomme på denne problematik?
-
0
-
0
undervejs mellem server crash osv så fik de deres total procent summet til 100.1%
flot
-
0
-
0
"Prøv evt. at dividere de forskellige fejlresultater fra decimaludregningerne med hinanden." Det er så en beregning hvor du netop forstærker unøjagtigheder...
Nej. Antallet af korrekte cifre ændres hverken ved division eller multiplikation (undtaget de "patologiske" tilfælde af over- eller underflow, som ikke er berørt her).
Som set i de forskellige eksempler, er det subtraktion (eller addition at tal med forskellige fortegn), der kan føre til et væsentligt tab i antallet af korrekte cifre.
Læs eventuelt W. Kahans "Can You Count on Your Calculator".
-
0
-
0
Den associative lov gælder ikke; Sammenligning (==) er som regel forkert at bruge; subtraktion kan lede til voldsomme problemer og hvis F er et stort nok tal, da gælder naturligvis F+1 == F.
Det "farlige" i den her forbindelse er hvis en lille fejl på sidste decimal vokser sig større og større for til sidst at påvirke resultatet på afgørende vis. Det kan naturligvis undgås, men så skal man som udgangspunkt læse en smule om numerik og IEEE 754-repræsentationen.
Men når "almindeligt dødelige" bliver udsat for ineksakte tal, så ramler himlen åbentbart ned.
-
0
-
0
Til gengæld er IEEE 754 - i modsætning til de relle tal - et lukket tallegeme mht. alle fire regningsarter.
-
0
-
0
En computer kunne i princippet meget nemt regne såvel minimum som maximum ud. Ligesom komplekse tal, består af en imaginærdel, og en reeldel - og kan laves som klasse i C++ - så er også muligt, at lave en klasse for udregning med min/max værdier, og hvor såvel en minimumsværdi, og en maximumsværdi for resultatet gemmes. Laves addition, er minimumsværdien de to minimumsværdier adderet, minus eventuel mangel på præcision på additionen, og maximumsværdierne er de to maximumsværdier adderet, plus eventuelt mangel på præcisionen. Alle resultater, er så et sted mellem minimum og maximum. Typisk, vil man ved udskrift, ikke angive flere cifre, end forskellen mellem minimum og maximum gør realistisk.
Om der regnes binært, eller decimalt, betyder naturligvis intet for resultatets kvalitet - og der er ligeså stor grund til at regne efter, hvis regnearket gør det decimalt.
Specielt ved matematiske og videnskabelige udregninger, vil altid anvendes minmax beregninger. Det er relativt nemt, på samme måde som komplekse tal, og kan klares ved at lave klasser til problemet. Matematiske og videnskabelige udregninger, har ofte udregninger der forekommer i løkker - og her kan en værdis præcision teoretisk blive lavere for hver itteration - derfor er altid vigtigt, at her udregne såvel minimum som maximum. Skal computerens resultat kunne bruges videnskabeligt, er det altid nødvendigt.
Regneark har både problem med at kunne anvendes videnskabeligt, og problem med at kunne bruges til økonomi. For videnskab, er det et problem, at der ikke tages hensyn til minmax, at der ikke er implementeret komplekse tal, matricer osv. Og for økonomi, lever de ikke op til sikkerheden, men det kan måske tildels løses ved at have flere uafhængige udregninger, baseret på forskellige producenters regnearksprogrammer. Dog er regneark ikke godkendt til økonomi.
Det vil være naturligt, hvis programmeringssprog som standard havde indbygget minmax typer, hvor der dels vil kunne indtastes værdi og præcision, eller min+max værdi, og hvor det vil være muligt at få såvel præcision, eller minimum og maximum værdi, ved resultat. Ønskes så bedre præcision, vil være en fordel, hvis sprogets typer håndterer, at der ved erklæringen, frit kan vælges med hvor stor præcision en float skal udregnes med.
-
0
-
0
Dog er regneark ikke godkendt til økonomi.
Øhhhhh... Nå. Det var en lidt generaliserende udtalelse!
Hvem er det, der ikke har "godkendt regneark til økonomi"?
Der er regler om, at du fx ikke må bruge regneark til at udarbejde regnskaber/fakturaer m.v., men det skyldes ikke deres "unøjagtighed", men derimod at de ikke vedligeholder et revisionsspor, og at der derfor er mulighed for at manipulere med tallene efterfølgende. Jeg gad i øvrigt godt vide, om IT-Factory anvendte Excel som det centrale økonomisystem ;-)
-
0
-
0
Jeg kan ikke huske det præcise tal, men lad os antage, at der skulle være xxx,125 men pga. floating point blev det til xxx,12499999.... Når dette tal afrundes til 2 decimaler skete fejlen.
Hmmm. Hvis man afrunder xxx,12499999 til 2 decimaler bliver resultatet xxx,125 med mindre der vælges at runde ned (truncate), i hvilket tilfælde resultatet bliver xxx,124. Så der er her nok nærmere tale om at udvikleren har valgt en forkert afrundingsmetode, og altså ikke at præcisionen af floating point havde nogen betydning i sig selv.
-
0
-
0
så skal man derimod undgå at trække store tal fra hinanden.
Ja for der bliver meget langt i mellem dem :-))
Herudover er der intet nyt i at man kan risikere unøjagtighed ud på 15-16 ciffer når man laver floating point operationer, selv om tallet tilsyneladende kun har to decimaler.
/Christian
-
0
-
0
staveinkompetEnce...? Ja sorry, men den var altså for oplagt...
Ja, "Stavning eller kaos" som man sagde i gamle dage.
Socialdemokraterne gik vist endda til valg på det slogan engang...
-
0
-
0
Nu vi snakker om inkompetence hvem er også så dumme at implementere grunenheder i systemer der behandler økonomisk data som decimaltal.
Præcis i den branche, hvor fejlen ikke bare er kosmetisk, har man jo den enorme fordel at du kan regne alt som heltal (representeret ved mindste møntenhed). Så at der opstår fejl i regneark skyldes udelukkende fejl hos brugeren ("programmøren") af regnearket.
-
0
-
0
xxx,125 bliver vist til xxx,13 hvis man afrunder til 2 decimaler.
Jeg kan squ ikke huske om jeg brugte bankers rounding eller ej, det er trods alt 25+ år siden.
Derfor undlod jeg at præcisere om det 'korrekte' resultat var ,12 eller ,13.
-
0
-
0
En del af grunden er måske, at det ikke vil ændre på den grundlæggende begrænsning af præcisionen i hardwaren
Det er klart, men det løser vel problemet med at almindeligt forekommende tal ikke opfører sig som de fleste brugere forventer.
Fx ved de fleste nok, at 0,3333 ikke er det samme som 1/3, men det er de færreste der tænker over, at på computeren er 0,1 forskellig fra 1/10 pga. den binære repræsentation.
-
0
-
0
Stig,
Jeg kan squ ikke huske om jeg brugte bankers rounding eller ej
Min kommentar var også rettet til Morten Hattesen, der skrev:
Hvis man afrunder xxx,12499999 til 2 decimaler bliver resultatet xxx,125 ...
Det er vist snarere en afrunding til 3 decimaler :-)
-
0
-
0
Til gengæld er IEEE 754 - i modsætning til de relle tal - et lukket tallegeme mht. alle fire regningsarter.
Det kan da næppe være et legeme. Det er end ikke en ring: Den additive operator udgør ikke en gruppe (den associative lov gælder ikke) og den multiplikative operator former ikke en monoid (semigruppe) af samme grund.
-
0
-
0
Det kan da næppe være et legeme.
Undskyld.
Det jeg mente var (på engelsk)
"IEEE 754 is closed under the four arithmetic operations",
altså at enhver aritmetisk operation på to IEEE 754 elementer har et resultat der er IEEE 754. Det samme gælder ikke for de reelle tal.
-
0
-
0
Ja, ja, ja, æg-på-fjæs til mig for min fejl med antallet af decimaler. Den bad jeg selv om! :-D
-
0
-
0
Så er her et rigtigt godt link: http://www.diycalculator.com/sp-round.shtml
-
0
-
0
Nu vi snakker om inkompetence hvem er også så dumme at implementere grunenheder i systemer der behandler økonomisk data som decimaltal.
Fordi det ser dumt ud, at en vare koster 1000 øre.
Minder mig om ham, der skulle oprette mig i lønsystemet, hvor der faktisk skulle tastet i øre.
Det havde han glemt, så jeg fik vist 150-160 kr. udbetalt om måneden :)
Men bortset fra det, så er det ikke alle udviklingsværktøjer, der har implied decimal.
I COBOL kan man definere PIC S9(9)V99 COMP,
som internt er et heltal, men repræsenteres med 2 decimaler.
I Delphi/MS SQLServer (og sikker andre Windoes værktøjer) har man currency, som er en 64 bit integer med 4 decimaler implied.
I regneark vil jeg tro, at man altid bruger floating point.
Jeg lavede engang et program til at trække data ud i en Lotus 123 fil, og dér var det floating point, så mon ikke det er det samme med Excel(?)
Og apropos IEEE 754 og sjovt, så var det sjovt, eller rettere bitflækkeri, for det var på en HP3000, som kørte med 53+10 bits, og ikke 52+11, som lotus skulle bruge, så der skulle flyttes lidt bits.
-
0
-
0
altså at enhver aritmetisk operation på to IEEE 754 elementer har et resultat der er IEEE 754. Det samme gælder ikke for de reelle tal.
Øhhh...
Jeg kunne godt tænke mig at se en aritmetisk operation på to reelle tal, hvis resultat ikke lå i mængden af de reelle tal.
Har du et eksempel?
-
0
-
0
Jeg kunne godt tænke mig at se en aritmetisk operation på to reelle tal, hvis resultat ikke lå i mængden af de reelle tal.
0/0 er udefineret for reelle tal. Dermed er det et eksempel på en aritmetisk operation på 2 reelle tal hvis resultat ikke er reelt. For IEEE 754 FPs har 0/0 en værdi, nemlig NaN. NaN kan du "regne med" ligesom alle mulige andre tal, fordi du så kan propagere regnefejlen til senere. Men opfattet som mængde med aritmetiske operatorer så fungerer det anderledes end de reelle tal.
-
0
-
0
0/0 er udefineret for reelle tal.
Interessant, men jeg tror ikke den holder.
Det er jo divisions-[i]operationen[/i] der er udefineret for divisor 0, ikke resultatet.
Operationen er jo netop udefineret fordi et resultat ikke ville give mening, rent matematisk.
For [i]lovlige[/i] operationer skulle de reelle tal & aritmetiske operatorer gerne være lukket.
Og endnu værre, NaN har jo egenskaber der gør at det ikke er et tal ("Not a Number"), så selve det at snakke om "lukkethed" i denne kontekst (IEEE 754) har jeg svært ved at se giver mening.
Men jeg vil nu lige konsultere lærebøgerne omkring det før jeg erklærer mig 100% skråsikker :-)
-
0
-
0
For IEEE 754 FPs har 0/0 en værdi, nemlig NaN.
Wikipedia siger om IEEE 754 at der defineres en "exception handling" ifm. division med nul. Så operationen lader heller ikke til at være en tilladt aritmetisk operation på det tilhørende talsystem - IEEE 754 definerer åbenbart bare hvordan denne ulovlige operation [i]håndteres[/i] (åbenbart med NaN).
http://en.wikipedia.org/wiki/IEEE_floating-point_standard#Exception_hand...
-
0
-
0
Software ingeniørerne gør (ikke). [...] (7. semester SW ved AAU)
Da jeg læste på DTU (start 1996), var "Regning på datamater" obligatorisk fag på informatikfagpakken.
http://www.shb2002.dtu.dk/megetgamlekurser/1997-1998/kurser/imm/04010_uk...
-
0
-
0
Det er da et kendt problem som ofte sker ved afrunding bla. i den statistiske verden, DW og BI.
De fleste SQL implementationer laver denne type afrundingsfejl ved SUM.
Computere kan heller ikke direkte regne med brøker
(1 / 3) * 3 = 0.99999999
Wow!!! BIG NEWS!!!
-
0
-
0
Computere kan heller ikke direkte regne med brøker
Min første lommeregner (HP25) kunne sagtens finde ud af, at 1/3 = 0.33333..
og gangede man derefter med 3, så gav det 1 !!!
-
0
-
0
Ja men prøv du det i f.eks. SAS
Hvof' det?
Jeg har bygget masser af systemer med tilhørende DW/BI, uden at have haft afrundingsproblemer.
Man skal bare vælge de rigtige datatype (aka implied decimal) inden for finans.
Men du snakker statistik, og der er det vel lige gyldigt om det er 42% eller 42,001% -
after all: "87% of all stastics are made up"
-
0
-
0
Derfor findes der BCD-aritmetik i sprog som Cobol, men du får stadig samme problem hvis du laver 1/3, til gengæld kan du repræsentere 1/10 eksakt, så øre-fejl følger vanlig tankegang.
-
0
-
0
Min første lommeregner (HP25) kunne sagtens finde ud af, at 1/3 = 0.33333.. og gangede man derefter med 3, så gav det 1 !!!
De fleste lommeregnere, har nogle ekstra cifre, som gør at det ser ud til resultatet er 1. Trækker du 1 fra, er det ikke altid det giver 1.
I mange sammenhænge glemmes helt at tage højde for computernes unøjagtigheder. Det mest sikre, er at lave et objekt, så minimum og maximum udregnes for alt. På den måde, kan også angives ethvert tal med målenøjagtighed, og såvel måle som beregningsunøjagtigheden udregnes ved resultatet.
-
0
-
0
Hvof' det? Jeg har bygget masser af systemer med tilhørende DW/BI, uden at have haft afrundingsproblemer.
Fint for dig, så fordi du ikke har haft nogen, betyder altså at det ikke findes. Super logik!
Man skal bare vælge de rigtige datatype (aka implied decimal) inden for finans.
Not! Det har ingen betydning... Så det virker hvis domænet er finans... Jesus!
Men du snakker statistik, og der er det vel lige gyldigt om det er 42% eller 42,001% -
Helt sikkert...LOL
Det bliver enddog mere signifikant når vi begynder at joine på tværs af databaser, lave aggregater hvor vi kun opdaterer med delta osv...
after all: "87% of all stastics are made up"
Godt så :-)
-
0
-
0
Fint for dig, så fordi du ikke har haft nogen, betyder altså at det ikke findes. Super logik!
Nej, det er vist noget du har misforstået.
Pointen var, at hvis man [b]ved[/b] hvad man laver, og vælger de rigtige datatyper, så kan man undgå afrundingsproblemer.
Not! Det har ingen betydning...
Det har da i allerhøjeste grad betydning, ud over mit eget eksempel, så se indlægget:
Afrundingsfejl er pinlige af Mikkel Høgh
længere oppe i tråden.
Så det virker hvis domænet er finans... Jesus!
Den logik forstår jeg slet ikke.
Hvis man har behov for eksakt repræsentation bør man da bruge implied decimal, uanset domænet.
Det kan da godt lyde underligt, at man går op i 1 øre når omsætningen ligger på 1 mia+/dag, men rationalet fra revision/banktilsyn er:
"Hvis der er en fejl på 1 øre, hvor mange andre /store) fejl er der så i systemet?"
Når du skriver som du skriver, tager jeg udgangspunkt i, at du ikke har erfaring inden for finans/økonomi, men det er altså vigtigt at tallene stemmer i disse systemer.
-
0
-
0
Ja men prøv du det i f.eks. SAS
[code=sas]
1 data null;
2 x=1/3;
3 y=3*x;
4 put x=;
5 put y=;
6 run;
x=0.3333333333
y=1
[/code]
Er vi glade så :-)
-
0
-
0
Nej, det er vist noget du har misforstået. Pointen var, at hvis man ved hvad man laver, og vælger de rigtige datatyper, så kan man undgå afrundingsproblemer.
Men det fortæller jeg dig så at man ikke kan hvis man f.eks. bruger SAS som en MEGET stor del af DW/BI verdenen gør. Det er een numerisk datatype (den kan så formateres på forskellig vis).
Den logik forstår jeg slet ikke. Hvis man har behov for eksakt repræsentation bør man da bruge implied decimal, uanset domænet.
Netop! Men nu var det sådan set, at jeg skrev at afrundingsproblematikken ikke er et nyt fænomen
Når du skriver som du skriver, tager jeg udgangspunkt i, at du ikke har erfaring inden for finans/økonomi, men det er altså vigtigt at tallene stemmer i disse systemer.
Det var netop min pointe at nøjagtighed har relevans - og jo jeg har temmelig stor erfaring indenfor netop disse områder, ligesom det har det i medicinalbranchen og andre steder.
Er vi glade så :-)
Nej du har jo ikke haft det over en tabel, så du har lige bevist at compileren i data step kan reducere.
proc sql har dette problem, jeg har ingen intesion om at bevise det, for jeg ved det er der. Jeg har siddet med netop dette afrundingsproblem, da jeg arbejdede i NC og lavede den SQL optimizer der er i SAS's rapporteringsløsninger. Svaret fra proc sql udviklerne var, at de unøjagtigheder der ved afrunding er normal og acceptabel.
Det betyder at afvikler du den samme proc sql 2 gange vil en sum f.eks. give 2 forskellige resultater, selvom det er samme data og sql udtryk.
Det kan give problemer, da databehandling på databehandling kan opsummere disse afrundingsproblemer.
Hvis man går ned og ser på den binære repræsentation af data i target tabellen for en operation som ovenståendekan man se afvigelsen.
Hvis du læser Christian Nobels indlæg højerer oppe kan du jo se at han lige netop omtaler problemet som meget normalt for floating point. Implied decimal (COBOL), BigDecimal (Java) etc. er ikke altid til rådighed hele vejen ned i en database og tilbage igen til den sprog/&software som videre behandler data.
-
0
-
0
Nej du har jo ikke haft det over en tabel, så du har lige bevist at compileren i data step kan reducere. proc sql har dette problem, jeg har ingen intesion om at bevise det, for jeg ved det er der. Jeg har siddet med netop dette afrundingsproblem, da jeg arbejdede i NC og lavede den SQL optimizer der er i SAS's rapporteringsløsninger. Svaret fra proc sql udviklerne var, at de unøjagtigheder der ved afrunding er normal og acceptabel.
SAS Kode:
[code=sas]
data WORK.ROUND1;
x=1/3;
run;
data WORK.ROUND1;
set WORK.ROUND1;
y=3*x;
run;
proc sql;
create table WORK.ROUND2 as
select x,
0 as y
from WORK.ROUND1
;
update WORK.ROUND2
set y=3*x
;
quit;
proc print data=WORK.ROUND1;
proc print data=WORK.ROUND2;
run;
[/code]
Nu har jeg haft det over en tabel, både i et data step og i proc sql.
Hvad siger proc print?
ROUND1:
[code=sas]
Obs x y
1 0.33333 1
[/code]
ROUND2:
[code=sas]
Obs x y
1 0.33333 1
[/code]
Er vi glade så :-)
-
0
-
0
Er vi glade så :-)
Læste du hele mit indlæg? Hvis ja, hvorfor forholder du dig så kun til dele af det?
-
0
-
0
Læste du hele mit indlæg? Hvis ja, hvorfor forholder du dig så kun til dele af det?
Udgangspunktet var eksemplet med 3 * (1/3).
Det betyder at afvikler du den samme proc sql 2 gange vil en sum f.eks. give 2 forskellige resultater, selvom det er samme data og sql udtryk.
Det glæder jeg mig til at teste!
-
0
-
0
Udgangspunktet var eksemplet med 3 * (1/3).
Korrekt, og jeg vil give dig ret. Dog lavede en tidligere kollega et eksempel til mig i SAS for flere år siden som gjorde nøjagtigt det modsatte af dit eksempel.
Problemet er at ryger man ud af kontekst, vil de 0.33333 ikke længere være 1/3, men 0.33333. Ganger man 0.33333 med 3 får man så 0.99999 og ikke 1.
Det håber jeg du giver mig ret i?
Det glæder jeg mig til at teste!
Det behøver du ikke, men du er velkommen, hvilken version af SAS bruger du - 9.2?
jeg ved at vi på min gamle arbejdsplads har nogle JUnit tests der rent faktisk lider under denne afrundingsfejl
-
0
-
0
Jeg bruger 9.1.3 SP4.
Jeg er selv rendt ind i afrundingsfejl i SAS (tilbage i version 8 godt nok), så jeg afviser slet ikke at de forekommer - det må de jo nødvendigvis, hvis du har et begrænset antal bits til at repræsentere reelle tal - spørgsmålet er bare hvilke typer beregninger man skal ud i for at få dem til overfladen.
Og her mener jeg SAS gør en OK figur - men de bruger jo også som udgangspunkt 8 bytes til at lagre tal...
Så længe du holder dig indenfor 12 decimaler i SAS er du på nogenlunde sikker grund (har jeg læst engang) - og når man sjældent får f.eks. valutakurser med mere end 5-6 decimaler, kan man som regel klare sig igennem :-)
-
0
-
0
Jeg bruger 9.1.3 SP4.
Jeg har ikke arbejdet med SAS de seneste 3 år+, men det var også den seneste release da jeg arbejde med den. Er 9.2 ikke kommet endnu - eller venter vi på 10?
9.1.3 havde også problemerne.
Og ja til alt andet du skriver :-) Men Lewis Hamilton, tror jeg han hedder fra proc sql, gav en forklaring tilbage i sommeren 2004 på hvorfor unøjagtighederne kommer...
Iøvrigt var min gamle arbejdsplads som du har gættet SAS Institute, både DK og HQ i NC.
-
0
-
0
Er 9.2 ikke kommet endnu - eller venter vi på 10?
Jojo, 9.2 Foundation er længe ude, men nogle af de overliggende komponenter (BI Platform) mangler vist at kunne køre på 9.2. Og så længe 9.1 virker og dækker behovet har vi ikke travlt med at opgradere - "lad de andre tage børnesygdommene" :-)
-
0
-
0
Ja behøver jeg nævne SAS version 7 :-)
Dog skulle 9.2 introducere data step 2, men jeg ved ikke om det er droppet?
-
0
-
0
Tilføj kommentar
