Re: [it-users] errore Calc

Spero che con le spiegazioni di Marco Marego si metta fine a questa
lunga discussione interessante  ma che adesso è diventata sterile,
perché vede contrapposti due fronti. Chi ritiene che calc sbagli e chi
invece no.

Il PC non è un essere umano dotato di razionalità ma è un insieme di
circuiti che conosce solo due stati 0 e 1, on e off, acceso o spento e
con tale struttura bisogna fare i conti. Poi c'è altro hardware che
traduce questi stati in qualcosa che i programmi - software - ci
mostrano sullo schermo. Il PC non sostituisce l'uomo ma lo aiuta in
operazione complesse che richiederebbero molto tempo. Di questo dobbiamo
essere consapevoli.

Qualcuno ha scritto che l'esempio di pigreco non è calzante. Invito a
fare questa breve prova. A scuola quando dovevamo calcolare l'area del
cerchio il valore di pigreco era 3,14, una semplificazione come abbiamo
saputo col passare degli anni. Quindi l'area del cerchio di raggio 2
vale 12,57. Se però si usasse il valore con tre decimali 3,142 l'area
diventa 12,566. È forse un errore? No di certo. Il valore è più
accurato. ma mano che aggiungo decimali il valore dell'area è sempre più
preciso. Quindi tornando a Calc, ma vale per qualsiasi foglio
elettronico, se vogliamo valori più precisi basta aumentare il numero di
decimali, come ha ben spiegato Marco Marego. In conclusione se due
posizioni decimali vanno bene basta impostare il valore a 2. Se si
ritiene che siano insufficienti dobbiamo aumentare questo valore nella
misura che ci serve nei calcoli per avere valori più precisi.

Marcolongo

Il 23/08/21 19:26, Marco Marega ha scritto:
> Il 23/08/21 09:54, Miriam ha scritto:
> > Buongiorno a tutti,
> > aggiungo qualche altra informazione dato che in azienda stiamo valutando l'impatto di questa 
> > situazione sui nostri fogli di calcolo.
> >
> > 1) un problema estremamente simile era stato segnalato anche su ASK
> > https://ask.libreoffice.org/t/strani-decimali-in-una-sottrazione-calc/47815
> > in questo caso l'arrotondamento non era visibile nella cella (che non era stata allargata) ma 
> > nella barra di stato (cosa che accade anche con gli esempi di cui stiamo discutendo)
> >
> > 2) l'utente che aveva posto da domanda ha giustamente sollevato un problema *potenzialmente 
> > molto più grave*:
> > Se il risultato approssimato viene utilizzato in un confronto logico si ottiene False in 
> > situazioni in cui invece si dovrebbe ottenere True. Capite che può essere un grosso problema 
> > risolvibile solo utilizzando formule di confronto molto più complesse di quelle standard. Su ask 
> > c'è anche un file di esempio.
> >
> > 3) se, come stanno sostenendo alcuni, l'approssimazione è normale ed è stata introdotta 
> > volontariamente, allora sarebbe interessante spiegare perché non succede se i valori coinvolti 
> > hanno un solo decimale: 12,5-12 da sempre 0,5 esatto senza approssimazione.
> >
> > M.G.
> >
> > --
> >
> > Sent: Sunday, August 22, 2021 at 5:59 PM
> > From: "Miriam" <tsubaki@gmx.com>
> > To: users@it.libreoffice.org
> > Subject: Re: [it-users] errore Calc
> > Piccolo aggiornamento:
> > Ho riscontrato il bug nella 7.1.0.3 (come scritto sopra) ma anche nelle versioni 6.4.2.2 e 
> > 5.4.7.2 e nella versione online (quella fornita da GMX). Il bug invece NON è presente nella 
> > versione 4.4.7.2
> > (ho usato queste versioni perché ne avevo una copia d'archivio)
> Buongiorno,
>
> 1) un conto è la rappresentazione che si vede nella cella, che dipende
> da come questa è formattata e dalle impostazioni indicate nelle opzioni,
> un altro conto è il valore che il computer ha in memoria e che per molti
> numeri decimali (non tutti) può essere un'approsimazione (con differenze
> infinitesime, ma pur sempre un'approsimazione)
>
> 2) il problema si risolve con un arrotondamento ai due decimali, non
> servono formule molto complesse, basta un =ARROTONDA(A1-A2;2), nel caso
>  posto inizialmente da Francesca sarebbe =ARROTONDA(241,47-241;2).
> Capisco che ragionando in base 10 possa sembrare strano arrotondare il
> risultato di una sottrazione, cosa che verrebbe più naturale da fare ad
> esempio con una divisione.
> Inoltre per la stragrande maggioranza dei calcoli la differenza è così
> piccola, che basta formattare le celle con i soli decimali che servono e
> non ci si accorge nemmeno del problema.
>
> 3) l'approssimazione è normale, ma NON è stata introdotta
> volontariamente, semplicemente lavorando in base 2 e con un determinato
> numero di bit a disposizione è inevitabile, così come in base 10 è
> inevitabile che la rappresentazione di 1/3 sia 0,3333 con il 3
> periodico. Ogni decimale che viene aggiunto avvicina l'approssimazione
> all'effettivo valore di 1/3, ma non sarà mai lo stesso, seppure per una
> differenza microscopica.
> Per puro caso nel tuo esempio hai usato lo 0,5, che è un valore decimale
> rappresentabile esattamente sia in base 10, sia in base 2.
>
> Il problema è trattato in maniera abbastanza chiara in questa pagina del
> tutorial che parla del linguaggio di programmazione Python
> https://pytutorial-it.readthedocs.io/it/python3.9/floatingpoint.html
>
> Anche in questo documento si precisa che non è un bug di Python e che il
> problema riguarda anche gli altri linguaggi di programmazione.
> Allo stesso modo Calc condivide il problema con gli altri fogli
> elettronici. Ognuno dei quali poi a video rappresenta il numero come
> meglio crede, lasciando o meno all'utente la scelta delle impostazioni
> predefinite, ma di fondo, indipendentemente da ciò che viene mostrato,
> il valore in memoria è comunque approssimato.

-- 
Come cancellarsi: E-mail users+unsubscribe@it.libreoffice.org
Problemi? https://it.libreoffice.org/supporto/mailing-lists/come-cancellarsi/
Linee guida per postare + altro: https://wiki.documentfoundation.org/Local_Mailing_Lists/it
Archivio della lista: https://listarchives.libreoffice.org/it/users/
Privacy Policy: https://www.documentfoundation.org/privacy