Bug στο MS Excel 2007

[sparc]

Πριν, 3 μέρες στο ακόλουθο thread του google groups microsoft.public.excel αναφέρθηκε πως η 2007 έκδοση του Excel, τρελαίνεται όταν ο αριθμός 65.535 συμπεριλαμβάνεται σε αριθμητικές πράξεις, έμμεσα ή άμεσα, δίνοντας λανθασμένα αποτελέσματα.
Για παράδειγμα ο πολ/σμός 850*77,1 (που κανονικά ισούται με 65.535), δίνει 100.000. Το bug αυτό είναι σημαντικό αφού αν ο χρήστης δεν το γνωρίζει, δεν έχει καμία απολύτως ένδειξη ότι κάτι πάει στραβά και συνεπώς είτε θα δεχθεί λανθασμένα νούμερα, είτε θα ψάχνει βελόνα στα άχυρα, αφού όσες φορές και να κάνει τις πράξεις, το excel πιστεύει ακράδαντα πως 850*77,1=100.000 !

PS: αν κάποιος αναρωτιέται τα αίτια του bug, να πω ότι το 65.535 (=2^16 -1)  δεν είναι τυχαίος αριθμός και αποτελεί το άνω φράγμα τιμών για αρκετούς τύπους μεταβλητών στις περισσότερες γλώσσες. Κυρίως για unsigned integer. Ο υπολογισμός ενός γεμάτου λογιστικού φύλλου είναι πολύ πιθανό να απαιτεί τον ορισμό δεκάδων μεταβλητών. Συνεπώς, ιδιαίτερη βαρύτητα πέφτει στην οικονομία χώρου. Όλα αυτά τα προβλήματα θα μπορούσαν να μην υπάρχουν αν όλες οι μεταβλητές ορίζονταν ως long (2^32) αλλά αυτό θα ήταν τεράστια σπατάλη πόρων.
Αντιθέτως χρησιμοποιούνται δυναμικοί τύποι μεταβλητών μη σταθερού μεγέθους, ανάλογα με την τιμή την οποία περιέχουν. Είναι πολύ πιθανό λοιπόν, το σφάλμα να παρουσιάζεται στον κώδικα μετάβασης από unsigned integer στην επόμενη κλάση των unsigned long (αφού το αριθμητικό όριο για την μετάβαση είναι το 65.535). Έτσι, υποθέτω πως ο πολλαπλασιασμός (-850)*(-77,1) θα δώσει το σωστό αποτέλεσμα αφού ο τύπος signed integer έχει ως όριο το 32.768, οπότε το γινόμενο θα υπολογισθεί με χρήση signed long εξ αρχής.
Αν κάποιος έχει Excel 2007 ας το δοκιμάσει.

[timos_m]

Το δοκίμασα και ισχύει, όντως, για το 850*77,1. Παρ'όλ' αυτά δοκίμασα 85*771 και βγάζει το σωστό αποτέλεσμα, όπως και το 2^16-1...

[drcypher]

Αντιθέτως χρησιμοποιούνται δυναμικοί τύποι μεταβλητών μη σταθερού μεγέθους, ανάλογα με την τιμή την οποία περιέχουν. Είναι πολύ πιθανό λοιπόν, το σφάλμα να παρουσιάζεται στον κώδικα μετάβασης από unsigned integer στην επόμενη κλάση των unsigned long (αφού το αριθμητικό όριο για την μετάβαση είναι το 65.535). Έτσι, υποθέτω πως ο πολλαπλασιασμός (-850)*(-77,1) θα δώσει το σωστό αποτέλεσμα αφού ο τύπος signed integer έχει ως όριο το 32.768, οπότε το γινόμενο θα υπολογισθεί με χρήση signed long εξ αρχής.

