[sv-users] calc räknar fel

classic Classic list List threaded Threaded
7 messages Options
Lars-Göran Hansson Lars-Göran Hansson
Reply | Threaded
Open this post in threaded view
|

[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,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: [hidden email]
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

Lars-Göran Hansson Lars-Göran Hansson
Reply | Threaded
Open this post in threaded view
|

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,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: [hidden email]
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

Lars-Göran Hansson Lars-Göran Hansson
Reply | Threaded
Open this post in threaded view
|

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,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: [hidden email]
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

Kaj Persson Kaj Persson
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Lars-Göran Hansson
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,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: [hidden email]
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
Kaj Persson Kaj Persson
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Lars-Göran Hansson
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 : [hidden email]
>Datum : 2019-04-28 - 11:27 (CEST)
>Till : [hidden email]
>Ä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,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: [hidden email]
>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: [hidden email]
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
Johnny Rosenberg Johnny Rosenberg
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Kaj Persson
Den sön 28 apr. 2019 kl 19:53 skrev Kaj Persson <[hidden email]> <
[hidden email]>:

> 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:
> [hidden email]
> 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: [hidden email]
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
Jan Öhman-3 Jan Öhman-3
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Kaj Persson
Jag tyckte att förklaringen var grundlig och bra!
Tack för din tid!

Den 2019-04-28 kl. 19:52, skrev Kaj Persson <[hidden email]>:

> 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,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: [hidden email]
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