Link alla notizia: http://www.hwupgrade.it/news/software/microsoft-excel-2007-sbaglia-le-moltiplicazioni_22690.html

Un errore in fase di visualizzazione del risultato è alla base di un grosso problema relativo a Microsoft Office 2007

Click sul link per visualizzare la notizia.

:eek:

non finiranno mai di stupirmi...

Dal blog di MS comunque dicono che è solo un bug di visualizzazione, che se si usa la cella nei calcoli il valore è esatto... Comunque si sapeva già da un po' di giorni...

ecco perchè dopo aver emesso e inviato via email una fattura il cui totale era 65535 euro il cliente mi ha versato 100000 euro :asd:

beh, peccato :asd:

Mi da, ogni giorno, un motivo nuovo per non usare i suoi prodotti. :)
Che una cosa del genere possa succedere su un software che si paga a peso d'oro mi sembra abbastanza vergognosa.

Mi da, ogni giorno, un motivo nuovo per non usare i suoi prodotti. :)
Che una cosa del genere possa succedere su un software che si paga a peso d'oro mi sembra abbastanza vergognosa.

Concordo :rolleyes:

Mi da, ogni giorno, un motivo nuovo per non usare i suoi prodotti. :)
Che una cosa del genere possa succedere su un software che si paga a peso d'oro mi sembra abbastanza vergognosa.

Vergognoso sarebbe se non sviluppassero fix o negassero addirittura il problema... cmq basta saperlo e in attesa del fix ci si arrangia...

Un altro esempio del reale valore dei prodotti MS

Bhe è un bug difficilissimo da scovare...

cosa dovevano fare provare tutte le operazioni del mondo?

Mi da, ogni giorno, un motivo nuovo per non usare i suoi prodotti. :)

ah beh perchè altrimenti prima li usavi eh? =)

Che una cosa del genere possa succedere su un software che si paga a peso d'oro mi sembra abbastanza vergognosa.

oh, difatti quei software altamente specifici che si pagano 10 volte tanto office non hanno bachi, non hanno bachi gravi, e hanno le patch prima ancora che il baco si manifesti

Mi da, ogni giorno, un motivo nuovo per non usare i suoi prodotti. :)
Che una cosa del genere possa succedere su un software che si paga a peso d'oro mi sembra abbastanza vergognosa.

in materia c'è un illustre precedente di altra casa...

in materia c'è un illustre precedente di altra casa...

con la differenza che non lo paghi a peso d'oro.

Un altro esempio del reale valore dei prodotti MS

io uso fondamentalmente linux

ti dico solo che ad es. nel php certi bug li ho scovati io, il che è tutto dire (ovvero: erano un tantinello più visibili di questo). questo è un esempio del reale valore dell'open source? ma proprio no, sia da una parte che dall'altra i bachi ci sono (e sicuramente, al di là di ogni polemica, ci sono - se escludiamo il kernel e altre due cose - molto di più in linux), quello che fa il valore sono altre cose, tant'è che reputo sia excel che il php per il loro target, con i loro limiti, entrambi buoni prodotti.

edit: ah, per inciso... ho anche provato ad usare OOO per sostituire excel, peccato che appena appena fai cose un pelo più complesse della fattura si rileva completamente inadatto (ad es. a collegare celle di file diversi, o ad assegnare variabili)... alla fine si possono contestare certe scelte, però excel rimane un prodotto valido e ben fatto (e poi qualche bug ci può anche essere... ah, coloro che si scandalizzano tanto immagino non abbiano più comprato processori intel dal pentium in avanti eh? hiihihihih)

con la differenza che non lo paghi a peso d'oro.

si... almeno 1000€... e per risolvere il problema ci hanno messo anche un po di tempo

Onestamente non capisco la presunzione che si ha, credendo che un software a pagamento possa essere esente da bug in quanto tale...

PS: credo che nella maggiore delle ipotesi la prossima settimana avremo un fix, e cmq se è saltato solo ora il problema evidentemente non è così comune o così evidente.

la notizia (di ieri) su html.it era leggermente diversa...
facendo diversi tipi di operazione sulla cella incriminata, alcune volte il risultato era corretto mentre altre volte no, prova del fatto che il datto della cella non era memorizzato nello stack della FPU

Bhe è un bug difficilissimo da scovare...

cosa dovevano fare provare tutte le operazioni del mondo?

Un codice di qualità è progettato in maniera da prevenire questi bug.
Programmare alla carlona e poi lasciare spazio ai tester per trovare le magagne è un modo di lavorare che poteva andare bene in ambito amatoriale 25 anni fa ma non certo adesso con un programma critico come excel.

chi si aspetta che esista SW senza bug è proprio.. un simpatico bricconcello (che non ha mai speso un minuto a programmare niente di più del videoregistratore)

il SW nasce buggato, non c'è niente da fare. e questo vale per tutto il SW.

la cosa che lascia un po di stucco è che il processo di test e verifica non abbia colto questo bug, che si, non è proprio facile da scovare ma neanche cosi impossibile da prevedere direi.

ad ogni modo: patch e via :D

evviva openoffice!

Mi sembra inutile tanto clamore su un errore che ammonta appena al 52%... I soliti pregiudizi Microsoft. Se gli utonti fossero più istruiti, eviterebbero di leggere i numeri visualizzati da Excel ed il problema non sussisterebbe!

si... almeno 1000€... e per risolvere il problema ci hanno messo anche un po di tempo

Pensavo ti riferissi a questo bug di openoffice calc:
assing a<-127 to RCalcDump will cause it to print the outputs of the previous statement rather than this one.

A cosa ti riferivi?

hehe chissà quante fatture sono state già stampate :)

oh, difatti quei software altamente specifici che si pagano 10 volte tanto office non hanno bachi, non hanno bachi gravi, e hanno le patch prima ancora che il baco si manifesti

Visto che entri in questo campo, permettimi di fare una piccola
precisazione:
Quei software "specifici" che paghi a peso d'oro spesso li paghi così tanto
perchè hanno molto meno mercato.

Intendiamoci: non è che il codice di au*ocad sia così migliore di quello
altrui da giustificare la spesa, solo che au*ocad lo comprano (non lo
copiano, lo comprano) realmente solo i professionisti, e questo fa sì che
pur essendo il miglior software nel suo genere venda meno di un decimo
delle copie che vende Office.
Ovvio però che i programmatori (e con loro i commerciali al seguito) vorranno/dovranno
mangiare lo stesso cibo, guidare le stesse auto, etc.etc. da qui la differenza di prezzo
(e non da qualità intrinseca del codice o che altro....)

Pensavo ti riferissi a questo bug di openoffice calc:
assing a<-127 to RCalcDump will cause it to print the outputs of the previous statement rather than this one.

A cosa ti riferivi?

alla calcolatrice impazzita di OSX

io uso fondamentalmente linux

ti dico solo che ad es. nel php certi bug li ho scovati io, il che è tutto dire (ovvero: erano un tantinello più visibili di questo). questo è un esempio del reale valore dell'open source? ma proprio no, sia da una parte che dall'altra i bachi ci sono (e sicuramente, al di là di ogni polemica, ci sono - se escludiamo il kernel e altre due cose - molto di più in linux), quello che fa il valore sono altre cose, tant'è che reputo sia excel che il php per il loro target, con i loro limiti, entrambi buoni prodotti.

edit: ah, per inciso... ho anche provato ad usare OOO per sostituire excel, peccato che appena appena fai cose un pelo più complesse della fattura si rileva completamente inadatto (ad es. a collegare celle di file diversi, o ad assegnare variabili)... alla fine si possono contestare certe scelte, però excel rimane un prodotto valido e ben fatto (e poi qualche bug ci può anche essere... ah, coloro che si scandalizzano tanto immagino non abbiano più comprato processori intel dal pentium in avanti eh? hiihihihih)

Anche io uso Linux tutti i santi giorni visto e considerato che nella mia rete aziendale la parte server è solo Linux/Unix (c'è qualche solaris sparso in giro :cool: ).
Lavoro con il PHP da parecchi anni ormai e ho avuto modo di lavorare (bestemmiare in realtà ma è perchè Excel odia me e io odio lui) con Excel.
Il problema non è tanto il fatto che il bug ci sia (a parte che è veramente un bug grossolano e il non averlo visto significa il non avere fatto un minimo di testing ed aver lasciato agli utenti PAGANTI tale compito) ma il fatto che un bug del genere (dite quello che volete ma è gravissimo a mio avviso) sia in un prodotto costoso come Excel 2007. Insomma se la politica di MS è quella di dire :"Paghi noi ed hai delle garanzie" perchè è questo che vogliono far credere con le loro campagne pubblicitarie questo bag ed il loro minimizzarlo significa solo che hanno le tasche ben piene dei soldi degli utenti ed iniziano (già da tempo) a strafregarsene.

No mi spiace, un bug del genere è grave sia che sia su un prodotto Open source sia che sia su un prodotto proprietario, ma nel secondo caso c'è l'aggravante del costo del prodotto che, IN TEORIA, dovrebbe garantirmi l'esenza da bug così grossolani.

:old:

Questo identico bug è presente in moltissime edizioni di Office e non è mai stato corretto. (ricordo di averlo visto per la prima volta a scuola sul 95 o sul 97 :D )

Sulle versioni più recenti non c'era, come abbia fatto a rispuntare adesso è un mistero :confused:

IMHO un bel cut&paste da vecchio codice :oink:

Mi trovo ancora una volta a dover criticare il contenuto di un articolo di hwupgrade, che dal mio punto di vista ha raggiunto livelli molto molto bassi.
Il titolo di questo articolo è "Microsoft Excel 2007 sbaglia le moltiplicazioni" che non lascia spazio a interpretazioni. Ma nell'articolo stesso si legge anche "Si evince, quindi, che Excel 2007 non sbaglia a fare i conti ma solo nel presentare i risultati".

Vecchia e lecita l'idea di presentare un titolo ad effetto, ma in questo caso è solo errato e fuorviante.

... perseverare è stupido... fregarsene è umano

da html.it

L'errore di calcolo ha presentato l'occasione per ricordare un altro bug presente in Office sin dalla versione 5 e che si ripropone immutato anche nella edizione 2007: nel caso si scriva o calcoli un numero compreso tra 32.768 e 65.535 che contiene una porzione decimale di .848, il numero viene visualizzato con una porzione decimale di .8479999999.


Ok che non esistono software perfetti, ma almeno bachi di 10 anni fa :rolleyes:

che sbagli a mostrare i risultati è altrettanto grave che se sbagli a fare i calcoli. I fogli di calcolo vengono usati principalmente per restiutire dei risultati agli occhi dell'operatore: se questi programmi visualizzano un risultato non valido, anche se l'algoritmo che sta sotto restiuisce un numero corretto, rischiano di causare danni ingenti.
Molte società utilizzano excel per fare e stampare fatture ai propri clienti

Bhe è un bug difficilissimo da scovare...

cosa dovevano fare provare tutte le operazioni del mondo?

Sarà difficilissimo, ma è un operazione banalissima, dimmi te che cavolo cobinano...

devo prendere un valore e semplicemente visualizzarlo... per cose più complicate che facciamo, diciamo un rosario? :D

Mi sto preoccupando... ma come programma la gente? Ha bisogno di buttare dentro un fix per ogni operazione? Del tipo: "fixata la visualizzazione del risultato di 124.523*12314.124124". Ma lavorano con tabelle con tutti i risultati possibili immaginabili da cui il programma pesca con chiave "i due moltiplicandi inseriti dall'utente"?

thread ciclici:O

Trovatemi un altro foglio di calcolo con 1.000.000 di righe e che abbia le stesse funzioni di excel+asap utilities... e lo userò con piacere ;)

:eek:


le macchine si stanno ribellando...è la fine. :sofico:

Incredibile :eek:

Mi da, ogni giorno, un motivo nuovo per non usare i suoi prodotti. :)
Che una cosa del genere possa succedere su un software che si paga a peso d'oro mi sembra abbastanza vergognosa.

i bug esistono a prescindere da quanto li paghi, esisteranno sempre e la MS non puo farci niente nemmeno investendo tutti i soldi del mondo.

visto che preferite software open vi faccio un esempio pratico di come tunno non è esente da errori.

tempo fa ho richiesto il rimborso di 8 euro per una spesa in una missione, sullo scontrono era indicato 16.000lire, l'addetto ha inserito questa cifra nella mia busta paga con il risultato che mi sono trovato oltre 16.000 euro in busta paga il mese precedente, il bello è che a detta di chi ci ha fatto il software ci sono dei controlli che impediscono queste cose.

