Re: [it-users] errore Calc

Sembra quasi che ognuno abbia un LO e un Excel personale :-))

Per evitare malintesi ho fotografato le schermate mostrando anche la
finestra della formattazione.

Questo è quello che si vede con *Excel* se si imposta un numero abbastanza
alto di cifre decimali.
https://drive.google.com/file/d/15-_BKKtSazQ1ZV0iIgznFaHd4Av1Z8OP/view?usp=sharing

Questo è quello che si vede in *LibreOffice *che sembra permettere un po'
meno cifre decimali:
https://drive.google.com/file/d/18pOvjKItjm9O5D2ZywFt7Gb04sE2x6ji/view?usp=sharing

In entrambi i casi, all'inizio c'è un bel 4,69999999... di cui si è già
discusso il motivo fin troppo a lungo.
Alla fine c'è  una serie di zeri dovuti al numero limitato di cifre
significative utilizzate dal programma.

Andrea

Il giorno dom 22 ago 2021 alle ore 16:35 Marcolongo <
gianpaolomarcolongo@alice.it> ha scritto:

> Non sono arrampicate sugli specchi dipende da come sono impostati i
> default dei vari programmi. Se questi sono a 2 cifre decimali il
> problema non sussiste e mi pare ovvio. Se non c'è impostazione il numero
> dei decimali mostrati dipende dalla dimensioni della colonna.. Basta
> provare ad aggiungere decimali fino a 15 e qui scatta come Alessandro
> Malfatti ha fatto rilevare il 0,46(9) periodico. provare per credere.
>
> Miriam scrive
>
> l'operazione 101,42-101 da come risultato 0,420000000000002. Motivo
> problema di arrotondamento. Come ho scritto in precedenza l'arrotondamento
> avviene per difetto da 0 a 4 , per eccesso da 5 a 9. Nel caso in oggetto
> l'ultima cifra decimale è 2, quindi l'arrotondamento per difetto porta a 0.
> Per capire meglio la dinamica provate il valore pi greco. Con 2 cifre
> decimali è 3,14 ma aumentando le cifre vedrete comparire valori che variano
> con le cifre decimali impostate. Il calcolo è il seguente
> area/raggioxraggio. (area 3141549, raggio =1000). con 6 cifre decimali
> 3,141549, con 5 decimali 3,14155 e così via fino a 3,14. I computer usano
> un coprocessore matematico che svolge i calcoli in virgola mobile ed è
> tanto più preciso quante cifre decimali riesce a rappresentare.
>
> Comunque se avete fastidio con LO la rappresentazione con 9 periodico
> basta operare così. strumenti ->Opzioni-libreoffice Calc->calcola-> limita
> decimali del valore numero standard a _>impostate il valore che vi piace
> Quando una cella è numerica la sua rappresentazione decimale sarà quella
> impostata, anche se in formatta cella il campo è vuoto.
> Nessun bug di LO è una semplice impostazione del default, esattamente come
> per Writer si può impostare il suo modello di default all'apertura di un
> documento vuoto.
> Bello e interessante questo lungo scambio di mail ma forse qualcuno non li
> ha letti tutti e di conseguenza ha perso qualche spiegazione.
> Gian Paolo Marcolongo
>
> Il 22/08/21 11:34, Miriam ha scritto:
> > Mi scuso con la lista, solito problema con le accentate :(
> > Provo a rispostare in testo semplice
> >
> > --Inizio--
> > Salve a tutti,
> > ho letto l'intera discussione e sinceramente ho visto arrampicate sugli
> specchi incredibili che non penso aiutino la community.
> > Ho voluto fare delle prove dirette:
> > Su LO 7.1 (Win) posso confermare il problema che si ripete in tutti gli
> schermi simili ma non sempre con il 9 periodico.
> > Ad esempio l'operazione 101,42-101 da come risultato 0,420000000000002
> > Per visualizzare queste rappresentazioni è in effetti necessario
> allargare la colonna, questo nonostante già di default la larghezza della
> colonna consenta più di due decimali. A mio avviso è proprio questo il
> comportamento anomalo. In OpenOffice, in Softmaker Office ed anche in Excel
> modificare la larghezza della colonna non altera la rappresentazione del
> risultato (tranne ovviamene i casi in cui la lughezza del numero eccede lo
> spazio disponibile).
> > Come controprova ho ripetuto le stesse operazioni in OpenOffice 4.1.10
> su Win e Linux e del problema non c'è traccia. Tutti i calcoli che avete
> proposto nelle risposte precedenti danno il risultato esatto con due
> decimali. E questo indipendentemente dalla larghezza della colonna e dal
> numero di decimali impostato nel formato (ovviamente purché maggiore o
> uguale a 2).
> > Ipotizzando che il problema potesse essere legato al formato dei file
> (ODF 1.3 in LO, ODF 1.2 in OO) ho provato ad incrociare i dati. Il file che
> genera l'errore di calcolo in LO viene visualizzato con il risultato
> corretto in OpenOffice. Viceversa aprendo in LO il file creato con OO
> compaiono gli errori di approssimazione. Il formato di salvataggio quindi
> sembrerebbe ininfluente.
> > Spero che queste informazioni possano essere utili ad isolare il
> problema.
> > Poi che da un punto di vista numerico non ci siano grossi problemi, è
> vero. Ma non neghiamo l'evidenza. Cerchiamo di uscire dalla modalità
> 'fanboy' che certo non aiuta a risolvere la situazione (se fosse successo
> in Excell scrivereste le stesse cose?).
> > Miriam Greco
> >
> > --Fine--
>
> --
> 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

-- 
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