Δεν εκπλήσσομαι καθόλου από το ενδεχόμενο να υπάρχει τέτοιο (ή χειρότερο) bug στο Excel, αλλά απορώ με κάτι άλλο: Όταν πολλαπλασιάζεις δυο αριθμούς διαφορετικού τύπου (ή εύρους) λογικά η μεταβλητή που κρατά το αποτέλεσμα θα πρέπει να "αναβαθμίζεται" ώστε να έχει αν μη τι άλλο την ίδια "χωρητικότητα" με την πιο ευρεία των δυο παραγόντων.

Π.χ. το -850 μπορεί κάλλιστα να αποθηκεύεται ως short int (ή τέλος πάντων κάτι στα 2 bytes), αλλά το -77.1 θα πρέπει να αποθηκευτεί τουλάχιστον ως float (αν όχι double). Άλλωστε το γινόμενο δυο τέτοιων αριθμών θα είναι κατά κανόνα δεκαδικός αριθμός, συνεπώς μου φαίνεται παράλογο να χρησιμοποιείται για το αποτέλεσμα ο short int (που έχει και το συγκεκριμένο πρόβλημα), εκτός αν ο χρήστης ορίσει σε κάποιο κελί με το χέρι τον τύπο που επιθυμεί (οπότε θα έχουμε explicit casts).

[sparc]

dr έχεις δίκιο, ωστόσο δεν διαφέρει σε τπτ με όσα είπα, απλά αναφέρθηκα, σκοπίμως, εσφαλμένα σε integers (εμφανέστατο αφού το 77,1 είναι δεκαδικός) για απλότητα έκφρασης ώστε όλοι να καταλάβουν τι εννοώ.

Επίσης, σύμφωνα με τα αποτελέσματα του timos_m, είναι φανερό πως το πιθανότερο είναι το bug να περιορίζεται στο recast float τύπου μεταβλητών, αφού σε εκθετική αλλά και ακέραια μορφή το γινόμενο δίνει σωστό αποτέλεσμα.

[drcypher]

Δεν είπα ότι έκανες λάθος (τουλ. που να επηρεάζει τα λεγόμενά σου). Η απορία μου αφορά στο ίδιο το bug: Άλλο το +5 (char και πάνω) κι άλλο το +5.0 (float και πάνω). Όταν πολλαπλασιάζεις το (+5) με το (+5.0) το αποτέλεσμα είναι (περίπου; ) +25.0 (float). Για ποιον λόγο το κάνουν cast σε int δεν μπορώ να καταλάβω (δεδομένου ότι κατά κανόνα τα αποτελέσματα θέλουμε να παραμένουν δεκαδικά)

[sparc]

Δεν νομίζω ότι το κάνουν cast σε int. Εφόσον κάποιος από τους αρχικούς παράγοντες είναι δεκαδικός, τότε και το αποτέλεσμα είναι δεκαδικό. Άρα όταν πολ/ζουμε 850 με 77,1 παίρνουμε ως αποτέλεσμα 100.000,0 εσφαλμένα (ή 65.535,0). Αντιθέτως, πολ/ντας 85 με 771 το αποτέλεσμα είναι long integer.
Συνεπώς, σύμφωνα με όσα είπε ο timos_m, το πρόβλημα περιορίζεται λογικά, στην κλάση float, και εγώ υποθέτω ότι στο 65.535 πρέπει να γίνεται αλλαγή υποκλάσης (ίσως από single σε double float) και εκεί να γίνεται το σφάλμα επειδή η τιμή οριακά χωράει σε single.

[theos]

Σύμφωνα με αυτά που λες sparc δεν θα έπρεπε να βγάζει λάθος και το 8500*7,71?

Το βγάζει σωστό πάντως. Και όλες τις άλλεσ πιθανές πράξεις. Μόνο αυτό βγάζει λάθος

[sparc]

Άρα το πιθανότερο είναι, ο συλλογισμός μου να είναι εξ αρχής λάθος και το πρόβλημα να μην έγκειται στην μετατροπή μεταξύ τύπων μεταβλητών.
Όπως και να έχει πιστεύω ότι είναι απίθανο μόνο ο συγκεκριμένος πολ/σμός να δίνει λάθος αποτέλεσμα, οπότε προσοχή.

[theos]