il nostro software è open e fatto in casa da una azienda che ci ha investito negli anni alcuni milioni di euro............

tutta l'azienda si basa su office ed excel è non è mai capitato che un bug o errore del programmaabbia generato errori in fatture o altro, quindi non trovo che questo bug sia piu o meno grave di altri, c'è e va risolto subito ma non rende vergognoso o altro un software.

Questo non è un normale bug, mi immagino solo i guai che potrebbe combinare in campo finanziario... pensate ad un errore del 50% sul fatturato di una media azienda (poichè spero che nelle grandi aziende si usi altro) e traete le vostre conclusioni. Un conto è la calcolatrice che mi sbaglia un calcolo, un conto è un software spesso posizionato in situazioni critiche che produce un errore del genere. Pensate se Padoa-Schioppa si trovasse davanti a questo errore nel tentativo di valutare a grandi linee una possibile strada da seguire per la prossima finanziaria, a quel punto non so quanto potrebbe valere il discorso "tra una settimana abbiamo il nostro bugfix" oppure "trovami un software senza bug"... i processi di sviluppo per software critici esistono e funzionano e servono ad evitare situazioni come questa.

Questo non è un normale bug, mi immagino solo i guai che potrebbe combinare in campo finanziario... pensate ad un errore del 50% sul fatturato di una media azienda (poichè spero che nelle grandi aziende si usi altro) e traete le vostre conclusioni. Un conto è la calcolatrice che mi sbaglia un calcolo, un conto è un software spesso posizionato in situazioni critiche che produce un errore del genere. Pensate se Padoa-Schioppa si trovasse davanti a questo errore nel tentativo di valutare a grandi linee una possibile strada da seguire per la prossima finanziaria, a quel punto non so quanto potrebbe valere il discorso "tra una settimana abbiamo il nostro bugfix" oppure "trovami un software senza bug"... i processi di sviluppo per software critici esistono e funzionano e servono ad evitare situazioni come questa.

per fortuna i nostri ministeri usano oracle :D

per fortuna i nostri ministeri usano oracle :D

non so se è una fortuna :rolleyes:

leggete bene: è un problema di sola visualizzazione e si presenta solo con alcuni valori. Bug imbarazzante ma non così scandaloso, soprattutto se verrà risolto presto con uno dei comodissimi update automatici. Per chi sottolinea la questione costi... provate a comprare uno di quei famosi gestionali la cui licenza e costi di installazione raggiungono totali da un milione di euro e poi vedete se non trovate almeno un paio di bug più gravi di questo. RAgazzi... il software è "rotto"... io lo so bene perchè sono uno che produce bug, ehm... software

Microsoft == CIARLATANI
Si fanno pagare centinaia di euro per Office 2007 e fanno ste cappelle che non farebbe neanche il piu' scarso dei programmatori.
La figura e' ancora piu' da pezzenti perche' secondo PI di ieri (http://punto-informatico.it/p.aspx?i=2073462) questo bug risale a vecchie versioni Excel 95-97 quindi in casa Microloft oltre a non saper programmare fanno pure i copiaincolla di pezzi sbagliati di codice.
E io dovrei dare qualche soldo a gente del genere? Spero falliscano in fretta e viva l'opensource dove se c'e' qualche bug clamoroso, almeno non ho sborsato soldi e non mi sento preso per il culo.

i bug esistono a prescindere da quanto li paghi, esisteranno sempre e la MS non puo farci niente nemmeno investendo tutti i soldi del mondo.


Errato, esistono processi di sviluppo del software che servono ad evitare simili situazioni. In questo caso ci troviamo davanti ad un bug abbastanza classico: una funzione funziona perfettamente, ma in presenza di particolari input assume un comportamento errato. Buona norma in questi casi è ricordare le esperienze passate e questo bug non è nuovo, si era presentato anche in passato. 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.

non confondere la complessità con l'affidabilità. Oracle è molto complesso, ma se in mano a gente competente garantisce affidabilità e sopratutto integrità dei dati.

leggete bene: è un problema di sola visualizzazione e si presenta solo con alcuni valori. Bug imbarazzante ma non così scandaloso,

E grazie tante!! Pensa a una fattura il cui totale dovrebbe essere 65'535 euro che diventano magicamente 100'000 .. che figura di merda ci fai con il cliente?

Errato, esistono processi di sviluppo del software che servono ad evitare simili situazioni. In questo caso ci troviamo davanti ad un bug abbastanza classico: una funzione funziona perfettamente, ma in presenza di particolari input assume un comportamento errato. Buona norma in questi casi è ricordare le esperienze passate e questo bug non è nuovo, si era presentato anche in passato. 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.

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.

ahhhh che palle

va bene essere pedanti ma a tutto c'è un limite

allora... il baco si presenta solo in casi estremamente particolari, casi che NEL MONDO REALE non si presenteranno mai

tant'è che ho fatto la battuta della fattura con totale 65535 e oh, c'è gente (vedi sopra) che invece lo dice sul serio

d'altro canto tutti fanno fatture con il totale di 65535 euro ricavato non da delle somme come al solito ma proprio da una di quelle 6 moltiplicazioni astruse


PIEDI PER TERRA

come quelli che si preoccupano che caschi loro in testa un meteorite e poi quando sono in macchina sono tranquillissimi

ovviamente la possibilità che questo baco dia fastidio c'è, il punto è che di molti ordini di grandezza inferiore a quella che ci sia ad esempio un errore umano, piuttosto che altri tipi di errore


ora, la bug list di una qualsiasi CPU tipicamente è composta da centinaia di voci

vi stracciate le vesti per un errore estremamente specifico come questo (ovvero casi straordinari in un'applicazione specifica); dei bachi invece che sono a livello hardware cosa ne dite? vi uccidete?

un po' di obiettività (merce rara quando si parla di MS):
1) il baco è ininfluente
2) in ogni caso, se avesse causato un problema esistono i metodi per rivalersi
3) bello parlare alla cazzo dei processi di testing di MS sulla base di un baco: dei processi raffinati non ESCLUDONO la possibilità di un baco ma lo riducono...

poi è fantastico che pur di dare addosso date più importanza a una stronzata del genere completamente ininfluente piuttosto magari di un buffer overflow

ah, e del baco di OOO dove viene visualizzato il contenuto della cella precedente nessuno parla?


su, SIAMO REALISTI: NON CONTA NIENTE. fa tanta scena ma all'atto pratico non influirà mai.

di questi bachi sai quanti ce ne saranno in giro

Fatto qualche test su Excel 2007:

A1 = 77,1*850 => 100000
B1 = A1+1 => 100001
C1 = A1/2 => 32767,5
D1 = A1^2 => 4294836225
E1 = RADQ(A4) => 100000

3 pagine di discussione, Ms ne fa ballare di utenti ogni mattina. :asd:

ma come detto da molti non mi sembra uno scandalo...
è stato trovato un bug, il bug è stato ammesso la patch per il bug verrà rilasciata a breve.
a me pare il comportamento di una casa di sw seria cmq.
ovviamente hanno anche aggiunto che il bug è solo di visualizazione e non delle celle ergo il risultato è salvato in maniera corretta ma viene visualizzato in maniera errata.
quindi hanno semplicemente detto che se vedono il risultato anomalo in quel passaggio possono continuare a lavorare tranquilli xè il programma salva il valore corretto e non quello visualizzato.

Se provate a fare (CELL=65535) ritorna TRUE e quindi in questo caso è un errore solo di visualizzazione ma se fate (CELL+1) ritorna 100001 -> questo non è un errore di visualizzazione ma può "sputtanare" un intero foglio di calcolo :read:

Non è assolutamente solo un errore di visualizzazione

Ragazzi ma fosse solo questo il problema di Office 2007, ce ne sono gia' una sfilza.

Ma dove sono finiti quelli che dicono che Office e' una spanna sopra ad OpenOffice? In vacanza tutti? :asd:

Buona lettura
http://ooxmlisdefectivebydesign.blogspot.com/

Se profate a fare (CELL=65535) ritorna TRUE e quindi in questo caso è un errore solo di visualizzazione ma se fate (CELL+1) ritorna 100001 -> questo non è un errore di visualizzazione ma può "sputtanare" un intero foglio di calcolo :read:

Non è assolutamente solo un errore di visualizzazione

sono 6 le combinazioni che danno il problema, sarebbe da verificare se cell + 2 dà 100002 o 65537, nel primo caso non è solo un errore di visualizzazione, nel secondo si


Cimmo: eccomi qui, l'ho detto poco fa. al di là del fatto che OOO ha avuto bachi più gravi, è più limitato, praticamente inusabile se hai delle esigenze appena appena complesse. ripeto, prova solamente a linkare delle celle di fogli di altri file e vedrai che ti nasce spontanea la domanda:

perchè mi devo sbattere così quando con excel faccio tutto in 5 minuti?

Ragazzi ma fosse solo questo il problema di Office 2007, ce ne sono gia' una sfilza.

Ma dove sono finiti quelli che dicono che Office e' una spanna sopra ad OpenOffice? In vacanza tutti? :asd:

Buona lettura
http://ooxmlisdefectivebydesign.blogspot.com/

vogliamo parlare della pena che fanno i filtri in OOo? ed uso solo quello perchè mi costa troppo Office.

:asd:

questo topic è spettacolare... :blah:

ahhhh che palle
va bene essere pedanti ma a tutto c'è un limite
allora... il baco si presenta solo in casi estremamente particolari, casi che NEL MONDO REALE non si presenteranno mai
tant'è che ho fatto la battuta della fattura con totale 65535 e oh, c'è gente (vedi sopra) che invece lo dice sul serio
Io l'ho detto sul serio. Problemi? E non avevo letto il tuo post precedente al mio. Il mio primo pensiero e' stato quello. Probabilmente per te i soldi non hanno valore.

d'altro canto tutti fanno fatture con il totale di 65535 euro ricavato non da delle somme come al solito ma proprio da una di quelle 6 moltiplicazioni astruse
Non si tratta solo di fatture. Operazioni bancarie, calcolo di interessi, dichiarazione dei redditi. Magari ci capita una delle operazioni incriminate (e chi ti dice che sono solo quelle?) .. c'e' differenza tra pagare 65535 euro di tasse e 100000.


su, SIAMO REALISTI: NON CONTA NIENTE. fa tanta scena ma all'atto pratico non influirà mai.
di questi bachi sai quanti ce ne saranno in giro

Bravo continua cosi' .. finche' ci sara' qualcuno che di fronte a qualsiasi bug dice "non conta niente", microsozz continuera' a realizizzare software pieni di bug e a farsi pagare .. evidentemente a molti piace farsi prendere per il culo. A me no.

Io l'ho detto sul serio. Problemi? E non avevo letto il tuo post precedente al mio. Il mio primo pensiero e' stato quello. Probabilmente per te i soldi non hanno valore.


Non si tratta solo di fatture. Operazioni bancarie, calcolo di interessi, dichiarazione dei redditi. Magari ci capita una delle operazioni incriminate (e chi ti dice che sono solo quelle?) .. c'e' differenza tra pagare 65535 euro di tasse e 100000.



Bravo continua cosi' .. finche' ci sara' qualcuno che di fronte a qualsiasi bug dice "non conta niente", microsozz continuera' a realizizzare software pieni di bug e a farsi pagare .. evidentemente a molti piace farsi prendere per il culo. A me no.

allora spegni il PC, perchè software bug-free è solo nei PC spenti.

Questo thread e' fenomenale!
E' pieno di gente che ha sborsato centinaia di euro per Office, gli brucia perche' le stesse cose le avrebbero potute fare con OpenOffice e stanno a difendere Microsoft di fronte a qualsiasi bug pur di non ammettere che si son presi una enorme fregatura.

Questo thread e' fenomenale!
E' pieno di gente che ha sborsato centinaia di euro per Office, gli brucia perche' le stesse cose le avrebbero potute fare con OpenOffice e stanno a difendere Microsoft di fronte a qualsiasi bug pur di non ammettere che si son presi una enorme fregatura.

Ancora con OOo?

allora spegni il PC, perchè software bug-free è solo nei PC spenti.

Eccolo!! Grazie, lo sapevo gia' .. pero' se il software lo pago mi piacerebbe che sia testato a dovere e magari che non si porti dietro bug scoperti parecchi anni fa ..

