Forum Discussion
Cell presented value differs from cell result value
Did you check this web page?
https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3
I tend to take it forgathered that MS-Excel is a stable, working software package. If I do find something strange I will not blame it first I will test the heck out of it, and after all is extenuated and after I have asked all my Excelers Friends THEN and ONLY then do I blame Excel.
To Err is Human, but MS-Excel does a good job 99.99% of the time.
If in fact you stumbled on an "issue" then I would suggest contacting Microsoft Office Support and let them know.
GeorgieAnne wrote: ``Did you check this web page?
https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-2...``What is your point?
JoeUser2004 sorry for the late reply.
I tend to agree with most of GeorgieAnne observations , and my procedure was similar, even to the point of calling out for fellow Excellers. My suspicions went more towards MacOS than anything else!
I tested your 1Exxx defect xls, on both an up to date Windows computer and my Macs and something maddening happened!
Both Macs maintained the error, as I expected. (see attached MAC Exxx.png)
However, the Windows machine, on loading the xls file, displayed, as the result of the TEXT($B$2$, ...) formula in cells B18 and B19, the wrong value 3.2878E-308 (formatted according to the formatting second parameter).
The moment you edit the formula or copy/paste it somewhere else, the correct value 1E-292 is displayed!
(see cell B18 of attached Win Exxx.png. No doctoring of underlying xls or png, scouts word! (wink) 🙂)
I liked your idea of displaying the difference between 1E-292 and 2.32E-308, that, due to the huge difference, should result in the larger value.
As you point out, the difference between 1e-292 and 1e-308 is in the 15th decimal place for normalized presentation. If I'm not wrong, excel's display engine is 128 bits, and the calculation engine is 64. Also, the other value (1e-163) lies at a similar place in the 32 bits realm. Could this be the culprit?
Anyway, I think this falls into the 0.01% issue, so I'll try to submit it to MSFT.
Thanks, and best regards!
PS....
jmsoeiro wrote: ``No doctoring of underlying xls or png, scouts word! (wink) ``
I believe you. But with your regional configuration, B19 does not appear as I intended.
The reason is: you need to change the TEXT format from "0.000" (period) to "0,000" (comma).
