Date: prev next · Thread: first prev next last


Den sön 28 apr. 2019 kl 19:53 skrev Kaj Persson <kape_fsp@telia.com> <
kape_fsp@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+unsubscribe@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+unsubscribe@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.