Microsoft Excel 2007 sbaglia le moltiplicazioni

[manowar84]

Originariamente inviato da diabolik1981

quindi è un bug nuovo, non un ritorno di uno vecchio

guarda da quello che ho capito (e potrei sbagliarmi) era un bug vecchio che è stato successivamente corretto nelle versioni 95 e 97 ed è rispuntato fuori! Da quello che ho capito, potrei sbagliarmi

[zago]

a me a dire il vero sbaglia anche a farci le operazioni nn solo a visualizzare il risultato

visualizzare vuol dire che io ho 65535 in A1 e ti faccio vedere 100000 ma se faccio A2=A1+1 mi da 65536 e nn 100001 come effettivamente fa

[Cimmo]

Originariamente inviato da diabolik1981

oltretutto all'epoca dell'articolo forse non ero ancora iscritto.

si si ho cannato io.
Cmq quello che mi da' fastidio e' l'arroganza di Microsoft a voler imporre l'OOXML come standard ISO a tal punto che corrompe della gente dandole dei soldi.

Poi il suo formato e' bacato fino all'osso e non mi riferisco a questo bug in particolare, ma al link postato nelle precedenti pagine.

E poi salta fuori gente che dice che Office e' una spanna sopra, si' forse come interfaccia, ma come salvataggio dati sono dell'idea che OO sia migliore.
Poi certo che un software ha dei bug sempre e comunque, ma ripeto non mi riferisco a questo bug in particolare, ma a molti altri e alla linea sempre scorretta che adotta MS.

[sari]

Originariamente inviato da coschizza

condivido di principio ma nel mondo reale queste restano delle teorie che è difficile da mettere in pratica.

il debug è stato fatto da centinaia di migliaia di persone per oltre 1 anno ma non sarebbero bastate nemmeno milioni per torvare un bug simile, altrimenti in anni di sviluppo qualcuno lo avrebbe gia segnalato.

Non hai capito il punto. Che sia impossibile testare ogni possibile input ok, ma che non si testi nemmeno con input fonte di errore in passato è da azienducola di paese, un insulto all'ingegneria del software.

Vecchio bug come si diceva che rispunta:
http://support.microsoft.com/default...;en-us;Q161234

[corgiov]

Il problema non viene negato da Microsoft che però fa notare come l'errore sia solo in fase di visualizzazione del risultato nella cella, infatti, effettuando successivi calcoli in cui si prende come dato iniziale il precedente risultato di una delle moltiplicazioni in oggetto si perviene a un risultato corretto. Si evince, quindi, che Excel 2007 non sbaglia a fare i conti ma solo nel presentare i risultati: magra consolazione.

Fatto l'esperimento: l'errore resta!
Ho prima creato una moltiplicazione identica a quella indicata, 77,1x850. Mi dà 100000. Poi ci ho addizionato lo 0, e mi dà nuovamente 100000 (ossia 0+x=100000, dove x=100000=65535).
C'è davvero qualcosa che non va!

[dannyb78]

Il problema non viene negato da Microsoft che però fa notare come l'errore sia solo in fase di visualizzazione del risultato nella cella, infatti, effettuando successivi calcoli in cui si prende come dato iniziale il precedente risultato di una delle moltiplicazioni in oggetto si perviene a un risultato corretto. Si evince, quindi, che Excel 2007 non sbaglia a fare i conti ma solo nel presentare i risultati: magra consolazione.

VERO... ma avete provato a sommare o sottrarre 1 a quel risultato? Qualunque altra operazione ottiene il risultato corretto, ma 77,1*850 + o - 1 dà 100001 o 99999

[riva.dani]

Dai su, io uso GNU/Linux e OpenOffice, ma non è certo un bug come questo ad influenzare le mie scelte: i motivi sono ben altri!

[bonzuccio]

A me funzia perfettamente, versione Microsoft(R) Excel 2002 10.6816.6817 SP3

=77,1*850

risultato 65535

[sari]

Originariamente inviato da LucaNoize

scusami, ma l'errore che hai linkato non c'entra nulla con il nuovo bug...li si parla di un errore nel caso di calcoli con numeri fra 32,768 and 65,535 che hanno una porzione decimale uguale a .848 (che viene visualizzata come .8479999999)

forse sono ignorante io ma mi spiegate bene cosa c'entra con il bug oggetto della discussione??

Raccolta di input per la verifica e la validazione.

