[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sv-users] calc räknar fel


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

References:
Re: [sv-users] calc räknar fel"Kaj Persson <kape_fsp@telia.com>" <kape_fsp@telia.com>
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.