Jump to content

Почему в таблице nanoCAD round(1.005;2) = 1,00 ?


Recommended Posts

Вопрос в заголовке. Кто-нибудь сможет объяснить?

nanoCAD 21.0.5803.3451 сборка 5857

=round(2.005;2) = 2,01

=round(3.005;2) = 3,01

в EXCELL, например, =округл(1,005;2) = 1,01

что за прикол?

  • Like 2
Link to comment
Share on other sites

6 минут назад, Artem_R сказал:

а что не так? )

во всех трех случаях правильное округление до второго знака после запятой.

1,00 ; 2,01; 3,01 правильное по каким "правилам"?

Link to comment
Share on other sites

1 минуту назад, XPom сказал:

1,00 ; 2,01; 3,01 правильное по каким "правилам"?

Вот по этим:

Цитата

 

Округление к ближайшему целому

Округление к ближайшему целому — наиболее часто используемое округление, при котором число округляется до целого, модуль разности с которым у этого числа минимален. В общем случае, когда число в десятичной системе округляют до N-го знака, правило может быть сформулировано следующим образом:

    если N+1 знак < 5, то N-й знак сохраняют, а N+1 и все последующие обнуляют;
    если N+1 знак >= 5, то N-й знак увеличивают на единицу, а N+1 и все последующие обнуляют;

https://ru.wikipedia.org/wiki/Округление

 

 

А Вы по каким округляете?

добавлено через 5 минут

Сорри. Только сейчас понял, что это три правильных примера противопоставленные неправильному в заголовке.

Link to comment
Share on other sites

25 минут назад, XPom сказал:

Вопрос в заголовке.

Похоже действительно ошибка. Причем воспроизводится только для единицы и для второго разряда. Спасибо, разберемся.

  • Like 2
Link to comment
Share on other sites

1 час назад, Artem_R сказал:

Причем воспроизводится только для единицы и для второго разряда.

Замысловатая картинка получается.

 

Подготовил примерчик (в аттаче).

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

Отмечу, что по правилам математического округления (наиболее распространенный случай) округление 0,5 должно быть вверх.

 

 

Спойлер

image.thumb.png.7a3e40a5c262bc741a50a1f89065733a.png

 

 