[Sapo84]

Originariamente inviato da sari

Ora, quanto meno avrebbero potuto inserire nella fase di debugging anche un test per la valutazione e individuazione di questo errore. A qualsiasi corso di ingegneria del software insegnano a produrre dei buoni test di validazione.

Certo, infatti 12 valori su 18446744073709551616 sono sicuramente beccati in fase di debug.
L'importante è esserne convinti dopotutto.

Originariamente inviato da LucaNoize

scusami, ma l'errore che hai linkato non c'entra nulla con il nuovo bug...li si parla di un errore nel caso di calcoli con numeri fra 32,768 and 65,535 che hanno una porzione decimale uguale a .848 (che viene visualizzata come .8479999999)

forse sono ignorante io ma mi spiegate bene cosa c'entra con il bug oggetto della discussione??

Non c'entra niente infatti, quello è un problema dovuto al fatto che excel non usa l'aritmetica decimale e quindi ci saranno sempre degli errori di approssimazione.

Originariamente inviato da sari

Raccolta di input per la verifica e la validazione.

Ok, è evidente che tu non abbia idea di ciò di cui stai parlando (a sproposito aggiungerei)

[cdimauro]

Originariamente inviato da Sapo84

Certo, infatti 12 valori su 18446744073709551616 sono sicuramente beccati in fase di debug.
L'importante è esserne convinti dopotutto.



Non c'entra niente infatti, quello è un problema dovuto al fatto che excel non usa l'aritmetica decimale e quindi ci saranno sempre degli errori di approssimazione.


Ok, è evidente che tu non abbia idea di ciò di cui stai parlando (a sproposito aggiungerei)

Quoto. Sono due bug diversi, com'è attestato qui: http://blogs.msdn.com/excel/archive/...ue-update.aspx e qui http://support.microsoft.com/default...;en-us;Q161234
Com'è evidente, i problemi sono dovuti a 12 precisi valori.
Poi ovviamente è impossibile effettuare dei test su una quantità esorbitante di valori rappresentabili dal formato IEEE 754 a doppia precisione: sarebbe da folli.

A chi parlava dell'esistenza di applicazioni per il controllo della correttezza del codice suggerisco una bella ripassatina alla teoria della computabilità, e in particolare al problema dello stop: http://en.wikipedia.org/wiki/Halting_problem

"In computability theory the halting problem is a decision problem which can be informally stated as follows:
Given a description of a program and a finite input, decide whether the program finishes running or will run forever, given that input.

Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. We say that the halting problem is undecidable over Turing machines."

Turing si starà ribaltando nella tomba...

Infine sulla precisione dei calcoli con Excel c'è questo http://support.microsoft.com/kb/78113/EN-US/ documento che spiega bene la situazione.
Chi opera con dati di tipo finanziario e ha la necessità di eseguire dei calcoli PRECISI deve prendere in seria considerazione l'eventualità che ci possano essere degli errori.
Per i calcoli precisi esistono altri tipi di dato che sono stati creati appositamente (il Currency, ad esempio).

Quella che è stata montata (ad arte, perché il titolo della news è tutto un programma) è una polemica del tutto inutile e faziosa. Come al solito.

[r.chiodaroli]

Ho reperito una approfondita spiegazione al problema e la riporto per una lettura

http://www.joelonsoftware.com/items/2007/09/26b.html

[M4R1|<]

@ FX (il primo post)

LOL asd

[Cimmo]

Originariamente inviato da cdimauro

Quella che è stata montata (ad arte, perché il titolo della news è tutto un programma) è una polemica del tutto inutile e faziosa. Come al solito.

fazioso e' il modo come la interpreti.
Certo lo so non esiste un programma che controlla la correttezza di un altro programma, infatti non ho mai detto questo io (e lo so che non ti rivolgi a me), pero' visto che un programmatore di Office sa bene dove sono i limiti del proprio software non credi che sarebbe stato utile provare quelle combinazioni di valori che portano all'estremo del tuo dato?

In altre parole: se io immagazzino un dato in un intero e voglio essere sicuro che non ci siano bug testero' il caso quando passo da intero a double o no? Insomma si insegna al primo anno di informatica di testare "gli estremi" degli input prima di tutto.
Caso pila vuota, caso pila piena... dai...

