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 < [email protected]> 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 [email protected] > 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 [email protected] 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
