Den sön 28 apr. 2019 kl 19:53 skrev Kaj Persson <kape_...@telia.com> < kape_...@telia.com>:
> Ack nej, någon bugg är det inte. Det har fenomenet har studenter > upptäckt och undrat över ända sedan datorn blev ett användbart verktyg. > Orsaken är att du räknar i det decimala talsystemet, alltså med basen > 10, medan datorn använder det binära talsystemet, basen 2. I datorernas > barndom fanns det faktiskt decimala datorer, men man fann snart att den > konstruktionen tillförde fler problem än den löste, och övergavs snart. > Elektroniken som används är ju binär, man använder element som är > antingen till eller från, vilket vi då tolkar som 1 eller 0. Därför > måste datorn, dig ovetande, varje gång du matar in ett decimalt tal > omvandla det till binär form för att kunna bearbeta det. Om talet är ett > heltal blir representationen lika i de två talsystemen, men med > decimaler skiljer de sig nästan alltid åt i någon avlägsen decimal. > Detta beror på att vi har ett begränsat utrymme att lagra talet, så > någonstans på slutet måste vi kasta bort de överskjutande siffrorna, och > då uppstår alltså ett avrundningsfel. > > Du vet säkert att det binära talsystemet är uppbyggt kring tal med > värdena 1, 2, 4, 8, 16 etc, d.v.s. den efterföljande siffran är alltid > dubbelt så stor som den föregående. Egentligen skulle jag skriva dem i > omvänd ordning för det är så de används enligt positionssystemet. Det > binära talsystemet är uppbyggt analogt med vad gäller i det decimala > talsystemet, där värdet av varje siffra beror på positionen i talet. > T.ex. 123 betyder 1 * 100 + 2 * 10 + 3 * 1. En siffra på en viss > position är värd 10 gånger så mycket som siffran till höger om sig. I > det binära talsystemet arbetar man på samma sätt, men då med värdena 16, > 8, 4, 2, 1 i stället för t.ex. 100, 10, 1, o.s.v. > > När man sedan kommer till decimalerna fungerar det på samma sätt men nu > med positonsvikterna 0,5, 0,25, 0,125, 0,0625 etc, Fortfarande gäller > principen att en siffra på en viss position är värd dubbelt så mycket > som siffran till höger. Här inser man snart att det oftast inte går att > få en exakt koppling mellan det decimala och det binära talsystemet. > Exempelvis motsvaras det decimala talet 0,8 av det binära 1 * 0,5 + 1 * > 0,25 + 0 * 0,125 + 0 * 0,0625 + 1 * 0,03125 etc. D.v.s. binärt > 0,11001... Det fortsätter i all oändlighet, men någonstans säger > konstruktören att nu avsätter vi inte större utrymme för lagringen, och > därmed kastas de resterande decimalerna helt sonika bort. Det är alltså > bara vissa speciella decimaltal, som kan representeras exakt i det > binära talsystemet, såsom exempelvis 0,5, 0,625 etc. > > Lösningen då? Den enklaste är förstås att räkna i ören i stället för > kronor, eller vilken valuta det nu handlar om. Så får man fixa > omvandlingen på slutet genom att helt enkelt dividera slutresultatet med > 100. > En annan utväg är att utnyttja att felet ligger i en decimal långt > utanför hundradelarna, och därför kan man enkelt införa en > avrundningsfunktion där man begränsar antalet visade decimaler till två. > Här finns ett vägval: antingen behåller man datorns beräknade resultat, > men sätter ett format på cellen som begränsar visningen till två > decimaler korrekt avrundat. Eller också kan man införa > avrundningsfunktionen (vars namn jag just nu inte kommer på), =AVRUNDA(<Cellreferens och/eller uttryck>;<Antal decimaler>) Exempelvis: =AVRUNDA(1/3;2) ⇨ 0,33 > där man > förändrar talvärdet till det man önskar. > > Det blev mycket det här, och kanske slår jag in öppna dörrar, ursäkta. > Jag kunde ha gjort det enkelt för mig och bara hänvisat till > hjälptexterna för där framgår de här konsekvenserna, men jag ville lägga > fram det på mitt vis, och då blev det så här. > Tänkte själv skriva ungefär samma sak (fast kanske aningen kortare), men nu slapp jag…! ☺ Vänliga hälsningar Johnny Rosenberg Kaj > > Den 2019-04-28 kl. 11:27, skrev Lars-Göran Hansson: > I vissa lägen räknar calc fel (någon form av öresutjämning som > programmet hittar på själv) i nedanstående kalkyl har jag lagt D15-D16 > och får 3005,0199999999?? > > Cellen D15 innehåller "=+160021,8+2862" > > och cellen D16 innehåller "159878,78" > > Ingen cell innehåller alltså mer än två decimaler > > Är detta någon känd bugg? > > > //Lars-Göran Hansson > > > > > -- > For unsubscribe instructions e-mail to: > users+unsubscr...@sv.libreoffice.org > Problems? > https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette > List archive: https://listarchives.libreoffice.org/sv/users/ > Privacy Policy: https://www.documentfoundation.org/privacy > -- For unsubscribe instructions e-mail to: users+unsubscr...@sv.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/sv/users/ Privacy Policy: https://www.documentfoundation.org/privacy