Ripeto:
non c'e' il programma perfetto e ok, non si puo' scovare tutti i bug e ok, non esiste un programma che testa un altro programma e ok, ma i test case ci sono e dovrebbero proprio beccare i casi dove il programmatore sa che ci possono essere errori di questo tipo e mi sembra che questo sia un bug "classicissimo".

Cmq tenendo conto che ci puo' stare anche questo bug (e l'ho gia' detto piu' volte) che mi dici del formato bacato OOXML? Faziosa e' la gente che non risponde ai quesiti e devia su altre cose.

[figliodierica]

Sulla prossima versione di Microsoft Office pretendo uno sconto del 34.465000000000001%!

[WarDuck]

Originariamente inviato da corgiov

Fatto l'esperimento: l'errore resta!
Ho prima creato una moltiplicazione identica a quella indicata, 77,1x850. Mi dà 100000. Poi ci ho addizionato lo 0, e mi dà nuovamente 100000 (ossia 0+x=100000, dove x=100000=65535).
C'è davvero qualcosa che non va!

Scusami ma che test sarebbe? Se ci aggiungi 0 è normale che ricompare lo stesso valore...

[bonzuccio]

Originariamente inviato da WarDuck

Scusami ma che test sarebbe? Se ci aggiungi 0 è normale che ricompare lo stesso valore...

Che bello che fa if 0 then stesso valore?

[cdimauro]

Originariamente inviato da Cimmo

fazioso e' il modo come la interpreti.

IO la interpreto da programmatore navigato, e senza farmi condizionare da ideologie e sentimentalismi: mi sembra un buon punto di partenza per un professionista, non credi?

Tu come lo interpreti, invece?

Certo lo so non esiste un programma che controlla la correttezza di un altro programma, infatti non ho mai detto questo io (e lo so che non ti rivolgi a me), pero' visto che un programmatore di Office sa bene dove sono i limiti del proprio software non credi che sarebbe stato utile provare quelle combinazioni di valori che portano all'estremo del tuo dato?

Lo stesso che hai scritto vale per QUALUNQUE software: OGNI programmatore, secondo te, dovrebbe conoscere i limiti del proprio software, ma "STRANAMENTE" il mondo è pieno di applicazioni, closed od open source, il cui changelog è fitto di "bug-fixed".

Il che, alla luce del problema dello stop che ho riportato, è a dir poco ovvio.

In altre parole: se io immagazzino un dato in un intero e voglio essere sicuro che non ci siano bug testero' il caso quando passo da intero a double o no? Insomma si insegna al primo anno di informatica di testare "gli estremi" degli input prima di tutto.
Caso pila vuota, caso pila piena... dai...

Esatto, ma in questo caso l'input dell'utente NON può essere rappresentato correttamente perché è in formato IEEE 754: anche questo lo insegnano al primo anno di informatica.

Questo formato offre una precisione LIMITATA, e mi sembra a dir poco ovvio. Ecco perché possono venir fuori risultati sbagliati, come in questo caso.

Ripeto:
non c'e' il programma perfetto e ok, non si puo' scovare tutti i bug e ok, non esiste un programma che testa un altro programma e ok, ma i test case ci sono e dovrebbero proprio beccare i casi dove il programmatore sa che ci possono essere errori di questo tipo e mi sembra che questo sia un bug "classicissimo".

Se fosse un bug "classicissimo" esisterebbe anche un test case "classicissimo". Peccato che i bug siano... bug per definizione quando vengono individuati, ed è già... troppo tardi.

La programmazione TDD di per sé permette di scrivere codice priva di errori. Sicuramente dà un ottimo contribuito, ma qualcuno i test li deve scrive, e guarda caso sono gli stessi programmatori che, commettendo un errore, introducono bug nelle loro applicazioni.

Cmq tenendo conto che ci puo' stare anche questo bug (e l'ho gia' detto piu' volte) che mi dici del formato bacato OOXML? Faziosa e' la gente che non risponde ai quesiti e devia su altre cose.

Faziosa è la gente che sposta la discussione che ha un BEN PRECISO ARGOMENTO su altri che non c'entrano una beata mazza, come in questo caso.
Io mi sono limitato a rimanere in topic, ed è quello che qui, invece, fanno in pochi, visto che appena c'è una notizia che parla di Windows, immancabilmente saltano fuori i troll fanatici di Linux, OS X, ecc. a dire quant'è bello il loro sistema e quanto è merdoso il primo; se c'è una notizia su Office salta fuori OpenOffice, e puttanate varie. Le diatribe sono sempre le stesse.