Eccolo!! Grazie, lo sapevo gia' .. pero' se il software lo pago mi piacerebbe che sia testato a dovere e magari che non si porti dietro bug scoperti parecchi anni fa ..

cosa che accade sia che il SW lo paghi sia che si tratti di Open. Ma hai idea cosa voglia dire fare il test di SW che deve affrontare un possiblità di interazioni con l'utente praticamente infinite?

sono 6 le combinazioni che danno il problema, sarebbe da verificare se cell + 2 dà 100002 o 65537, nel primo caso non è solo un errore di visualizzazione, nel secondo si


Cimmo: eccomi qui, l'ho detto poco fa. al di là del fatto che OOO ha avuto bachi più gravi, è più limitato, praticamente inusabile se hai delle esigenze appena appena complesse. ripeto, prova solamente a linkare delle celle di fogli di altri file e vedrai che ti nasce spontanea la domanda:

perchè mi devo sbattere così quando con excel faccio tutto in 5 minuti?

Non ho capito.

(CELL+1) da come risultato 100001 che è un errore di calcolo. (cell+2 non so se sbaglia ma credo di no, resta il fatto che che è presente un errore di calcolo)

C'è scritto sul blog degli sviluppatori di Excel che in rari casi (come il CELL+1) è presente un errore di calcolo; la cosa è ufficiale.

Sul fatto che Excel sia 1000 volte meglio di Calc siamo daccordo (qualsiasi persona che usa seriamente i fogli di calcolo si è "impantanato" almeno una volta con le enormi mancanze di Calc)
Resta il fatto che questo è un bug molto grave.

io non uso ms office. Però leggendo in giro qualcuno mi spiega perchè:

se è vero che (CELL=65535) ritorna TRUE, è anche vero che CELL+1) ritorna 100001.

Cioè se il valore memorizzato in memoria è quello giusto perchè continua a farli male i calcoli?

Mi piacerebbe sapere, non sono ironico. Excel non l'ho mai toccato perchè non mi è mai servito, magari c'è una spiegazione anche a questo! :)

abbiamo scritto insieme eheheheheeh ! :)

cosa che accade sia che il SW lo paghi sia che si tratti di Open. Ma hai idea cosa voglia dire fare il test di SW che deve affrontare un possiblità di interazioni con l'utente praticamente infinite?

Esistono software per analizzare la correttezza del codice e qui si tratta di un bug veramente grossolano. Solito problema di una variabile a 16 o 32 bit .. problema che esisteva anche 30 anni fa e una delle prime cose che si imparano dopo aver scritto "hello world".
Il bug era gia' stato segnalato 2 anni fa su excel 95-97 .. puoi anche smetterla di arrampicarti sugli specchi, da microsfot programmano coi piedi e col copiaincolla e si fanno pure pagare .. tu continua a far parte del gregge e farti prendere per il c... da loro, io no.

allucinante...se quel risultato è stato usato come valore economico di qualcosa sono cazzi......

cosa che accade sia che il SW lo paghi sia che si tratti di Open. Ma hai idea cosa voglia dire fare il test di SW che deve affrontare un possiblità di interazioni con l'utente praticamente infinite?

ma non eri tu che nel thread di firefox dove avevano beccato un bug molto simile ad uno risolto tempo addietro eri li' ad additarlo?

Se mi ricordo bene dovresti avere coerenza.
I bug che ritornano sono scandalosi per tutti, sia per l'open che per il closed, per il gratis e x il pagamento.

Se era un bug noto giustamente andava fatto un test case, ce ne sono automatici o manuali e quelli manuali ovviamente li dai in pasto ai betatester.

Serieta'! Cosi' come dissi che era grave per Firefox dico che e' grave qui.

Esistono software per analizzare la correttezza del codice e qui si tratta di un bug veramente grossolano. Solito problema di una variabile a 16 o 32 bit .. problema che esisteva anche 30 anni fa e una delle prime cose che si imparano dopo aver scritto "hello world".
Il bug era gia' stato segnalato 2 anni fa su excel 95-97 .. puoi anche smetterla di arrampicarti sugli specchi, da microsfot programmano coi piedi e col copiaincolla e si fanno pure pagare .. tu continua a far parte del gregge e farti prendere per il c... da loro, io no.

lasciando perdere l'educazione, cosa posti in una discussione se non usi tali SW?

cosa posti in una discussione se non usi tali SW?

scusa ma mi sento chiamato in causa anche io... io non ho mai usato excel come non ho mai toccato software simili semplicemente perchè non mi servono... on ho mai toccato nemmeno openoffice calc.
Però che significa scusa? non posso informarmi a riguardo lo stesso? :confused:

ma non eri tu che nel thread di firefox dove avevano beccato un bug molto simile ad uno risolto tempo addietro eri li' ad additarlo?

Se mi ricordo bene dovresti avere coerenza.
I bug che ritornano sono scandalosi per tutti, sia per l'open che per il closed, per il gratis e x il pagamento.

Se era un bug noto giustamente andava fatto un test case, ce ne sono automatici o manuali e quelli manuali ovviamente li dai in pasto ai betatester.

Serieta'! Cosi' come dissi che era grave per Firefox dico che e' grave qui.

Questa cosa di FF non la ricordo, a meno che non ti riferisci all'uso abnorme di Ram. In ogni caso la cosa strana è che questo BUG non si presenta in Excel XP e 2003. Per il fatto che i bug che ritornano siano scandalosi, sono d'accordo, sia che si tratti di Open che di Closed.

lasciando perdere l'educazione, cosa posti in una discussione se non usi tali SW?

ma io non capisco questa ghettizzazione che ogni tanto questa gente usa.
"Se non usi questo software perche' sei qui a criticarlo?" Perche' e' vietato dalla legge italiana? Ma per favore, il rispetto per le persone dove l'avete messo?

Se venite a criticare Linux in un thread di Linux in modo costruttivo e coerente siete i benvenuti ma che scherziamo?

:eek: :eek: :eek: è assurdo..ma hanno fatto l aggiornamento almeno?:muro: :muro: :muro:

scusa ma mi sento chiamato in causa anche io... io non ho mai usato excel come non ho mai toccato software simili semplicemente perchè non mi servono... on ho mai toccato nemmeno openoffice calc.
Però che significa scusa? non posso informarmi a riguardo lo stesso? :confused:

informarsi è bene, venire a sparlare in tutte le discussione Ms come fa lui, usando quei toni, supponendo una superiorità che nessuno gli ha riconosciuto... beh direi di no.

ma io non capisco questa ghettizzazione che ogni tanto questa gente usa.
"Se non usi questo software perche' sei qui a criticarlo?" Perche' e' vietato dalla legge italiana? Ma per favore, il rispetto per le persone dove l'avete messo?

Se venite a criticare Linux in un thread di Linux in modo costruttivo e coerente siete i benvenuti ma che scherziamo?

ho già risposto più sotto...

Questa cosa di FF non la ricordo, a meno che non ti riferisci all'uso abnorme di Ram. In ogni caso la cosa strana è che questo BUG non si presenta in Excel XP e 2003. Per il fatto che i bug che ritornano siano scandalosi, sono d'accordo, sia che si tratti di Open che di Closed.

si ho ricordato male, ho ritrovato il thread e non eri tu.

Per chi avesse voglia di rileggere l'articolo e' questo, occhio che come al solito hwup non va' molto in profondita' e in realta' quel bug e' nato dopo una patch ad un altro bug, ma non e' assolutamente detto che il bug fosse identico a quello di tanto tempo fa, solo aveva gli stessi effetti.

http://www.hwupgrade.it/news/software/firefox-rispunta-una-falla-di-7-anni-fa_14767-0.html

si ho ricordato male, ho ritrovato il thread e non eri tu.

Per chi avesse voglia di rileggere l'articolo e' questo, occhio che come al solito hwup non va' molto in profondita' e in realta' quel bug e' nato dopo una patch ad un altro bug, ma non e' assolutamente detto che il bug fosse identico a quello di tanto tempo fa, solo aveva gli stessi effetti.

http://www.hwupgrade.it/news/software/firefox-rispunta-una-falla-di-7-anni-fa_14767-0.html

:mano:

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

excel 2002 esente dal bug (appena provato)

si sono esenti tutti tranne il 2007 da quello che leggo in giro ;)

si sono esenti tutti tranne il 2007 da quello che leggo in giro ;)

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

Per piacere, facciamo restare bassi i toni. ;)

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

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

:mano:

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.

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.aspx?scid=kb;en-us;Q161234

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!

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

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! ;)

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

=77,1*850

risultato 65535

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.

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.


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.

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) :mbe:

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) :mbe:
Quoto. Sono due bug diversi, com'è attestato qui: http://blogs.msdn.com/excel/archive/2007/09/25/calculation-issue-update.aspx e qui http://support.microsoft.com/default.aspx?scid=kb;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.

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

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

@ FX (il primo post)

LOL asd

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.

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

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... :mbe:

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

Che bello che fa if 0 then stesso valore?

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.

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 :mbe:
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.

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 ... :rolleyes: :rolleyes:

notai un bug in office 2000

1 2 3
4 5 6
7 8 9

=matr.determinante(a1:c3) ;)

è ancora presente?

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



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 ... :rolleyes: :rolleyes:
Peccato che la situazione del razzo Arianne sia BEN DIVERSA da quella del bug di Excel 2007: non si è certo trattato di un caso "che non si verifica mai", e che quindi è stato APPOSITAMENTE messo da parte.

Il problema, come è stato già detto, è relativo al fatto che l'uso di numeri in virgola mobile in formato IEEE 754 comporta DI PER SE' una perdita di precisione. Quindi alcune numeri NON si possono rappresentare.
Nel link che è stato postato poco fa, è spiegato in maniera esauriente questo tipo di problematica, e il fatto che esiste un'apposita routine che cerca di rappresentare questi numeri nella maniera migliore possibile, quindi applicando arrotondamenti et similia volti ad evitare che roba come 0.1 venga rappresentata invece come una sfilza di 0.10000000000001754.

Checché tu ne dica, c'è ben poco di informatica teorica, ma si tratta di molta pratica invece.

Quanto all'informatica teorica di per sé mi permette di affermare senza ombra di dubbio che ciò che hai ripotato in precedenza riguardo all'analisi della correttezza del software è una chimera informatica, visto che non sta né in cielo né in terra.

Adesso vediamo se quest'inutile polemica deve continuare o il buon senso permetterà di darci un taglio definitivo.

arrangiati te , io per quello che costa non tollero di arrangiarmi!

Bhe è un bug difficilissimo da scovare...

cosa dovevano fare provare tutte le operazioni del mondo?

Chiunque abbia imparato le basi minime dell'ingegnerizzazione del sotware, in particolare il testing (cosa che a questo punto non darei per scontata per i dipendenti MS, se la situazione è questa!) sa BENISSIMO che una delle condizioni da verificare in fase di black box testing è appunto quella dei valori limite...cosa che non è stata fatta.

Peccato che la situazione del razzo Arianne sia BEN DIVERSA da quella del bug di Excel 2007: non si è certo trattato di un caso "che non si verifica mai", e che quindi è stato APPOSITAMENTE messo da parte.
A me invece sembra simile .. quando c'e' il proprio interesse in ballo fa comodo dire "non si verifichera' mai" sperando che non succeda nulla.

Il problema, come è stato già detto, è relativo al fatto che l'uso di numeri in virgola mobile in formato IEEE 754 comporta DI PER SE' una perdita di precisione. Quindi alcune numeri NON si possono rappresentare.
Nel link che è stato postato poco fa, è spiegato in maniera esauriente questo tipo di problematica, e il fatto che esiste un'apposita routine che cerca di rappresentare questi numeri nella maniera migliore possibile, quindi applicando arrotondamenti et similia volti ad evitare che roba come 0.1 venga rappresentata invece come una sfilza di 0.10000000000001754.
Non serve tirar fuori standard IEEE ISO etc etc per spiegare il problema della rappresentazione binaria dei numeri in base dieci con la virgola!
Alla prima settimana di ing informatica ti spiegano che il numero decimale 0.1 viene convertito in un numero periodico binario:

0.1 decimale = 0.000110011001100110011.... binario

e quindi negli elaboratori e' tutto un discorso di approssimazioni pero' approssimare 65'535 a 100'000 mi sembra un po' esagerato :D:D

Chiunque abbia imparato le basi minime dell'ingegnerizzazione del sotware, in particolare il testing (cosa che a questo punto non darei per scontata per i dipendenti MS, se la situazione è questa!) sa BENISSIMO che una delle condizioni da verificare in fase di black box testing è appunto quella dei valori limite...cosa che non è stata fatta.

