eto@spacely.Jpl.Nasa.Gov (Edward Olsen) (09/14/88)
This is a repost. I did not see it on comp.sys.mac the first time I sent it and thus repost it. Sorry if it made it the first time after all. I have discovered what I classify as a bug in Microsoft Excel running on a Mac II. I am using Excel v1.5 and running sensitivity calculations in dBm. Thus I must take the natural logarithm of some very small numbers. I find that if I take LOG10(2.7E-20) that I come up with a #NUM! error, whereas LOG10(2.8E-20) computes fine. The break point occurs at LOG10(2.7105054312138E-20) If your number is a tiny bit smaller (change the 8 to a 7 just before the exponent), #NUM! pops up. Note that this is not a precision problem, for I am not asking for a lot of significant digits. I should be able to take LOG10(1.0E-99) if I need to! What is up here? Of course, if you run this test on a Mac Plus (no coproessor, just the SANE package) you do not get #NUM!, just a bad precision number. I called this in to the Microsoft technical assistance and found it was an absolute surprise to them. Ed Olsen /******************************************************************* * Edward Olsen ARPA: eto@spacely.jpl.nasa.gov * * Mail Stop: 169-506 UUCP: ...!cit-vax!spacely!eto * * Jet Propulsion Laboratory SPAN: jplrag::olsen * * 4800 Oak Grove Drive * * Pasadena, CA 91109 * * * * Phone: FTS: 792-7604 Commercial: (818) 354-7604 * *******************************************************************/
jurjen@cwi.nl (Jurjen N.E. Bos) (09/15/88)
In article <9367@elroy.Jpl.Nasa.Gov> eto@spacely.Jpl.Nasa.Gov (Edward Olsen) writes: >I find that if I take LOG10(2.7E-20) that I come up with a #NUM! error, >whereas LOG10(2.8E-20) computes fine. The break point occurs at > LOG10(2.7105054312138E-20) It might be interesting to point out that this number is exactly 2^-65. -- -- Jurjen N.E. Bos (jurjen@cwi.nl)