In ogni caso se vuoi una risposta (scontata, perché tanto sai già che non ho alcuna difficoltà a fare a pezzi le balle che vengono scritte dai fanatici, come ho sempre fatto finora), apri una discussione su un'apposita sezione, e non avrò alcuna difficoltà ad affrontare l'argomento, visto che non mi sono mai tirato indietro.
Così mettiamo una pietra tombale anche sul formato OXML.

[Sapo84]

Originariamente inviato da Cimmo

fazioso e' il modo come la interpreti.
Certo lo so non esiste un programma che controlla la correttezza di un altro programma, infatti non ho mai detto questo io (e lo so che non ti rivolgi a me), pero' visto che un programmatore di Office sa bene dove sono i limiti del proprio software non credi che sarebbe stato utile provare quelle combinazioni di valori che portano all'estremo del tuo dato?

In altre parole: se io immagazzino un dato in un intero e voglio essere sicuro che non ci siano bug testero' il caso quando passo da intero a double o no? Insomma si insegna al primo anno di informatica di testare "gli estremi" degli input prima di tutto.
Caso pila vuota, caso pila piena... dai...

Ripeto:
non c'e' il programma perfetto e ok, non si puo' scovare tutti i bug e ok, non esiste un programma che testa un altro programma e ok, ma i test case ci sono e dovrebbero proprio beccare i casi dove il programmatore sa che ci possono essere errori di questo tipo e mi sembra che questo sia un bug "classicissimo".

Passaggio da intero a double
Visto che viene detto che si parla di 6 valori tra 65534.99999999995 e 65535 e altri 6 tra 65534.99999999995 e 65536, che non mi sembrano proprio il passaggio da un intero a 32 bit (tra l'altro unsigned, mah) a uno a 64 bit non saprei se la spiegazione è così semplice come vuoi farla tu.
L'unico modo per avere qualche certezza sarebbe poter spulciare il codice, ma dato che dubito che qualcuno ne avrà mai la possibilità eviterei di buttarmi in spiegazioni senza prove certe.

[afterburner]

Questo bug in Excel 2007 mi ricorda molto questa situazione ...

Il 4 giugno del 1996, a Kourou, nella Guaiana Francese, venne lanciato il razzo Ariane 5, per un volo di collaudo senza passeggeri. Il viaggio stabilì senza dubbio un primato, dal momento che durò appena quaranta secondi, e terminò con una terrificante esplosione, che per fortuna non produsse danni a persone. L'imbarazzante episodio venne trasmesso in mondovisione, con gran dispetto per l'Agenzia Spaziale Europea, che sul progetto Ariane aveva messo in gioco la propria credibilità. Un team di esperti fu incaricato di indagare sul disastro; dopo un'attenta analisi, giunsero alla conclusione che la causa del fallimento era stato un errore software nel sistema di riferimento inerziale. Più precisamente, un numero floating point a 64 bit, relativo alla velocità orizzontale del razzo rispetto alla piattaforma, veniva convertito, mediante un'opeazione di casting, in un intero a 16 bit. Non appena il valore superò la fatidica soglia di 32.768, l'operazione cominciò a produrre valori sballati, che mandarono in crisi il sistema di navigazione. Questa circostanza provocò l'attivazione del sistema di autodistruzione, che polverizzò il razzo prima che potesse perdere il controllo e precipitare chissà dove.

Lo sviluppo di Ariane aveva richiesto, nell'arco di un decennio, una spesa complessiva di circa 7 miliardi di dollari. Al momento del lancio, il razzo trasportava quattro satelliti per telecomunicazioni, del valore complessivo di circa 500 milioni di dollari. Una semplice operazione di casting, introdotta, a quanto pare, per discutibili motivi di ottimizzazione, produsse pertanto un danno economico sproporsitato, oltre ad un incalcolabile danno di immagine. A completare il quadro, pare che il carico non fosse neppure stato assicurato, una circostanza che probabilmente fornì nuovi corollari al celebre elenco delle "Leggi di Murphy" (*).

Forse anche allora qualcuno deve aver pensato che "e' un'eventualita' che non si presentera' mai" ....

Poi, come al solito c'e' sempre qualcuno che complica con la fumosita' dell'informatica teorica cose terra terra come la rappresentazione binaria floating point dei numeri in base 10 e grida a complotti anti-microsoft ...