Quoto.
Tantopiu' dato che Excel non era nuovo a problemi sulla rappresentazione dei numeri, avrebbero dovuto fare dei test piu' approfonditi sui valori limite.

Chiunque abbia imparato le basi minime dell'ingegnerizzazione del sotware, in particolare il testing (cosa che a questo punto non darei per scontata per i dipendenti MS, se la situazione è questa!) sa BENISSIMO che una delle condizioni da verificare in fase di black box testing è appunto quella dei valori limite...cosa che non è stata fatta.
Prova a farla tu con l'ENORME range rappresentabile da un numero in formato IEEE 754 a doppia precisione...

A me invece sembra simile .. quando c'e' il proprio interesse in ballo fa comodo dire "non si verifichera' mai" sperando che non succeda nulla.
Se ti sembra simile non hai che da dimostrarlo allora. ;)
Non serve tirar fuori standard IEEE ISO etc etc per spiegare il problema della rappresentazione binaria dei numeri in base dieci con la virgola!
Alla prima settimana di ing informatica ti spiegano che il numero decimale 0.1 viene convertito in un numero periodico binario:

0.1 decimale = 0.000110011001100110011.... binario

e quindi negli elaboratori e' tutto un discorso di approssimazioni pero' approssimare 65'535 a 100'000 mi sembra un po' esagerato :D:D
Lo è anche per me, ma non so che tipo di algoritmi abbiano usato per cercare di far fronte ai problemi di rappresentazione.

Come dicevo prima, un conto è che l'utente veda 0.1 e tutt'altra cosa è 0.10000000000001754: eppure è quest'ultimo il dato giusto. Il primo caso è, invece, ottenuto falsando opportunamente il dato reale, e questo può generare a sua volta altri problemi, come quello che è capitato questa volta.

Quoto.
Tantopiu' dato che Excel non era nuovo a problemi sulla rappresentazione dei numeri, avrebbero dovuto fare dei test piu' approfonditi sui valori limite.
Non si possono fare: il range è troppo grande.

Se ti sembra simile non hai che da dimostrarlo allora. ;)

Non giriamo la frittata per favore. Dai tuoi post precedenti sembra tu sia tra coloro che sostengono che questo bug non inficiera' mai sulle operazioni e sui risultati di coloro che usano Excel 2007.
Spetta a chi sostiene questa ipotesi DIMOSTRARE che tra le decine di milioni di utilizzatori di Excel 2007 nessuno di questi otterra' mai un risultato sbagliato a causa di questo bug.

Non giriamo la frittata per favore.
Non l'ho mai fatto e non inizierò certo adesso: mi sono sempre attenuto a quello che era stato scritto.
Dai tuoi post precedenti sembra tu sia tra coloro che sostengono che questo bug non inficiera' mai sulle operazioni e sui risultati di coloro che usano Excel 2007.
Adesso quotami e fammi vedere in base a cosa sei arrivato a queste conclusioni che sicuramente non mi appartengono.
Spetta a chi sostiene questa ipotesi DIMOSTRARE che tra le decine di milioni di utilizzatori di Excel 2007 nessuno di questi otterra' mai un risultato sbagliato a causa di questo bug.
Non l'ho detto e non è cosa mia. Io ho detto ben altro.

Spetta, invece, a te dimostrare le similitudini fra il bug del razzo Arianne e quello di Excel 2007: te l'avevo chiesto, ma "stranamente" hai preferito cambiare del tutto argomento. Poi sarei io a rigirare le frittate, vero? :rolleyes:

Chiunque abbia imparato le basi minime dell'ingegnerizzazione del sotware, in particolare il testing (cosa che a questo punto non darei per scontata per i dipendenti MS, se la situazione è questa!) sa BENISSIMO che una delle condizioni da verificare in fase di black box testing è appunto quella dei valori limite...cosa che non è stata fatta.

Questo è un commento competente. :read:

65535 e 65536 sono due dei numeri nella "Top ten" dei valori da testare.
Un errore del genere indica che non è stato fatto alcun test sui valori limite. (non mi spiego come sia possibile:confused: )
Evidentemente non sono stati testati questi valori in input al layer di visualizzazione di Excel e la cosa è obbietivamente un grossolano errore.

OT. conosco personalmente l'uomo che ha fatto cascare l'A5 (lo hanno licenziato e adesso insegna in una università italiana..........non dico altro altrimenti mi ammazza :fiufiu: )

Questo è un commento competente. :read:

65535 e 65536 sono due dei numeri nella "Top ten" dei valori da testare.
E perché? Sono numeri come altri. Ricordiamoci che la rappresentazione è quella IEEE 754 a doppia precisione, non l'intero a 16 bit.
Un errore del genere indica che non è stato fatto alcun test sui valori limite. (non mi spiego come sia possibile:confused: )
Semplice: esiste un'enormità di valori limite, e testarli tutti esaustivamente rasenterebbe la follia.
Evidentemente non sono stati testati questi valori in input al layer di visualizzazione di Excel e la cosa è obbietivamente un grossolano errore.
L'errore è grossolano quanto al risultato, non certamente in ottica di test. Vedi sopra.
OT. conosco personalmente l'uomo che ha fatto cascare l'A5 (lo hanno licenziato e adesso insegna in una università italiana..........non dico altro altrimenti mi ammazza :fiufiu: )
Che ci sarebbe di male? Mica può risalire a te dal nickname. :fiufiu:

Adesso quotami e fammi vedere in base a cosa sei arrivato a queste conclusioni che sicuramente non mi appartengono.

Non l'ho detto e non è cosa mia. Io ho detto ben altro.

Hai detto che il bug si presenta con "12 precisi valori" e che "quella che è stata montata (ad arte, perché il titolo della news è tutto un programma) è una polemica del tutto inutile e faziosa. Come al solito." .. da queste affermazioni sembra tu voglia minimizzare il problema. Se non e' cosi' avro' interprenetrato male ..

Spetta, invece, a te dimostrare le similitudini fra il bug del razzo Arianne e quello di Excel 2007: te l'avevo chiesto, ma "stranamente" hai preferito cambiare del tutto argomento. Poi sarei io a rigirare le frittate, vero? :rolleyes:

No no non cambio argomento. Sull'Arianne era un problema di cast con numero magico 32'768, qui e' un problema su un altro numero magico 65'535 .. come detto da molti, i primi test da fare sono proprio attorno ai "numeri magici" e in entrambi i casi (Arianne e Excel 2007) non sono stati fatti dei test appropriati attorno a questi numeri. La similitudine che vedo in entrambi i casi e' la mancanza dei test fondamentali attorno ai numeri magici cosa che farebbe anche il piu' niubbo dei programmatori .. ti piace la mia dimostrazione?

Hai detto che il bug si presenta con "12 precisi valori" e che "quella che è stata montata (ad arte, perché il titolo della news è tutto un programma) è una polemica del tutto inutile e faziosa. Come al solito." .. da queste affermazioni sembra tu voglia minimizzare il problema.
Infatti il problema va minimizzato, ma NON trascurato. Tant'è che arriverà, appunto, una patch quanto prima.
Se non e' cosi' avro' interprenetrato male ..
Decisamente, visto che ti sei permesso di scrivere questo:

"Dai tuoi post precedenti sembra tu sia tra coloro che sostengono che questo bug non inficiera' mai sulle operazioni e sui risultati di coloro che usano Excel 2007"

sul mio conto.

Visto che non è la prima volta che capita, la prossima volta sei pregato di riportare il mio quote prima di fare certe affermazioni che mi riguardano.
No no non cambio argomento.
Mancava la tua risposta però.
Sull'Arianne era un problema di cast con numero magico 32'768, qui e' un problema su un altro numero magico 65'535 ..
Nel secondo caso non si tratta di un numero magico, visto che non è l'ULTIMO numero rappresentabile, come invece lo era con l'Arianne.
come detto da molti, i primi test da fare sono proprio attorno ai "numeri magici" e in entrambi i casi (Arianne e Excel 2007) non sono stati fatti dei test appropriati attorno a questi numeri.
La natura dei due problemi è completamente diversa, come ho già detto sopra, e nel secondo caso non sono applicabili test soltanto su alcuni numeretti (magici): non avrebbe senso, visto che il problema dell'approssimazione riguarda indifferentemente qualunque numero intero (e non) rappresentabile.
La similitudine che vedo in entrambi i casi e' la mancanza dei test fondamentali attorno ai numeri magici cosa che farebbe anche il piu' niubbo dei programmatori ..
Solo se il problema lo richiede: i test non s'inventano mica soltanto perché esistono dei "numeri magici".
ti piace la mia dimostrazione?
No, perché non hai dimostrato niente. Nel caso dell'Arianne, e te lo ripeto, il problema era dovuto al fatto che il numero in FP veniva convertito in un intero a 16 bit dotato di segno, per cui esistevano degli OGGETTIVI limiti da considerare.

Nel caso di Excel 2007 non c'è nessuna conversione da FP a intero, ma da FP a STRINGA, e in questo caso non c'è alcuna limitazione al range di numeri rappresentabile che non sia quella del dato di input, ossia del valore in FP, che qualunque programmatore niubbo sa bene essere afflitto dall'impossibilità di poter rappresentare qualunque numero razionale (e non tiro in ballo gli irrazionali per ovvie ragioni: la situazione è ben peggiore).

E' chiaro adesso del perché sono due problemi completamente diversi? Speriamo sia la volta buona...

Infatti il problema va minimizzato, ma NON trascurato. Tant'è che arriverà, appunto, una patch quanto prima.

Decisamente, visto che ti sei permesso di scrivere questo:

"Dai tuoi post precedenti sembra tu sia tra coloro che sostengono che questo bug non inficiera' mai sulle operazioni e sui risultati di coloro che usano Excel 2007"

sul mio conto.
In quello che ho scritto c'e' la parola magica "sembra".

Visto che non è la prima volta che capita, la prossima volta sei pregato di riportare il mio quote prima di fare certe affermazioni che mi riguardano.
Come sei fiscale!

Mancava la tua risposta però.

Nel secondo caso non si tratta di un numero magico, visto che non è l'ULTIMO numero rappresentabile, come invece lo era con l'Arianne.
Dopo questa ho segato il resto del "quote" e chiudo completamente perche' non ci siamo proprio con la rappresentazione binaria
Arianne: short int -32768 .. +32767
Excel 2007: unsigned short int 0 .. 65535 .. e mi dici che non e' l'ultimo numero rappresentabile?? e non e' un numero magico? magari non in floating point ma se il layer di visualizzazione per qualche motivo usa tipo di dato ecco che 65535 diventa un numero magico

2 elevato alla 16 meno 1 = 65535
dai basta aver studiato qualcosa di programmazione e di numeri in base 2 per sapere che è un numero particolare (il più grande valore positivo rappresentabile a 16 bit) .... e poichè è un numero limite andava testato.
Non ci sono scuse per la microsoft per un non test del genere.

In quello che ho scritto c'e' la parola magica "sembra".

Come sei fiscale!
Deformazione professionale.
Dopo questa ho segato il resto del "quote" e chiudo completamente perche' non ci siamo proprio con la rappresentazione binaria
Il resto del quote spiegava ESATTAMENTE la differenza fra il problema riscontrato con l'Arianne e quello con Excel 2007.

Arianne: short int -32768 .. +32767
OK
Excel 2007: unsigned short int 0 .. 65535 .. e mi dici che non e' l'ultimo numero rappresentabile??
No: prova a mettere 65536 nella cella. Lo vedi o te l'ha troncato?
e non e' un numero magico?
E' un numero come un altro, visto che stiamo parlando di valori in VIRGOLA MOBILE.
magari non in floating point
Esattamente, ed è QUESTO il nocciolo del problema.
ma se il layer di visualizzazione per qualche motivo usa tipo di dato ecco che 65535 diventa un numero magico
Che tipo di dato dovrebbe usare? Spiegati meglio?

Anzi, facciamo una cosa: spiegami tu come faresti a convertire un valore da virgola mobile IEEE 754 a doppia precisione in stringa, e mostrami per quale motivo è importate testare il codice su questi "numeri magici" di cui parli.

Non è solo un bug di visualizzazione. Se provate a sottrarre o aggiungere 1 al valore noterete che non è in grado nemmeno di visualizzare le due cifre corrette (65534 e 65536) ma darà come risultato sempre 100000 in caso di sottrazione e 100001 in caso di addizione.