Τι προσοχή? Δεν υπάρχει αυτό. Δεν μπορείς να προσέξεις! Απλώς αλλάζεις software αφού είναι αναξιόπιστο

Γιατί φυσικά δεν είναι καθόλου λογικό και εφικτό να κάθομαι να ψάχνω αν έχει κάνει σωστά τις πράξεις.

Βέβαια, αυτό το excel που έχω εγώ είναι beta και δικαιολογούνται κάποια λαθάκια. Τεσπα... Ίδωμεν

[drcypher]

Τι προσοχή? Δεν υπάρχει αυτό. Δεν μπορείς να προσέξεις! Απλώς αλλάζεις software αφού είναι αναξιόπιστο

Αρκετά ενδιαφέρουσα άποψη, ειδικά όταν την ακούει κανείς... από σένα! Η έκφραση "αξιόπιστο λογισμικό" φυσικά χωράει πάρα πολλή συζήτηση (η οποία ήδη γίνεται στον πολιτισμένο κόσμο), αλλά στο μικρό μου μυαλό αναξιόπιστο είναι π.χ. και το λογισμικό που λειτουργεί σαν ραδιενεργός πυρήνας: Έχει μια στάνταρ πιθανότητα να σου "σκάσει" (crash), η οποία, όμως, είναι ανεξάρτητη από τα προηγούμενα crashes και παραμένει σταθερή στο χρόνο, αφήνοντάς σε στο σκοτάδι της στατιστικής...

Με την ίδια λογική κανείς θα έπρεπε, λοιπόν, να αλλάξει και τα Windows. Μόνο που υπάρχει μια διαφορά: Άλλο ο gaussιανός τερματισμός λειτουργίας ενός προγράμματος/λειτουργικού και άλλο τα λογικά σφάλματα. Στην μεν πρώτη περίπτωση απλώς σταματάς να κάνεις δουλειά. Στην δεύτερη συνεχίζεις νομίζοντας ότι όλα πάνε καλά, ενώ το πρόγραμμα παράγει λανθασμένα αποτελέσματα.

Δεδομένου ότι μιλάμε για λογισμικό που χρησιμοποιείται κατά κόρον σε λογιστικές εργασίες, θα μπορούσε κανείς να ζητήσει ακόμα και αποζημίωση από την Microsoft για ενδεχόμενο λάθος που θα επέφερε οικονομική ζημία και θα οφειλόταν στο bug.

[theos]

Μόνο που αν αλλάξεις το excel και πας στο openoffice προσαρμόζεσαι σε 1 ώρα όσο δύσκολα και αν ήταν αυτά που έκανες στο excel. Κοινώς συγκρίνεις ανόμοια πράγματα. Επίσης να προσθέσω ότι δεν είπα ακριβώς αυτό που κατάλαβες drcypher.

Είπα πως προκειμένου να μην το εμπιστεύεσαι και να ψάχνεσαι για λάθη καλύτερα να πας αλλού. Γιατί δεν μπορείς να ελέγχεις ένα τέτοιο πρόγραμμα. Αν μπορούσες να το ελέγχεις θα τα έκανες με το μυαλό

Θεωρητικά έχει ενδιαφέρον αυτό που λες. Να ζητήσει κάποιος αποζημίωση δηλαδή. Αλλά αφενός δεν ξέρω αν το λάθος υπάρχει και στην τελική version του excel και αφετέρου αν αυτός που ζητήσει αποζημίωση μπορεί να αποδείξει ότι έκανε το συγκεκριμένο λάθος και του κόστισε. ΧΧΧμμμ. Τώρα που το σκέφτομαι υπάρχει και τρίτο κόλλημα. Θα το έχει το excel σε γνήσιο? Λίγοι το έχουν αγοράσει πάντως...

[Wizard]

... Αλλά αφενός δεν ξέρω αν το λάθος υπάρχει και στην τελική version του excel...

Υπάρχει

[timos_m]

Αλλά αφενός δεν ξέρω αν το λάθος υπάρχει και στην τελική version του excel

Την τελική έχω...