Чудеса! Никогда бы не подумал. Павел, я думаю, что если ZVI увидит это - даст ответ.

--  
Спасибо, Павел и Юрий - с удовольствием отвечу.  
 
Павел, если посмотреть 14 десятичных разряда результата Вашей формулы, то увидим, что разницы между результатом формулы и копированием этого результата как числа нет.  
 
Вспомним, что числа в Excel и во многих других программных продуктах - это набор бинарных нулей и единиц.    
А в соответствии со спецификацией IEEE754 в десятичном представлении любого числа допускаются ошибки в 15-м значащем разряде.  
Подробнее об этом можно почитать здесь:  
http://support.microsoft.com/kb/78113  
 
В приложении я добавил пример более явной ошибки для случая, когда требовалось получить случайные число от 0.1 до 0.9 с обним десятичным разрядом.  
 
По справке, чтобы получить случайное число используется формула:  
Int((upperbound - lowerbound + 1) * Rnd + lowerbound)  
 
Мы ее просто разделим на 10 и даже округлим результат до одного десятичного разряда:  
Round( Int(9 * Rnd + 1) / 10, 1)  
 
Результат может удивить, так как, во-первых, дает не один десятичный разряд, а c мусором уже в 8-м десятичном разряде.  
Причина в том, что функция Int() дает результат с 32-битным типом Long.  
Корректнее нужно было явно задать 64-битный результат с типом Double, например, так:  
Dim x As Double  
x = Int(9 * Rnd + 1) / 10  
При этом получим то, что и ожидалось.  
 
Нюансов представления чисел и ошибок округления много.  
Например, малоизвестно, но факт: библиотека Excel при вычислениях формул пользуется не 64-битным, а 80-битным представлением, но результат все равно возвращает не более, чем в 64-битном представлении. Поэтому возможны расхождения в результатах вычислений по частям и одной формулой, а также отличия в вычислениях в Excel и в других 64-битных программах, впрочем, отличия как раз и будут в 15-м значащем разряде.  
 
Существуют библиотеки и даже Excel-надстройки для вычислений не с 15-ю значащими разрядами, а с 30-ю и более (в т.ч. более 1000 разрядов).    
Это интересная, но отдельная тема.  
Между прочим, обычный калькулятор Calc.Exe имеет в два раза больше десятичных разрядов, чем у Excel.  
Поэтому при вычисления одной и той же формулы его результаты могут отличаться от результов Excel.  
 
Удачных всем вычислений и округлений,  
---  
ZVI

Еще одна ошибка.  
Пост от 12.09.08 14.00 в теме  
http://www.planetaexcel.ru/forum.php?thread_id=5700  
Что ему (Excel) не нравится?

да, я с датами натыкАлся - при попытке поиска даты с точностью до секунды, оно говорит "фиг вам", приходилось задавать интервал в пару секунд..

{quote}{login=vikttur}{date=16.09.2008 02:15}{thema=}{post}Нашел.  
Дело не в датах, а в суммировании чисел столбца С. У автора вместо "2,8" в ячейки вбито "2,77777777777778", это и вызывает ошибку ВПР.{/post}{/quote}  
---  
С этим-то вроде все правильно, т.к. 2.8 при сложении не дают 25.    
Нонсенс в том, что если в ячейке с результатом суммы установить числовой формат и отобразить 15 или больше десятичных знаков, то все они отобразятся нулями, хотя для ВПР они нулями не кажутся.  
Вывод: если в клетке Excel слон, но написано "Лев" - не верь отображению.  
---  
ZVI