ora si spiega la crisi dei mutui americani

2 elevato alla 16 meno 1 = 65535
Bene.
dai basta aver studiato qualcosa di programmazione e di numeri in base 2 per sapere che è un numero particolare (il più grande valore positivo rappresentabile a 16 bit) ....
Bene.
e poichè è un numero limite andava testato.
Male, anzi malissimo: ti sei perso il mio messaggio in cui descrivevo il problema.
Non ci sono scuse per la microsoft per un non test del genere.
Adesso ci dimostri per quale motivo andava testato questo numeretto, e per quale motivo sarebbe "limite" rispetto all'operazione di conversione di un numero da virgola mobile IEEE 754 a doppia precisione in stringa.

P.S. Ringrazia che non sono un tuo docente perché non ti saresti mai laureato. :asd:

Non è solo un bug di visualizzazione. Se provate a sottrarre o aggiungere 1 al valore noterete che non è in grado nemmeno di visualizzare le due cifre corrette (65534 e 65536) ma darà come risultato sempre 100000 in caso di sottrazione e 100001 in caso di addizione.
E' spiegato nel link che era stato postato, da un ex dipendente MS.

Messaggio cancellato:

Vedere messaggio successivo

un bug difficile da trovare?
Abbastanza. Vedi documento di spiegazione annesso.
un sistema anche se costa tanto dovrebbe essere esente da bug di programmazione?
Nessun software ha la certezza di essere esente da bug.
ma scherziamo? per 800 euro di programma a copia dovrebbero fare 3/4...se non più betatest.....
Lo fanno già, ma non è possibile azzerare il numero di bug.
chi lavora a lungo con excel...il bug lo scopre eccome....
Infatti s'è visto proprio. Per curiosità, quand'è che è stato rilasciato Office 2007?
cioè...non è un bug su una funzione di chissa quale complessità...è un bug sulla funzione moltiplicazione che si fa con il segno * .... la più idiota delle operazioni matematiche...
Infatti non riguarda la moltiplicazione: si vede che hai letto soltanto il titolo della notizia (del tutto fuorviante) e la news, senza verificare né sul sito in cui se ne parla e neppure hai letto gli altri messaggi del thread.
roba da matti.....sono un demente che gli do anche i soldi per sfornare prodotti che vengono ultrapubblicizzati e nel giro di 1 anno escono bug di tutti i tipi....dai più complessi....ai più idioti....(vedi questo)
Fai una cosa: NON usare software. Tanto non potrai avere la certezza che sia esente da bug.
PS.... ho visto risposte di persone qualificate in materia e laureate in matematica/ingegneria (presumo) ... tutto il rispetto e l'approvazione per i loro ragionamenti, ma quando uno spende quasi 1000 euro e vengono alla luce cose simili...veramente, c'è da piangere.
C'è da piangere nel leggere commenti come il tuo che dimostrano che non hai la benché minima idea del problema né tanto meno di cosa significhi sviluppare software.

Un commento inutile, insomma, come il titolo della notizia.

Adesso mi prendo una bella pausa. Vediamo chi avrà il coraggio di continuare a raccontare frottole dopo tutto quello che è stato scritto sul tema.

ah mi spiace....cancello il messaggio precedente...caro "collega" [Edit: umh....no facciamo professioni diverse e abbiamo lauree diverse] non pensavo che fossi capace di un messaggio di contenuti così bassi e offensivi.

forse facevi meglio a leggere integralmente il mio PS, dove scrissi che mi lamentavo del fatto che quando uno spende 800 euro e vede sorgere bug e cose varie cadono le pa***.

Non ho editato tutto il messaggio e ho preferito aggiungere un PS, dopo che ho letto le tue risposte precedenti.

2 cose...

1. c'è gente che ha appena tempo di leggere 3/4 news e di dare qualche commento/opinione personale e basta
2. si chiamano commenti perchè uno da la propria opinione personale, e non sta a te decidere se il mio parere è giusto o sbagliato, proprio perchè al massimo puoi condividere o non condividere, anche perchè nessuno è tenuto a leggersi 5 pagine di commenti dove ci sono tecnicismi che magari non sono alla portata di tutti.

3za cosa...anche se non era previsto e solo un piccolo consiglio:

Impara a rispettare le persone, perchè dal tuo tono di superiorità divina emerge che sei un maleducato di prima cartella...e dalle mie parti si dice cafone...o villano.

Detto ciò, chiedo scusa per l'OT e per il messaggio precedente eliminato, ma del resto questo non è un forum...solo chi ha 1000000000000 messaggi può parlare e dire la sua.

Arrivederci

PS...io ho letto solo la notizia riportata qui su HWU...inizialmente....sempre citando il fattore tempo.

PPS: il bug esiste da un anno....office mi sembra sia uscito a ottobre 2006...ma sbaglio di sicuro....e cosa di cui sono sicuro è che su 10 utenti che vedono un bug, solo 8 ne segnalano la presenza.

PPPS: ripeto dunque...io non ho tentato di dare una spiegazione alla notizia....io ho commentato la notizia, non i commenti e i contenuti di supplemento alla notizia....e dico ciò solo per risaltare le tue offese che non mi spiego, ma vedo solo io....sarà il cuore che non funziona bene...meglio che stacco sennò mi prende un infarto.... e io che ho anche scritto che provavo rispetto per i tuoi ultimi commenti... è vero essere educati porta solo a essere insultato

E perché? Sono numeri come altri. Ricordiamoci che la rappresentazione è quella IEEE 754 a doppia precisione, non l'intero a 16 bit.

Semplice: esiste un'enormità di valori limite, e testarli tutti esaustivamente rasenterebbe la follia.

L'errore è grossolano quanto al risultato, non certamente in ottica di test. Vedi sopra.

Che ci sarebbe di male? Mica può risalire a te dal nickname. :fiufiu:

L'errore non è nel "motore di calcolo" di Excel ma nel layer di visualizzazione, dato che questro strato SW non lavora su numeri in virgola mobile (li riceve solo in input, poi li "casta") ma esclusimente su interi (stringhe di caratteri)........almeno spero, i 65535/6 non sono più numeri come gli altri ;)
Non ho mai detto che il bug sia facilissimo da trovare, dato che non basta testare dei numeri particolari ma per ognuno di essi bisogna testare i vari modi in cui sono stati generati (solo i casi limite ;) mica tutti ) e questo per ogni tipo di dato (saremo nell'ordine dei milioni di combinazioni solo per il 65535 ;) )
Resta il fatto che era un bug "trovabile" (duro da trovare ma si poteva fare tranquillamente visto i potenti mezzi a disposizione dalla "piccola" Microsoft)

IMHO questo bug è dovuto ad un banalissimo (ma stronzissimo) errore di cast. (un classico :) )

Saluto perchè questo ormai è un flame assurdo. Ciao.

Mi da, ogni giorno, un motivo nuovo per non usare i suoi prodotti. :)
Che una cosa del genere possa succedere su un software che si paga a peso d'oro mi sembra abbastanza vergognosa.Il software è scritto da esseri umani che possono commettere errori.

Errori commessi a vari livelli:

- specifiche di sistema

- specifiche di prodotto

- errata interpretazione delle specifiche degli standard utilizzati

- a livello di implementazione

- errori negli strumenti Sw/Hw(compilatore, debbuger, simulatore, ecc) utilizzati

- errori di comunicazione7interpretazione tra i componenti dei vari team di progetto e sviluppo del prodotto

Tutto ciò ed altro ancora indipendentemente dal costo del prodotto finale.

Errori che non di rado si ripercuotono sul prodotto finale e che sono di non facile individuazione.

Sovente i novizi dei corsi di informatica apprendono rapidamente quello che potrebbe definirsi l'Assioma N° uno:
il Sw, per sua natura, non è esente da Bugs(bachi)

Quindi da qui all'eternità tu non dovresti usare NESSUN "software".

Il mio intervento non vuole essere polemico, ma cercare, forse invano, di far capire(a i non addetti ai lavori) a molti utenti che il bug nel Sw "rappresenta quasi una normalità"(più di qualche utente dopo questa affermazione sarà soggetto a conati di vomito), non è il caso di gridare allo scandalo.

L'importante è che si realizzi un "fix" efficace e in tempi ragionevoli.

Ossia che il prodotto abbia un buon servizio di assistenza post vendita.

Io ci vedo tutti i casi di crack dai bond argentini alla parmalat.. d'altronde programmi su excel molte volte vengono usati dagli uffici decisionali di grandi aziende,
anche statali.. ma la finanziaria come la fanno?
:read: :ciapet:

Adesso ci dimostri per quale motivo andava testato questo numeretto, e per quale motivo sarebbe "limite" rispetto all'operazione di conversione di un numero da virgola mobile IEEE 754 a doppia precisione in stringa.


perchè visto che in certe rappresentazioni è un valore limite per scrupolo un programmatore lo deve provare ed un programmatore deve essere sempre puntiglioso (che poi il sw esente da errori non esiste è un altro discorso) .
Che poi in altre rappresentazioni non sia un valore limite non ha importanza visto il numero di righe di codice che contiene excel.
Per esempio mettiti dalla parte del tester: chi gli dice che magari non ci sia un casting ad int a 16 bit che può dar problemi? Sapendo che era un numero potenzialmente a rischio di errori lo avrebbe dovuto provare -> e avrebbe trovato l'errore: questo non è stato fatto.
Delle cause vere dell'errore se ne sarebbe occupato solo dopo averlo trovato (e sinceramente non mi interessano nemmeno, visto che la programmazione non è il mio campo)

P.S. Ringrazia che non sono un tuo docente perché non ti saresti mai laureato.

.... e sono uscito pure con un voto alto!
bè vorrà dire che alla sapienza di roma non sanno insegnare allora :Prrr:

perchè visto che in certe rappresentazioni è un valore limite per scrupolo un programmatore lo deve provare ed un programmatore deve essere sempre puntiglioso.
Che poi in altre rappresentazioni non sia un valore limite non ha importanza visto il numero di righe di codice che contiene excel.


Probabilmente mi sbaglio perchè sono completamente ignorante in materia, ma a pelle questo mi sembra un po' mirror climbing :mc: Se excel non "conta" in interi a 16 bit allora quel valore che dà il problema non è differente da qualsiasi altro agli occhi del programmatore...perchè interessarsi di quanto può essere problematico in ALTRE rappresentazioni? :boh: ripeto, sono ignorante, spiegatemelo...

@rondinix
Con tutto il rispetto ma "Non ho avuto molto tempo per leggere la news e non ho letto minimamente i commenti" non mi sembra il massimo come linea di difesa :sofico:

Signori, creare un flame ogni volta che si parla di certe case o merche non è un buon modo di condurre le discussioni qui sul forum. Indi per cui, per piacere il flame finisce QUI e ORA.
In particolare, cdmauro, evitiamo atteggiamenti sarcastici e denigratori perchè sono vietati dal regolamento, e rondinix, tu prendi un'ammonizione, perchè se un post dà fastidio si segnala la cosa al moderatore e e non si risponde invece come hai fatto.

Probabilmente mi sbaglio perchè sono completamente ignorante in materia, ma a pelle questo mi sembra un po' mirror climbing :mc: Se excel non "conta" in interi a 16 bit allora quel valore che dà il problema non è differente da qualsiasi altro agli occhi del programmatore...perchè interessarsi di quanto può essere problematico in ALTRE rappresentazionie? :boh: ripeto, sono ignorante, spiegatemelo...

@rondinix
Con tutto il rispetto ma "Non ho avuto molto tempo per leggere la news e non ho letto minimamente i commenti" non mi sembra il massimo come linea di difesa :sofico:

il fatto che una persona non abbia tempo, non è una condanna....io sono un amatore...un simpatizzante per i PC e guarda un po...per Microsoft..ma i commenti possono anche esprimere opinioni personali(come ho fatto) e non solo tecnicismi

ho scritto che ad un commento si può rispondere anche con un opinione personale, infatti guarda un po...io non ho fatto un tecnicismo...ho al massimo criticato gli 800 euro di MSOffice.

e infine non si risponde con insulti ingiustificati come ha fatto cdimauro.
EDIT:
@leoneazzurro: con tutto il rispetto, ma ho segnalato il messaggio e ho addirittura cancellato un mio post perchè apparivo come un demente per come ha risposto cdimauro citando frase per frase.
Nella risposta fatta da me...il messaggio fondamentale è "c'è gente che ha meno tempo di te, che magari posta per opinionismo, e che la maleducazione si esprime in tanti modi tra i quali quelli di cdimauro" non mi sono spinto oltre e certamente non volevo scatenare flame

