Elliott Roper said:
Well, that's putting a pretty fine spin on it.
Just trying not to panic, or engage in schadenfreude
And it is not only a display bug according to two of the posters to
that article. ( I can't test it myself without Excel 2007 and a Windows
OS)
If they'd read the article, they'd see they're wrong.
to quote one
A1 =850*77.1 --> 100000
B1 =A1+1 --> 100001 (realy a display bug???)
C1 =A1-1 --> 65534
D1 =B1-C1 --> 2
SInce A1+1 = 65536, and 65536 is one of the two values that produces the
display bug, it's hardly surprising that the display of A1+1 is also
faulty, but A1-1 isn't.
..the other pointed out that ROUND(A1) produces 100000 for real.
That *is* a calculation error if true.
Uh, no. Since ROUND(A1) produces (at the internal representation level)
the *same* result as A1 (i.e, 65535 or 65536), it says nothing about a
calculation error.
That is *very* sloppy work by MS. If ever there were a single edge
condition that had to regression tested at every release then 65336 ==
2^16 would have to be a top candidate.
I absolutely agree that it's sloppy. But I don't necessarily agree it
would be a top candidate for thorough checking.
First of all, as far as the calculation is concerned, it can't have
anything to do with 2-byte boundaries - all of XL's numeric values
(including integers) are stored in IEEE double-precision floating point
representation, which means 64-bit values, not 16. And while the Pentium
bug is still relatively fresh memory, no subsequent FPU has had a
problem with 64-bit math.
So there's no *inherent* "edge" at 2-bytes when it comes to converting
those 64-bit numbers to ASCII decimal representations.
That said, MS obviously *created* an edge in its internal rounding
routines, though I can't even begin to think of why or how.
Again, trying to look at it objectively, and based on what's been
released, it's a really limited bug that will likely be forgotten in a
month or two.
