Re: [sv-users] calc räknar fel
Den sön 28 apr. 2019 kl 19:53 skrev Kaj Persson < 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(;) 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,01?? > > 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:
Re: [sv-users] calc räknar fel (2)
Hej igen! Nu kom jag på vad avrundningsfunktionen heter. Det var ju rätt självklart, och jag klistrar in syntaxen från hjälpsidorna: AVRUNDA Rundar av ett tal till ett visst antal decimaler. Syntax AVRUNDA (Tal; Antal) Returnerar Tal avrundat till Antal decimaler. Om Antal utelämnas eller är noll avrundar funktionen nedåt till närmsta heltal. Om Antal är negativt så avrundar funktionen till nästa 10, 100, 1 000 o.s.v. Hälsningar Kaj >Ursprungligt meddelande >Från : l...@lgr.se >Datum : 2019-04-28 - 11:27 (CEST) >Till : users@sv.libreoffice.org >Ämne : [sv-users] calc räknar fel > >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,01?? >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
Re: [sv-users] calc räknar fel
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å), 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. 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,01?? 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
Re: [sv-users] calc räknar fel
Om man testar att lägga 10,8 i en cell och -10,78 i cellen under och klickar "summa" får man ytterligare ett annat fel. Vågar man använda detta program i fortsättningen? //L-G Den 2019-04-28 kl. 14:32, skrev Lars-Göran Hansson: Har testat även i tomma blad (lagt in exakt nedanstående siffror och får samma fel (det gäller att cellen är tillräckligt bred) //L-G 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,01?? 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
Re: [sv-users] calc räknar fel
Har testat även i tomma blad (lagt in exakt nedanstående siffror och får samma fel (det gäller att cellen är tillräckligt bred) //L-G 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,01?? 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