Definitiva fine dell'OFF

il fatto che una persona non abbia tempo, non è una condanna....io sono un amatore...un simpatizzante per i PC e guarda un po...per Microsoft..ma i commenti possono anche esprimere opinioni personali(come ho fatto) e non solo tecnicismi

ho scritto che ad un commento si può rispondere anche con un opinione personale, infatti guarda un po...io non ho fatto un tecnicismo...ho al massimo criticato gli 800 euro di MSOffice.

e infine non si risponde con insulti ingiustificati come ha fatto cdimauro.

@leoneazzurro: con tutto il rispetto, ma ho segnalato il messaggio e ho addirittura cancellato un mio post perchè apparivo come un demente per come ha risposto cdimauro citando frase per frase.
Nella risposta fatta da me...il messaggio fondamentale è "c'è gente che ha meno tempo di te, che magari posta per opinionismo, e che la maleducazione si esprime in tanti modi tra i quali quelli di cdimauro" non mi sono spinto oltre e certamente non volevo scatenare flame

Il discorso è che "si segnala" e basta, non "si segnala e poi si risponde a (vere o presunte) offese con offese".
E' una regola fondamentale, così come quella di mostrare sempre RISPETTO per il proprio interlocutore (e non mi sto riferendo a te qui).

Per piacere, ora basta discussioni, e se avete qualcosa da dirmi, in PVT come da regolamento.

Probabilmente mi sbaglio perchè sono completamente ignorante in materia, ma a pelle questo mi sembra un po' mirror climbing :mc: Se excel non "conta" in interi a 16 bit allora quel valore che dà il problema non è differente da qualsiasi altro agli occhi del programmatore...perchè interessarsi di quanto può essere problematico in ALTRE rappresentazionie? :boh: ripeto, sono ignorante, spiegatemelo...

La parte in neretto è facile da verificare su piccoli programmi non su quelli che contano millioni di righe.
Infatti non penso proprio che qualcuno conosca tutte le righe di codice di excel (quindi nessun programmatore potrà escludere a priori che vi è ad esempio un numero rappresentato con 16 bit) ed infatti c'è una suddivisione dei compiti sui grandi programmi.
Quindi semplificando un gruppo scrive una funzione, un altro un'altra funzione ecc.. quando poi si mette insieme è inevitabile che ci siano incongruenze od errori.
E scovarli tutti non solo è impossibile, ma anche leggendo il codice molti non si individuano.
L'unico modo quindi per individuare almeno i più grossolani è fare testing; ma non si può provare tutto con tutte le possibili combinazioni (è letteralmente impossibile) e quindi bisogna fare dei test mirati che vengono individuati in base all'esperienza e alla statistica (errori più frequenti).
E da questo è venuto fuori che spesso si commettono errori nel gestire i casi "estremi" e 65535 può essere rappresentato da 16 "uni" ( cosa che in fase di testing non si può escludere, visto che nessuno conosce tutto il codice)

Poi da cosa dipende il bug in questione può saperlo solo la Microsoft visto che il codice è chiuso (cioè nessun altro oltre a loro può leggerlo)

La parte in neretto è facile da verificare su piccoli programmi...CUT...

Ok capito :mano:
Avevo capito che il "motore" di excel lavorasse solo in "virgola mobile IEEE 754" o come si chiama :stordita:

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

Chissà quale Università di scienze avrò mai frequentato :rolleyes:

1 - 65535 (ma credo l'abbiano già detto) non è un numero casuale e con importanza minima, in informatica definirlo di importanza "enorme" è sottovalutarlo.
2 - Qualsiasi moltiplicazione che dia quel risultato produce un errore.
3 - 65535 compare come limite per un precedente bug.

Ignorarlo significa IMHO "insultare l'ingegneria del software". Con quali input avrebbero dovuto testare?

:eek: :eek: :eek: :eek: :eek: :eek:
Acc.... ma è proprio vero ?!

Adesso mi prendo una bella pausa. Vediamo chi avrà il coraggio di continuare a raccontare frottole dopo tutto quello che è stato scritto sul tema.

Sei un docente Universitario? Presumo di si dai tuoi precedenti commenti.
Ora, nei corsi di algoritmi o di architettura mi è stata insegnata una cosa fondamentale le scelte non si operano mai per caso. Semplice esempio che mi è rimasto particolarmente impresso:
Scelta della lunghezza di riga nello ShellSort, niente di casuale, si va dalle serie di potenze a Fibonacci, non perchè siano le scelte migliori ma semplicemente perchè non sono scelte casuali (l'ottimo, fino a prova contraria, non è a nostra disposizione).

Ora, non so quale metodo di sviluppo utilizzi Microsoft, sta di fatto che i test in qualche modo li conduce. Per condurre un test "di base" serve un input, un corrispettivo output, una funzione da testare e un elaboratore. Quale input/output scegliere? Siccome le scelte non si operano mai per caso si dovrebbe meditare sul da farsi. In questo caso 65535 (senza sfociare nella numerologia più spicciola) ricorre come limite in precedenti bug dello stesso software, è un limite delle precedenti versioni dello stesso software, è un numero di enorme importanza in informatica (è un limite di rappresentazione, FFFF)... ricordo che qualsiasi moltiplicazione che dia come risultato quel numero riproduce il bug.

Dimenticavo le conclusioni:
A parer mio che non sia stato usato nei test è indice di cattivo sviluppo. Non che sia uno sviluppatore e che mi ritenga al pari o superiore ad uno sviluppatore Microsoft, ma mi sembra doveroso criticare una simile svista.

Salto la disquisizione sulle parti polemiche e vado al sodo.
1. c'è gente che ha appena tempo di leggere 3/4 news e di dare qualche commento/opinione personale e basta
2. si chiamano commenti perchè uno da la propria opinione personale, e non sta a te decidere se il mio parere è giusto o sbagliato, proprio perchè al massimo puoi condividere o non condividere, anche perchè nessuno è tenuto a leggersi 5 pagine di commenti dove ci sono tecnicismi che magari non sono alla portata di tutti.
I tecnicismi ci sono anche nella news:

"Effettuando alcuni specifici calcoli come ad esempio 77,1*850 il risultato visualizzato da Excel 2007 è 100.000 anzichè 65.535.; altre combinazioni di calcolo aventi per risultato 65.535 sono affette dal medesimo errore. Salta subito all'cchio che il risultato atteso non è certo un numero qualsiasi ma è il valore più grande rappresentabile utilizzando 16 bit."

ed è di questo che si è parlato, ampliando anche la trattazione dell'argomento.

Questa è una news prettamente tecnica, per cui ha senso disquisire sul piano tecnico.
PS...io ho letto solo la notizia riportata qui su HWU...inizialmente....sempre citando il fattore tempo.
Hai anche detto di aver letto i messaggi di gente competente, e anche i miei, prima di scrivere il tuo messaggio: dunque dovevi essere abbastanza informato di quello che era stato scritto, in particolare dai "tecnici".

Mi sembra d'aver trattato piuttosto esaustivamente l'argomento, e per buona parte senza nemmeno andare a scomodare tecnicismi prettamente accademici: non saprei cos'altro avrei dovuto fare.
PPS: il bug esiste da un anno....office mi sembra sia uscito a ottobre 2006...ma sbaglio di sicuro....e cosa di cui sono sicuro è che su 10 utenti che vedono un bug, solo 8 ne segnalano la presenza.
Il che dimostra che questa:

"chi lavora a lungo con excel...il bug lo scopre eccome...."

tua affermazione era falsa, se è vero che c'è gente che lavora a lungo con Excel (e da quello che scrivi, oltre al fatto che è un'applicazione che ha MILIONI di utenti, non può che essere vero) ed è passato ben un anno dall'individuazione del bug.
PPPS: ripeto dunque...io non ho tentato di dare una spiegazione alla notizia....io ho commentato la notizia, non i commenti e i contenuti di supplemento alla notizia....e dico ciò solo per risaltare le tue offese che non mi spiego, ma vedo solo io....sarà il cuore che non funziona bene...meglio che stacco sennò mi prende un infarto.... e io che ho anche scritto che provavo rispetto per i tuoi ultimi commenti... è vero essere educati porta solo a essere insultato
Anch'io ho commentato la notizia (vedi il mio primo messaggio, ad esempio) e successivamente sono stato quotato e a mia volta ho risposto: i forum sono nati per questo.

Sul resto mi spiace che ti sia sentito offeso, ma non era mia intenzione: dal tuo messaggio sono scaturite un paio di battute, ma niente di più, e su questa parte "nera" della discussione sono disponibilissimo a darti ampie soddisfazioni in PVT, come da richiesta del moderatore.

L'errore non è nel "motore di calcolo" di Excel ma nel layer di visualizzazione, dato che questro strato SW non lavora su numeri in virgola mobile (li riceve solo in input, poi li "casta") ma esclusimente su interi (stringhe di caratteri)........almeno spero, i 65535/6 non sono più numeri come gli altri ;)
Il "casting" di questo strato del software avviene da virgola mobile a stringa: non si passa da nessun intero, a meno che tu con intero non ti riferisca al valore dei singoli caratteri contenuti nella stringa e in tal caso hai perfettamente ragione (sono gli interi fra 0 e 9 :)).
Non ho mai detto che il bug sia facilissimo da trovare, dato che non basta testare dei numeri particolari ma per ognuno di essi bisogna testare i vari modi in cui sono stati generati (solo i casi limite ;) mica tutti ) e questo per ogni tipo di dato (saremo nell'ordine dei milioni di combinazioni solo per il 65535 ;) )
Esattamente: il range è enorme, per cui non è possibile effettuare dei test esaustivi.
Resta il fatto che era un bug "trovabile" (duro da trovare ma si poteva fare tranquillamente visto i potenti mezzi a disposizione dalla "piccola" Microsoft)
I mezzi da sol inon bastano: serve anche una botta di culo. Come per tutti bug. :p
IMHO questo bug è dovuto ad un banalissimo (ma stronzissimo) errore di cast. (un classico :) )
Per quanto già detto, non sono d'accordo. Anche perché da questo http://blogs.msdn.com/excel/archive/2007/09/25/calculation-issue-update.aspx documento in cui viene descritto il problema non riguarda soltanto UN numero, ma DUE: sarebbe un cast a dir poco anomalo come comportamento, visto che dei due numeri almeno uno sarebbe perfettamente rappresentabile in un intero a 16 bit. :p

perchè visto che in certe rappresentazioni è un valore limite per scrupolo un programmatore lo deve provare ed un programmatore deve essere sempre puntiglioso (che poi il sw esente da errori non esiste è un altro discorso) .
Un programmatore deve testare che il software soddisfi tutti i requisiti per cui è stato progettato.

Se e solo se fra di essi c'è da tenere in considerazione particolari limiti, siano essi rappresentati da numeri "magici" o meno, lo dovrà fare, altrimenti è aggiungere test privi di significato è del tutto inutile.
Che poi in altre rappresentazioni non sia un valore limite non ha importanza visto il numero di righe di codice che contiene excel.
Non vuol dire niente: solo perché Excel è pieno di righe di codice è inutile aggiungere qualunque test ci passi per la testa. E' tempo (e risorse) sprecato.
Per esempio mettiti dalla parte del tester: chi gli dice che magari non ci sia un casting ad int a 16 bit che può dar problemi? Sapendo che era un numero potenzialmente a rischio di errori lo avrebbe dovuto provare -> e avrebbe trovato l'errore: questo non è stato fatto.
Semplicemente perché 65535 E (perché i numeri sono due e non uno) 65536 sono due qualunque numeri interi rappresentabili da uno in virgola mobile.

Il casting, poi, dovrebbe avere effetti su uno dei due.

A ciò aggiungiamo, poi, che in realtà i numeri che creano problemi non sono soltanto 2, ma ben 12 (10 sono "razionali").
Delle cause vere dell'errore se ne sarebbe occupato solo dopo averlo trovato (e sinceramente non mi interessano nemmeno, visto che la programmazione non è il mio campo)
Ripeto: i test non si possono fare a caso, soltanto perché esistono certi numeri nell'informatica. Bisogna avere buon senso, e in questo caso capire che i numeri in questione sono interi come altri.
.... e sono uscito pure con un voto alto!
bè vorrà dire che alla sapienza di roma non sanno insegnare allora :Prrr:
Sai bene che il voto non vuol dire niente. ;)

