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