Что занятно, лисповская функция  (rtos тоже жжет!

 

Протестировал простенький скрипт с округлением последовательности чисел. 

Спойлер

image.png.50ed752117a1cb08b973a93952f74424.png

Первые два числа округляются вверх, остальные - вниз

 

 

 И в обратном порядке

Спойлер

image.png.80bedc39f34f87adef3567529899febf.png

Первое  число округляется вниз, остальные - вверх

 

 

И вишенка на торте

Спойлер

image.thumb.png.4d492249fdf09bcd86fcf005ac93ea2e.png

Наблюдаем некоторое расхождение с лисповским результатом (опять же, система неуловима).

Но так же видим, что в правой таблице ВСЕ значения округлились вверх, а в левой - в разнобой.

Отмечу, что значение аргумента формировалось автоматически, как Ai=Ai-1 + 0.01 для таблицы слева и Ai=Ai-1 - 0.01 - для таблицы слева.

Единственным объяснением такого обескураживающего результата может быть то, что операции с плавающей точкой тоже выполняются с некоей погрешностью машинной сетки и далее с непредсказуемыми результатами. Вот только пользователя такое объяснение вряд ли удовлетворит.

 

Действительно, косяк присутствует. Причем, как в части необъяснимости примененного метода (когда есть явные функции округления вниз, вверх и как-бы до ближайшего), так и в одинаковости  результата для аргумента, полученного разными методами, но одинакового в конечном виде.

Особенности округления.dwg

Edited by EdwardSt
  • Like 4
Link to comment
Share on other sites

  • 2 weeks later...
16 часов назад, XPom сказал:

исправлено в Платформа

В чистую платформу исправление не попало, а вот в спдс/мех этой сборки да

Link to comment
Share on other sites

39 минут назад, NYO сказал:

В чистую платформу исправление не попало, а вот в спдс/мех этой сборки да

Странно. Я думал таблицы - это Платформа. А проверял на СПДС, да

 

Link to comment
Share on other sites

1 час назад, NYO сказал:

В чистую платформу исправление не попало, а вот в спдс/мех этой сборки да

Странная ситуация...

Вроде бы функционал таблиц относится к платформе...

 

Попутно обнаружил, что при починке функции в таблицах "сломали" функцию (rtos

Выше приводился скрин 

В 23.05.2022 в 12:13, EdwardSt сказал:

Протестировал простенький скрипт с округлением последовательности чисел. 

  Последовательность 4.235+0.01*N, N=0...39 (Показать контент)

image.png.50ed752117a1cb08b973a93952f74424.png

 

Для примера выбраны 2 значения:

   4.305 округлилось к "4.30" (неправильно, но показаны значащие нули в конце)

   4.405 округлилось к "4.41" (правильно)

 

В обновленном СПДС

Спойлер

image.png.dd477ab02988a00979c38d6f04b59b38.png

округление 4.305 по-прежнему выполняется неверно, но до кучи еще и не выводятся значащие нули.

Необходимо отметить, что у конкурента тоже не все в порядке. Так,  в АС14 тоже удаляются значащие нули, но  округление происходит верно.

А в справке к AC19 наблюдаем, что значащие нули должны отображаться.

Спойлер

image.png.178aa7ea9e1dc5ce4114f6b86bd19c39.png

 

В общем, налицо корявое исправление: исправили для таблиц только в спец-расширениях (СПДС, Механика), забыв исправить это в функции (rtos, и попутно разучив эту функцию корректно форматировать результат округления.

 

  • Like 2
Link to comment
Share on other sites

 

В 07.06.2022 в 15:50, EdwardSt сказал:

Так,  в АС14 тоже удаляются значащие нули, но  округление происходит верно.

Спойлер

rtos.png

 

В 07.06.2022 в 15:50, EdwardSt сказал:

но до кучи еще и не выводятся значащие нули

нужно поменять значение DIMZIN 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

44 минуты назад, NYO сказал:
В 07.06.2022 в 12:50, EdwardSt сказал:

но до кучи еще и не выводятся значащие нули

нужно поменять значение DIMZIN 

Супер! С этим разобрались. Огромное спасибо.

Странно только, что в стандартном новом файле "Без имени0.dwg" по умолчанию

Спойлер

image.png.267925df37eb1178ae7a54bbe3d60d94.png

Но это, понятно., - не проблема.

 

 

Link to comment
Share on other sites

8 минут назад, EdwardSt сказал:

Странно только, что в стандартном новом файле "Без имени0.dwg" по умолчанию

Цитата

Начальное значение:0 (британские единицы) или 8 (метрические единицы)

 

добавлено через 3 минут
Спойлер

image.png.72e772c08ecd56ad6b373c238f18f738.png

млин.. гении "интуитивно понятного" интерфейса biglol.gif.8c34acc0ac43fc1add33f1c990f13f32.gif

Edited by doctorraz
  • Haha 1
Link to comment
Share on other sites

4 минуты назад, doctorraz сказал:

Начальное значение:0 (британские единицы) или 8 (метрические единицы)

Это про что? Откуда цитата?

 

Link to comment
Share on other sites

4 минуты назад, doctorraz сказал:
5 минут назад, EdwardSt сказал:

Откуда цитата?

из оригинала

Сколько нового узнаешь...

Причем тут метрическая или британская система?

Очевидно же , что это битовая маска. Первые два бита регулируют нули в британской системе, а 3,4 биты - в метрической.

Причем, эти биты могут быть установлены независимо друг от друга.

 

 


Link to comment
Share on other sites

14 минут назад, EdwardSt сказал:

Причем тут метрическая или британская система?

это не я donno.gif.8f90395323aa23a6541f28d480f9beb9.gif

у автостола можно поинтересоваться

  • Like 2
Link to comment
Share on other sites

  • 5 months later...
В 07.06.2022 в 14:14, XPom сказал:
В 07.06.2022 в 13:38, NYO сказал:

В чистую платформу исправление не попало, а вот в спдс/мех этой сборки да

Странно. Я думал таблицы - это Платформа. А проверял на СПДС, да

Исправление в платформе будет доступно в новой версии.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Tell a friend

    Love Официальный форум компании Нанософт Разработка? Tell a friend!
×
×
  • Create New...