A me hanno anche dato la mensione d'onore, ma anche ad altri colleghi, eppure se a una chiedevi di splittare un file in due parti entrava nel panico. :asd:

La laurea, specialmente coi nuovi ordinamenti, è diventata una collezione di esami, o per meglio dire di crediti.

Ecco perché non amo tirare in ballo titoli "nobiliari", ma andare a guardare i fatti. :read: :D

A me hanno anche dato la mensione d'onore,

:mbe: :stordita:

Probabilmente mi sbaglio perchè sono completamente ignorante in materia, ma a pelle questo mi sembra un po' mirror climbing :mc: Se excel non "conta" in interi a 16 bit allora quel valore che dà il problema non è differente da qualsiasi altro agli occhi del programmatore...perchè interessarsi di quanto può essere problematico in ALTRE rappresentazioni? :boh: ripeto, sono ignorante, spiegatemelo...
Infatti non ha senso: sono numeri come altri.

:mbe: :stordita:
Hai ragione. :D

La parte in neretto è facile da verificare su piccoli programmi non su quelli che contano millioni di righe.
In questo caso sarebbe facile da verificare: la routine di conversione usata sarà una, anche se poi è usata più volte.

Certo, manca la materia prima: il sorgente. :D
Infatti non penso proprio che qualcuno conosca tutte le righe di codice di excel (quindi nessun programmatore potrà escludere a priori che vi è ad esempio un numero rappresentato con 16 bit) ed infatti c'è una suddivisione dei compiti sui grandi programmi.
Anche se fossero usati interi a 16 bit, quel che conta è andare a vedere come e perché vengono usati: non è dalla loro semplice presenza che si può presupporre che quel 65535 abbia un senso.

Esempio: posso usare un intero a 16 bit per contare il numero di caratteri generati dalla conversione. Ha attinenza col bug in questione? No, però è un intero a 16 bit anche questo...
Quindi semplificando un gruppo scrive una funzione, un altro un'altra funzione ecc.. quando poi si mette insieme è inevitabile che ci siano incongruenze od errori.
E scovarli tutti non solo è impossibile, ma anche leggendo il codice molti non si individuano.
Queste sono routine "fondamentali": difficile che chi lavori a Excel non le conosca. Persino quell'ex-programmatore MS ne ha parlato, ma ha detto di non poter verificare soltanto perché non aveva in mano il sorgente, quindi era ben a conoscenza del codice. ;)
L'unico modo quindi per individuare almeno i più grossolani è fare testing; ma non si può provare tutto con tutte le possibili combinazioni (è letteralmente impossibile) e quindi bisogna fare dei test mirati che vengono individuati in base all'esperienza e alla statistica (errori più frequenti).
Certamente: i test vanno fatti sempre mirati, non soltanto per far numero.
E da questo è venuto fuori che spesso si commettono errori nel gestire i casi "estremi" e 65535 può essere rappresentato da 16 "uni" ( cosa che in fase di testing non si può escludere, visto che nessuno conosce tutto il codice)
Chiaro, ma vedi sopra: bisogna sempre contestualizzare e vedere a cosa servono questi numeri e come vengono usati.
Poi da cosa dipende il bug in questione può saperlo solo la Microsoft visto che il codice è chiuso (cioè nessun altro oltre a loro può leggerlo)
Già.

Ok capito :mano:
Avevo capito che il "motore" di excel lavorasse solo in "virgola mobile IEEE 754" o come si chiama :stordita:
Esattamente: è proprio con questi che lavora, salvo poi convertirli in stringa per visualizzarli (ed è qui che c'è il bug).

Chissà quale Università di scienze avrò mai frequentato :rolleyes:
Qualunque essa sia non è questa in discussione e comunque conoscerla non servirà a niente: i titoli nobiliari lasciamoli a casa e occupiamoci esclusivamente dei fatti.
1 - 65535 (ma credo l'abbiano già detto) non è un numero casuale e con importanza minima, in informatica definirlo di importanza "enorme" è sottovalutarlo.
Certamente, ma solo SE e QUANDO serve.
2 - Qualsiasi moltiplicazione che dia quel risultato produce un errore.
I casi citati sono ben 12. Fonte: pagine del sito MS che si occupa del bug.
3 - 65535 compare come limite per un precedente bug.
Questo non risulta.
Ignorarlo significa IMHO "insultare l'ingegneria del software".
No, significa che nel contesto è inutile trattarlo.
Con quali input avrebbero dovuto testare?
Con tutti, visto che quello è un numero come un altro, che va semplicemente convertito. E tra l'altro, come dicevo prima, non è l'unico caso: i numeri interi interessati sono ben due ed è MOOOOOOLTO difficile credere che si tratti di problemi di casting e/o di "limiti", specialmente per le condizioni al contorno (vedi nuovamente pagina sul sito MS).

Sei un docente Universitario? Presumo di si dai tuoi precedenti commenti.
Presumi male, e non è l'oggetto della discussione: attieniti al topic. Oggi i flame sono stati anche troppi, e non ho intenzione di alimentarne in nessun modo.
Ora, nei corsi di algoritmi o di architettura mi è stata insegnata una cosa fondamentale le scelte non si operano mai per caso. Semplice esempio che mi è rimasto particolarmente impresso:
Scelta della lunghezza di riga nello ShellSort, niente di casuale, si va dalle serie di potenze a Fibonacci, non perchè siano le scelte migliori ma semplicemente perchè non sono scelte casuali (l'ottimo, fino a prova contraria, non è a nostra disposizione).
Sono esempi che non c'entrano con l'oggetto del thread. Esistono, ma sono a sé stanti: nulla implicano per altri contesti.
Ora, non so quale metodo di sviluppo utilizzi Microsoft, sta di fatto che i test in qualche modo li conduce. Per condurre un test "di base" serve un input, un corrispettivo output, una funzione da testare e un elaboratore. Quale input/output scegliere? Siccome le scelte non si operano mai per caso si dovrebbe meditare sul da farsi. In questo caso 65535 (senza sfociare nella numerologia più spicciola) ricorre come limite in precedenti bug dello stesso software, è un limite delle precedenti versioni dello stesso software, è un numero di enorme importanza in informatica (è un limite di rappresentazione, FFFF)... ricordo che qualsiasi moltiplicazione che dia come risultato quel numero riproduce il bug.
1) I numeri da testare sono un'ENORMITA' e ognuno avente pari dignità (anche qui, fino a prova contraria e con tanto di giustificazione del perché un numero debba essere considerato "miglior candidato" di un altro per i test).

2) Non risulta che i precedenti bug abbiano a che fare esattamente con questo.

3) Anche 65536 è un numero di enorme importanza, ed è anche lui fonte del bug in questione.

4) I risultati che producono quell'errore sono ben DODICI (che in informatica è un numero qualunque).
Dimenticavo le conclusioni:
A parer mio che non sia stato usato nei test è indice di cattivo sviluppo. Non che sia uno sviluppatore e che mi ritenga al pari o superiore ad uno sviluppatore Microsoft, ma mi sembra doveroso criticare una simile svista.
Bisognerebbe giustificarla. Ad esempio: fa parte dei requisiti del problema? Se sì, allora aggiungere un test su questo numero avrebbe senso, altrimenti no (leggi: è tempo perso).

I test, come le scelte, non si fanno a caso: bisogna sempre avere davanti il problema e tirarli fuori in base ai requisiti che deve soddisfare.

Numeri come 65535 in questo caso hanno PARI DIGNITA' rispetto ad altri: non si capisce su quale base dovrebbero essere trattati diversamente.

A me hanno anche dato la mensione d'onore, ma anche ad altri colleghi, eppure se a una chiedevi di splittare un file in due parti entrava nel panico. :asd:
..

Spiegami allora quale è la difficoltà nel fare una comparazione di due file, uno con i valori reppresentati a video e uno con i valori veri e tirare fuori solo le occorrenze con differenza maggiore di un numero dettato dal buonsenso..
secondo me un test vero non lo hanno mai fatto

Spiegami allora quale è la difficoltà nel fare una comparazione di due file, uno con i valori reppresentati a video e uno con i valori veri e tirare fuori solo le occorrenze con differenza maggiore di un numero dettato dal buonsenso..
Perché, come già detto, i valori da testare sono TROPPI.
secondo me un test vero non lo hanno mai fatto
Coi "secondo me" da soli puoi dire quello che vuoi, ma non ne usciamo più.

Hai prove? Non mi pare. Indizi? Nemmeno. E allora su quale base hai fatto quest'affermazione?

Sono 4 righe di un programma in c indentato bene :) ..
certo ci vorrebbe uno spazio molto capiente per fare uno unit test vero.. ma io lo farei e parlo di unit test, a 65 mila ci arrivo di sicuro

Sono 4 righe di un programma in c.. certo ci vorrebbe uno spazio molto capiente per fare uno unit test vero.. ma io lo farei e parlo di unit test
Devi sapere COSA testare però, e ancora questo non è chiaro.

Testi la funzione che fa il casting confrontando n valori inseriti con quelli prodotti dalla funzione.. non mi sembra una cosa fuori dal mondo molte volte certo si pecca di leggerezza e si è sicuri del risultato ma anche io ho imparato che niente è sicro quando si inizia a scrivere codice, quindi anche il test deve essere molto semplice 4 righe e una chiamata a funzione

Testi la funzione che fa il casting confrontando n valori inseriti con quelli prodotti dalla funzione.. non mi sembra una cosa fuori dal mondo molte volte certo si pecca di leggerezza e si è sicuri del risultato ma anche io ho imparato che niente è sicro quando si inizia a scrivere codice, quindi anche il test deve essere molto semplice 4 righe e una chiamata a funzione
E dove starebbe il casting in questo caso? E' una tua supposizione, suppongo (!). ;)

E dove starebbe il casting in questo caso? E' una tua supposizione, suppongo (!). ;)

Guarda.. ti do ragione se stai cercando di dire che puoi essere la Microsoft o chi ti pare, puoi avere il miglior gruppo di test a tua disposizione ma se sotto non c'è un gruppo coscenzioso e con le bolas di developers allora stai tranquillo che vai incontro a imprevedibili conseguenze

Guarda.. ti do ragione se stai cercando di dire che puoi essere la Microsoft o chi ti pare, puoi avere il miglior gruppo di test a tua disposizione ma se sotto non c'è un gruppo coscenzioso e con le bolas di developers allora stai tranquillo che vai incontro a imprevedibili conseguenze
Non ho detto questo ed è inutile cercare di mettermi in bocca parole che non mi sognerei nemmeno di dire: non sono il tipo che abbocca, e ormai avresti dovuto capirlo.

Per lo stesso motivo, è anche inutile che cerchi di cambiare discorso: hai parlato di casting, e sono curioso di sapere da dove l'hai tirato fuori.

Se fa casting o upscaling o costruisce integrali sulla media ponderata tra la radice delle triple di bit fratto un indice per poi tirare fuori il numero magico con l'algoritmo inventato da chissacchì non me ne importa,
il casting è la cosa più semplice a cui si possa pensare ma non è questo il punto,
se una funzione o n funzioni appiccicate con la colla producono qualcosa esse vengono richiamate ogni volta che si fa apparire un numero sul foglio di calcolo e in quanto tali queste funzioni (o funzionalità) possono e devono essere richiamate per essere testate, altrimenti se non si può fare l'ingegnerizzazione del software fa schifo ma non credo
comunque scusa, era solo un tentativo da parte mia di capire.. se non volevi dire quello non ti do ragione ma potrei avere anche torto (cosa probabile comunque) :p .. rileggendomi deco rassicurarti assolutamente che ero in buona fede :muro:

Se fa casting o upscaling o costruisce integrali sulla media ponderata tra la radice delle triple di bit fratto un indice per poi tirare fuori il numero magico con l'algoritmo inventato da chissacchì non me ne importa,
il casting è la cosa più semplice a cui si possa pensare ma non è questo il punto,
se una funzione o n funzioni appiccicate con la colla producono qualcosa esse vengono richiamate ogni volta che si fa apparire un numero sul foglio di calcolo e in quanto tali queste funzioni (o funzionalità) possono e devono essere richiamate per essere testate, altrimenti se non si può fare l'ingegnerizzazione del software fa schifo ma non credo
comunque scusa, era solo un tentativo da parte mia di capire.. se non volevi dire quello non ti do ragione ma potrei avere anche torto (cosa probabile comunque) :p .. rileggendomi deco rassicurarti assolutamente che ero in buona fede :muro:
Hai detto tutto e niente. Per la precisione, non hai detto niente, per quanto riguarda l'oggetto della discussione, ossia il bug in questione.

