ADN Club > Ошибки в AutoCAD и вертикальных приложениях
Некорректная работа функции trunc в атрибутах динамических блоков
Максим Маркевич:
--- Цитата: Александр Ривилис от 10-12-2016, 00:11:00 ---Ну что же. Увы, но это проблемы с точностью округления. Конечно это баг, но такой тонкий, что им вряд ли кто-то будет заниматься.
--- Конец цитаты ---
Если это баг, то почему он проявляется не всегда??
Иногда его удается "вылечить", заменив вхождение блока на такое же, только новое.
Делаю это при помощи самопального метода:
Извините, вам запрещён просмотр содержимого спойлеров.
--- Цитата: Александр Ривилис от 10-12-2016, 00:11:00 ---Так что или переходи на round
--- Конец цитаты ---
В предыдущем посте написал, что в "нездоровом блоке" с round происходит то же самое.
--- Цитата: Александр Ривилис от 10-12-2016, 00:11:00 ---или используй в формулах что-то такое: trunc((val1+fuzz)/val2) (например, fuzz = 1e-6)
--- Конец цитаты ---
:(
А вот еще кое-что интересное по этому поводу: у меня есть 2 одинаковых вхождения блока (блок здорового человека и блок курильщика) в разных документах, вот что происходит, если копировать один в другой:
Максим Маркевич:
--- Цитата: Александр Ривилис от 10-12-2016, 00:27:54 ---Ну и ещё для убедительности, что в таком виде использовать trunc нельзя ни в коем случае (!!!):
--- Конец цитаты ---
Ну так, я бы подстроился, если бы баг был статическим, а получается какой-то генератор случайного округления - иногда так срабатывает, иногда иначе, потом вдруг блок начинает работать как нужно, а через некоторое время снова шляпа (бывают даже случаи, когда ctrl+z решало данную проблему, то есть вот ставишь размер, обновляешь поле, баг, делаешь шаг назад, ставишь тот же размер - все ок :D - на самом деле, это не так и смешно >:().
Александр Ривилис:
1) Ты моё второе видео смотрел?
2) Ты понимаешь, что если trunc(4399.9999999999999/100) даёт 43, то тебе эта функция не годиться?
3) Там происходят различные арифметические операции над числами плавающей арифметики. Любые операции приводят к потере точности. Соответственно в реальности у тебя не 4400, а что-то около этого. И как результат потеря точности при операции trunc
Максим Маркевич:
--- Цитата: Александр Ривилис от 10-12-2016, 00:47:43 ---1) Ты моё второе видео смотрел?
--- Конец цитаты ---
Я все Ваши видео по два раза смотрю!
--- Цитата: Александр Ривилис от 10-12-2016, 00:47:43 ---2) Ты понимаешь, что если trunc(4399.9999999999999/100) даёт 43, то тебе эта функция не годиться?
--- Конец цитаты ---
А Вы понимаете, что с round то же самое?
А trunc и round - это все, что имеется!!
То есть мне ничего не годится, кроме костыля с 1e-6.
--- Цитата: Александр Ривилис от 10-12-2016, 00:47:43 ---3) Там происходят различные арифметические операции над числами плавающей арифметики. Любые операции приводят к потере точности. Соответственно в реальности у тебя не 4400, а что-то около этого. И как результат потеря точности при операции trunc
--- Конец цитаты ---
Вопрос из предыдущего поста, почему они происходят по-разному и случайно? Я не понимаю! Вы смотрели мое видео "Чудеса с функцией trunc"?
Александр Ривилис:
--- Цитата: Максим Маркевич от 10-12-2016, 00:43:35 ---Ну так, я бы подстроился, если бы баг был статическим, а получается какой-то генератор случайного округления
--- Конец цитаты ---
Прибавляй 1e-6 - всё будет нормально. И лучше даже так: trunc((val1/val2)+1e-6)
Навигация
Перейти к полной версии