Форум » [x]Harbour » Волшебные числа и операции » Ответить
Волшебные числа и операции
AndreyZh: Доброе утро! Вот наткнулся на очередную ошибку xHarbour и Clipper. Думал, что глюк ОС или ПК, но нет. Пример ошибки - оператор "остаток от деления": 8.8 * 3 = 26.4 или 3.3 * 3 = 9.9, но операции (%) дают 26.4%8.8 = 8.8 или (НО правильно) 9.9%3.3 = 0 Вопрос - как Вы обходите данные глюки? Или где в "арифметике" ожидать очередных "засад"? До кучи напомню об ошибочной работе функции Int в Clipper (в xHarbour кажется работает правильно)
Dima: Pasha пишет: Достаточно конечную цифру, я так и делаю А если складывать вот так ? [pre2] X+= Base->KLV * Base->CENA , где KLV , "N" ,10,3 а CENA , "N" ,10,2 [/pre2]
Pasha: здесь конечно требуется промежуточное округление, иначе погрешность в случае дробного количества будет достигать до полкопейки
rvu: Я сейчас уже не помню, что у меня было, но были примеры где промежуточное округление и итоговое разные значения давали. Очевидно, что ошибка была не в 0,00....001, а большая и они накапливались.
Pasha: round(1/3+1/3+1/3, 2) --> 1.00 round(1/3, 2)+round(1/3, 2)+round(1/3, 2) --> 0.99
rvu: Все округления могут быть полезны, лучше все и делать.
Pasha: Я обычно обхожусь без округления Сделал такую функцию, для сравнения чисел с точностью до двух десятичных знаков: [pre] #include "hbapi.h" #include "math.h" HB_FUNC( EQU ) { double d1 = hb_parnd( 1 ); if( HB_ISNUM( 2 ) ) { double d2 = hb_parnd( 2 ); hb_retl( fabs( d1 - d2 ) < 0.005 ); } else hb_retl( fabs( d1 ) < 0.005 ); } [/pre] вместо nSum1 == nSum2 или подобное использую Equ(nSum1, nSum2)
Pasha: Если скинуть в Excel достаточно большой заполненный dbf-файл, порядка 10 тыс.записей, с числовым полем размерностью N,12, 2 и затем с произвольной строки помечать числовую колонку, то начиная примерно с пометки 1500-2000 строк обязательно возникает погрешность суммы (которую видно внизу Excel) в 8-м знаке в ту или другую сторону, та же микрокопейка Если продолжать помечать колонку дальше, то при пометке 3-4 тыс строк погрешность может аннигилироваться. Забавно Эффект лучше наблюдать в LibreOffice. Погрешность суммирования то появляется, то исчезает
rvu: Pasha пишет: использую Equ(nSum1, nSum2) А я вставил округление до копейки в функцию и где считал нужным писал valround(значение).
SergKis: rvu пишет где считал нужным писал valround(значение) Помогает исп. рабочих полей в dbf "N", 19, <все нужные варианты>, т.е через них расчеты. Т.к. клиент сам ставит варианты nDec для разных групп номенклатуры (2, 3, 4, 5, 7), то привязывал имя раб. поля к номенклатуре (picture тоже если надо), работает вариант со времен S87
Pasha: Просто крик души Сдаем отчет РСВ-1 в ФНС Получаем протокол: 0400400013-СНИЛС XXX-XXX-XXX XX ст.170 (2 м.) = 8873.77 Расчетная сумма = (ст.150 поп + ст.150 (1 мес. + 2 мес.)) * тариф - ст.170 поп - ст.170 (1 мес.) = 150678.66 * 30/100 - 36329.82=8873.79 разница = -.02 V не принимается. II. По основаниям, предусмотренным пунктом 7 статьи 431 Налогового кодекса Российской Федерации: 0400400011-Нарушено условие равенства значения суммы страховых взносов по плательщику страховых взносов совокупной сумме страховых взносов по застрахованным лицам конец протокола проверяю на калькуляторе: 150678.66 * 30/100 - 36329.82 = 8873.78 и там дальше 4 такие же ошибки ФНС, если кто не знает, это Федеральная Налоговая Служба Российской Федерации Риторический вопрос: как научить ФНС арифметике ?
полная версия страницы