Hai parlato di:
- test da fare su comparazione di due file;
- unit test (e mi sono accorto adesso che hai aggiunto che "a 65 mila ci arrivo di sicuro"; quindi suggerisci un approccio di tipo forza bruta, che però è impossibile a causa dell'elevatissima quantità di numeri da testare, visto che TUTTI hanno pari dignità e andrebbero testati senza, dunque, fermarsi a 65mila e cocci);
- casting (e ancora, scusami se faccio la carogna e te lo ripeto, ma non l'hai scritto il perché);
- gruppi di programmazione incoscienti e conseguenze imprevidibili (cosa c'entri con la discussione non si capisce);
- di supermegacazzola con funzioni appiccicate con la colla.

La domanda sorge spontanea: dove vuoi arrivare?

La domanda sorge spontanea: dove vuoi arrivare?

Voglio arrivare a capire cosa si sono fumati in Microsoft :read: :D

Non ci puoi arrivare senza sorgenti, ma sta tranquillo che non c'entra il casting sugli interi a 16 bit del numero da rappresentare. ;)

Adesso vado a nanna però. :p Notte a tutti. :)

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.
A me non risulta. Anzi, dalla prova che ho fatto io l'errore se lo porta dietro..

Non so che prove tu abbia fatto, ma hai sicuramente sbagliato:
A1 = 77,1 * 850 -> 100000 (valore errato, perché fa parte dei primi SEI numeri per i quali si verifica il bug)
B1 = A1 + 1 -> 100001 (valore errato, perché fa parte degli altri SEI numeri per i quali si verifica il bug)
C1 = B1 + 1 -> 65537 (valore corretto, perché il risultato non appartiene a nessuno dei 12 numeri per i quali si verifica il bug)
E', dunque, un problema di VISUALIZZAZIONE e non di errata moltiplicazione, come falsamente attestato dalla notizia.

Mi sento solidare con excel: anche io sbaglio sempre le moltiplicazioni! Non vi dico poi le divisioni :D...

Bè, diciamo che non capita tutti i giorni di fare calcoli con quel risultato però se era documentato anche nella preistorica versione 5 allora sono perseveranti.... un'attenuante c'è per il fatto che l'errore è solo di visualizzazione però.

Bè, diciamo che non capita tutti i giorni di fare calcoli con quel risultato però se era documentato anche nella preistorica versione 5 allora sono perseveranti.... un'attenuante c'è per il fatto che l'errore è solo di visualizzazione però.

Il bello è che io non ho questo bug quindi è pure un problema di versioning delle fix

...e bill gates fa i soldi. Se li conta con il suo programma allora è meno ricco di quanto crede :lol

Dopo aver letto la notizia su vari forum e centinaia di commenti, la mia conclusione è questa:

- 65535 e 65536 SONO numeri più importanti di altri. Quei 12 numeri incriminati, stretti parenti di 65535 e 65536, devono avere qualcosa di MOLTO particolare in binario (non ho il tempo di verificare cosa...) quindi NON hanno pari dignità con gli altri 18 miliardi di miliardi ecc.

- Non so dov'è il baco, ma credo molto all'ipotesi di un tizio su Slashdot che teorizzava un >= al posto di > (con numeri "di confine" come quelli incriminati ogni tanto capita).

- OK, era difficile trovare il baco, ma IMHO la colpa è proprio di Microsoft che ha un fatware (software obeso!) che impedisce aggiornamenti e test in tempi umani.

- Of course non credo al complotto del dipendente Microsoft dimissionario. Microsoft non ha bisogno di complotti per produrre bugware.

La laurea, specialmente coi nuovi ordinamenti, è diventata una collezione di esami, o per meglio dire di crediti.

Ecco perché non amo tirare in ballo titoli "nobiliari", ma andare a guardare i fatti. :read: :D

Adesso non mi cadere nelle frasi fatte o nei luoghi comuni, che non ci fai una bella figura! :rolleyes:
Giusto per la cronaca siamo stati solo in 5 a prendere la laurea specialistica in Ing. delle Telecomunicazioni nella intera sessione di Settembre di quest'anno (in un anno si arriverà si e no a 40).
Quindi foss'anche una collezione d'esami ciò non significa che ora sia più facile (lo è stato i primissimi anni di riforma, perchè volevano incentivare il passaggio al "nuovo", non certo ora, e io lo posso dire a ragione visto che la metà degli esami li ho fatti al vecchio ordinamento)
Detto questo, ma perchè al vecchio ordinamento non era sempre una collezione d'esami ?

Per finire i titoli "nobiliari" contano eccome, mio caro: prova a farti assumere dove richiedono una certa laurea e poi vedi, se non ce l'hai, se ti prendono!
(poi indubbiamente contano anche altre cose)
E con questo chiudiamola con l'OT

Dopo aver letto la notizia su vari forum e centinaia di commenti, la mia conclusione è questa:

- 65535 e 65536 SONO numeri più importanti di altri.
Ma sono DUE e non UNO, per cui è difficile pensare a roba come casting, >= al posto di > (o viceversa), perché mi sembra a dir poco ovvio che l'impatto sarebbe dovuto essere su UNO SOLO dei due.
Quei 12 numeri incriminati, stretti parenti di 65535 e 65536, devono avere qualcosa di MOLTO particolare in binario (non ho il tempo di verificare cosa...)
E' scritto nel post di MS: sono numeri di confine nel range rappresentabile con valori in virgola mobile IEEE 754 a doppia precisione.
quindi NON hanno pari dignità con gli altri 18 miliardi di miliardi ecc.
Non vedo perché: TUTTI gli interi hanno numeri frazionari di confine simili a quelli di quei due numeri.
- Non so dov'è il baco, ma credo molto all'ipotesi di un tizio su Slashdot che teorizzava un >= al posto di > (con numeri "di confine" come quelli incriminati ogni tanto capita).
Se così fosse il bug sarebbe su UN solo numero, e non su due. E' evidente che il problema NON può essere causato da un solo bug.
- OK, era difficile trovare il baco, ma IMHO la colpa è proprio di Microsoft che ha un fatware (software obeso!)
Questa è una tua opinione non suffragata da fatti.

Poi roba come OpenOffice, che è il principale concorrente, definirlo "obeso" vuol dire soltanto fargli un complimento. :rolleyes:
che impedisce aggiornamenti e test in tempi umani.
I test li fanno, anzi hanno una politica di test come poche altre società: è proprio per questo che gli aggiornamenti vengono rilasciati dopo diversi giorni.
- Of course non credo al complotto del dipendente Microsoft dimissionario.
Se è quello che ha parlato nel suo blog, quel dipendente è da un pezzo che non lavorava più alla MS, e il suo commento alla notizia non è certo sembrato polemico: tutt'altro. E' stato, anzi, abbastanza chiaro e utile.
Microsoft non ha bisogno di complotti per produrre bugware.
Come nessun'altra società, ente o persona che produce software.

Anzi, dalle statistiche è fra le migliori società al mondo quanto a numero di bug per righe di codice.

Adesso non mi cadere nelle frasi fatte o nei luoghi comuni, che non ci fai una bella figura! :rolleyes:
Sei stato tu a tirare in ballo il voto di laurea, e questo sai bene che di per sé non vuol dire nulla: anche quello del laureato con voto alto che è sicuramente bravo è un luogo comune.
Giusto per la cronaca siamo stati solo in 5 a prendere la laurea specialistica in Ing. delle Telecomunicazioni nella intera sessione di Settembre di quest'anno (in un anno si arriverà si e no a 40).
Quindi foss'anche una collezione d'esami ciò non significa che ora sia più facile (lo è stato i primissimi anni di riforma, perchè volevano incentivare il passaggio al "nuovo", non certo ora, e io lo posso dire a ragione visto che la metà degli esami li ho fatti al vecchio ordinamento)
Non mi sono riferito a te.
Detto questo, ma perchè al vecchio ordinamento non era sempre una collezione d'esami ?
Era una gara a eliminazione. Quando avevi 6 materie annuali con dei mallopponi da portarti dietro tutti a giugno, non è che avevi molte possibilità: potevi prepararti uno o due esami da sostenere fra giugno e luglio, per poi rimandare qualche altro a settembre-ottobre, e a novembre ricominciavano le lezioni con qualche altro esame pendente.

Adesso con corsi tri-quadrimestrali ridotti a pochi crediti è decisamente più semplice uscirsene fuori (tanti corsi che prima erano annunali sono stati divisi in due o addirittura tre corsi nel nuovo ordinamento).

Inoltre i corsi di laurea sono diventati una bolgia di materie con pochi crediti spesso messi così per fare numero.
Per finire i titoli "nobiliari" contano eccome, mio caro: prova a farti assumere dove richiedono una certa laurea e poi vedi, se non ce l'hai, se ti prendono!
Non contano in discussioni come questa.

Per il resto, è vero: spesso le società più quotate vanno a guardare titolo e voto, altrimenti ciccia.

Infatti prima di conseguire la laurea non mi hanno potuto assumere in una multinazionale proprio per questa cazzata; dopo mi hanno cercato ben due volte (e con proposte non indifferenti), ma avevo già preso un altro lavoro e sto decisamente meglio (dove, tra l'altro, conta quello che sai fare).
(poi indubbiamente contano anche altre cose)
Purtroppo è vero: tante volte le altre cose, che sono più importanti, passano in secondo piano.
E con questo chiudiamola con l'OT
L'OT lo chiudiamo, ma i titoli nobiliari in merito a questa notizia (e come per qualunque valutazione tecnica) non servono a niente, ed era questo a cui mi riferivo.

P.S. Io non ho la laurea col vecchio ordinamento: sono passato al nuovo e ho conseguito quella triennale. Non mi sono iscritto alla specialistica (pur avendo altri esami da convalidare ed avendo già fatto stage in azienda) perché lavoro già e le materie che hanno inserito nei piani di studi non mi piacciono per niente.

Hihihih, immagino le conseguenze se, parlando di soldi, hanno preso il valore a manina leggendolo.

A seconda di chi fa il calcolo si può anche svuotare il conto in banca :asd:

Vabbè comunque tra poco arriverà il fix, una sVista (:D :rotfl: ) ci sta quando fai le ore piccole a programmare e dopo 14 ore non vedi l'ora di andare a casa a dormire :fagiano:

MEMORANDUM PER LE AZIENDE:
Aziende di tutto il mondo! Non fate fare gli straordinari a noi poveri programmatori! Poi per la stanchezza e il cervello fuso escono queste boiate! :p

Scusami ma che test sarebbe? Se ci aggiungi 0 è normale che ricompare lo stesso valore... :mbe:Secondo quanto scritto nella news, avrei dovuto ricevere il risultato corretto. Ho creato un'equazione, nella quale i due numeri moltiplicati davano il risultato a video errato, poi dovevano addizionarsi al prodotto di un'altra moltiplicazione che risultava 0. Secondo quanto letto nella news, mi aspettavo pertanto che avrei visto a video il risultato corretto a video.

Nella news parla di altro.

Aggiungere 0 non comporta nessun cambiamento, perché il dato memorizzato (o calcolato) rimane lo stesso.

Nella news parla di altro.

Aggiungere 0 non comporta nessun cambiamento, perché il dato memorizzato (o calcolato) rimane lo stesso.Matematicamente è vero, ma nella news si faceva riferimento a numero a video che nasconde quello vero. Excel dovrebbe poi calcolare in modo corretto. Al contrario, non ci riesce.

A proposito, ho scoperto che la versione Enterprise è diversa dalle altre. Non mi accetta il Service Pack 3 (sempre che il motivo non sia che avevo già installato gli aggiornamenti manualmente).

Infatti i calcoli sono corretti, anche nel caso che hai citato: è soltanto un problema di visualizzazione per soli 12 valori.

Adesso capisco come ha fatto MS a dichiarare di aver venduto tante 100.000 copie di Office 2007 il primo giorno!!!!


Ah Ah Ah Ah

Io vorrei commentare dicendo solo che chi crede che MS stia per Microsoft non ha capito nulla, MS sta per morte sicura...


COLTIVATE LINUX, TANTO WINDOWS SI PIANTA DA SOLO!!!

Ti registri appositamente sul forum per postare il tuo primo messaggio riesumando un thread di mesi fa ...... e spari minchiate? :mbe:

Età? :rolleyes:





Bah :D