|  13.10.2004, 09:47 | #1 | 
| Участник | Здравствуйте дети! :) 
			
			Продолжаем занятия! Добрые дяди из МБС задали вам очень интересную задачку! Попробуйте ее решить.... Только животики от смеха не надорвите! Создаем джоб PHP код: 
			Дружно смеемся. | 
|  | 
|  13.10.2004, 10:13 | #2 | 
| Участник | X++: static void Summ(Args _args) { real a = 9999.899999999999; real b = 9999.999999999999; ; print a; print b; print a + b; pause; } Вот так все отрабатывает   | 
|  | 
|  13.10.2004, 10:15 | #3 | 
| Участник | PHP код: 
			  | 
|  | 
|  13.10.2004, 10:25 | #4 | 
| Гость | 
			
			Все правильно, при печати число знаков после запятой ограниченно 2.  Это везде, в т.ч. в отчетах. Надо просто иметь это ввиду. Не понимаю эти совершенно необоснованные наезды на MBS в этом и предыдущем обсуждении. | 
|  | 
|  13.10.2004, 10:27 | #5 | 
| Участник | 
			
			прочтите, что нужно иметь в виду? что почти 10000 + почти 10000 = равно почти 10000? однако дешевенькая 1с считает это правильно.
		 | 
|  | 
|  13.10.2004, 10:41 | #6 | 
| Участник | 
			
			Вот это да! Теория относительности налицо :-)
		 | 
|  | 
|  13.10.2004, 10:41 | #7 | 
| Участник | Цитата: 
		
			Изначально опубликовано monk  меняю 9 на 8 Вот так все отрабатывает   а можно еще и одну девяточку убрать. Дело в переполнении. где-то неверно обрабатыватся точность округления.... на самом деле эта бага идет и при других сочетаниях.... 999.9999999999999 99.99999999999999 9.999999999999999 0.9999999999999999 другие не проверял... было бы еще более смешно, если бы еще и другие сочетания сваливались в баг.... | 
|  | 
|  13.10.2004, 10:42 | #8 | 
| Участник | 
			
			При чем здесь печать static void Summ(Args _args) { real a = 9999.999999999999; real b = 9999.999999999999; real c; ; print a; print b; c = a + b; print c; pause; } с = 10000 | 
|  | 
|  13.10.2004, 10:42 | #9 | 
| Участник | 
			
			А по-моему, это просто пасхальное яйцо (типа "=rand(200,99)" в Word ). Так как любое изменение в количестве девяток приводит к нормальной работе job'а. Интересно, как нашли такое сочетание?    | 
|  | 
|  13.10.2004, 10:47 | #10 | 
| Модератор | 
			
			Системная бага. Связана с тем, что Вы пытаетесь скормить системе 16 и более значащих цифр одновременно.  1) Зачем Вам такая точность? Хотя, финансовой системе она как раз-то не помешает...  2) Печально... бага-то налицо, и тяжкая... С Уважением, Георгий. | 
|  | 
|  13.10.2004, 10:48 | #11 | 
| Участник | 
			
			Т.е. кол-во 9-ток должно быть равно 16. Тогда баг есть.
		 | 
|  | 
|  13.10.2004, 10:54 | #12 | 
| Участник | Цитата: 
		
			Системная бага. Связана с тем, что Вы пытаетесь скормить системе 16 и более значащих цифр одновременно.
		
	   | 
|  | 
|  13.10.2004, 11:05 | #13 | 
| Модератор | 
			
			Посмотрите вот сюда: http://www.axforum.info/forums/showt...&highlight=256 Думаю, что эти проблемы схожи и связаны с отвратительной реализацией математики. Неужели нельзя было как следует оттестировать? Финансы, как-никак... С Уважением, Георгий. | 
|  | 
|  13.10.2004, 11:15 | #14 | 
| Участник | 
			
			Мне  как-то не до смеха. Вопрос как обойти эту багу ... Ведь при любых безобидных вычислениях есть вероятность нарваться. | 
|  | 
|  13.10.2004, 12:06 | #15 | 
| Участник | 
			
			...
		 | 
|  | 
|  13.10.2004, 12:29 | #16 | 
| экс-модератор | 
			
			самое страшное, уважаемые коллеги, что для повторения эффекта вовсе не нужны дикие нагромождения девяток, редко встречающиеся в практике учета. PHP код: 
			и, протестируйте, пожалуйста, кто-нибудь на 2.5 и ранних сп 3.0, у меня такое ощущение, что глюк свежий, не мог такой ужас жить несколько лет незамеченным   | 
|  | 
|  13.10.2004, 12:36 | #17 | 
| Участник | 
			
			Хм... Так в вашем примере как раз девятки и получаются после /3, *3
		 | 
|  | 
|  13.10.2004, 12:52 | #18 | 
| Участник | 
			
			Так в том то и проблема, что получить эти девятки не так уж сложно в процессе вычислений. Т.е. это не какой-то совсем уж экзотический случай.
		 | 
|  | 
|  13.10.2004, 12:56 | #19 | 
| экс-модератор | 
			
			понятное дело. это я пытался приблизить этот глюк к реальной практике. кстати, после замены real на amountMST глюк остается, что, впрочем, логично. | 
|  | 
|  13.10.2004, 13:05 | #20 | 
| Модератор | 
			
			Более того! Если произвести данные вычисления напосредственно в форме (Например, Цена в Заказе) 1000/3*3 + 1000/3*3, то будет то же самое. А вот если второе слагаемое будет отлично от первого, (хотя пусть и будет давать бесконечную дробь), то глюк вроде как не замечен... С Уважением, Георгий. Странно, неужели это выяснилось впервые за столько лет? | 
|  | 
| Теги | 
| баг, математика, округление | 
|  | 
|  Похожие темы | ||||
| Тема | Ответов | |||
| Абстрактный классификатор | 52 | |||
| Здравствуйте дети! :) - еще одна ошибка | 11 | |||
| Просмотр SQL запросов к БД с помощью файла Log | 3 | |||
| Виртуальные поля | 6 | |||
| 
 |