Volt már hasonló kis finomságokról szó itt a blogon és a mai posztban ismét az Excel "iparági szabványból" következő határvonala kerül feszegetésre, ami igazából nem újdonság, de valószínűleg sokak számára még nem ismert. Ez pedig az Excel ún. 15-számos korlátja.
Adott a következő szorzás Excelben:
Ha megnézzük egy sima számológépben az eredményt, akkor ezt látjuk:
Viszont ha Excelben nyomunk egy Entert a kis szorzásunkra, akkor ezt látjuk:
Bizony, az Excel nem jó eredményt adott a szorzásunkra! És ez nem csak specifikusan ennél a szorzásnál van így, láthatjuk, hogy ha két 222 milliós számot szorzunk össze, akkor sincs minden rendben:
Sőt, ilyen hosszú számokat be sem tudunk írni, az Excel 15 számjegy utána automatikusan 0-ra kerekít. Ha csak egy kalkulációnál futunk bele ebbe, akkor még azt is hihetjük, hogy valami gond van a táblázatkezelőnkkel, pedig amúgy nincs, amit tapasztalunk az szándékos és ismert korlát.
Ahogy ebben az írásban már fejtegettem, a magyarázat az Institute of Electrical and Electronics Engineers eredetileg kizárólag villamosmérnököket később aztán már informatikusokat is tömörítő szakmai szolgáltató szervezet egyik számformátumának követelményéből adódik, ami azt írja elő, hogy a számokat bináris formátumban kell tárolni (ez az IEEE 754/1985 lebegőpontos számformátum). Ebben a követelményrendszerben 15 számjegynél hosszabb számok tárolása nagyobb memóriát és erőforrást igényelne, így iparági szabványoknak megfelelően az erőforrások optimalizálása érdekében 15 számjegy után jön a kerekítés.
És bár szorzásnál ez annyira nem valószínű, hogy érinteni fog bennünket, de fontos észben tartani ezeket a korlátokat, hiszen pl. az 1/3 sem azt az eredményt fogja Excelben adni, mint amit matematikai tanulmányaink során próbáltak megtanítani nekünk.
További korlátokat láthatunk még a fentebb már linkelt írásban is, ahogy a lehetséges megoldásokat is, azaz a ROUND függvény vagy a Precision As Displayed funkció használatát.
Azért persze ez nagyjából olyan súlyú probléma, mint amikor régen a kéziszámológépek sem tudtak egészen egyszerű műveleteket megfelelően kezelni ilyen-olyan okokból kifolyólag, például amikor beadtuk a 369/258/147 osztást, majd az így kapott eredményt megszoroztuk előbb 147-tel, majd 258-cal - és a végeredmény nem 369 lett pontosan.
