Официальный форум российского программного комплекса T-FLEX PLM


Поиск  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Вопросы начинающего, вопросы от тех, кто только начинает своё знакомство с T-FLEX CAD
 
Вопросы о T-FLEX CAD от тех, кто начинает своё знакомство с T-FLEX CAD.
-------------------------
Новичкам рекомендуем ознакомиться с Учебным Пособием по T-FLEX CAD:
Онлайн: https://www.tflexcad.ru/help/tutorial/17/
Оффлайн: https://www.tflexcad.ru/download/tutorial/
Страницы: Пред. 1 ... 163 164 165 166 167 168 ... 419 След.
Ответы
 
Цитата
Денис Пользователь написал:
Vite , вы написали "double abs_b = abs(12.0-9.2);" где 12-9,2= 2,8 . или я что-то пропустил?
Очепятка, можете сами проверить)
 
Проверил операторы сравнения. Корректно работают только если в качестве операндов используются константы. Если операнды вычисляемые - работают как бог на душу положит. Интересно, разработчики в курсе? Все таки уже 15-ая версия на подходе и проверять работу базовых функций и операторов как-то несерьезно...
Учебная 15.0.10 Win7/64bit
 
Цитата
Talester написал:
Интересно, разработчики в курсе? Все таки уже 15-ая версия на подходе и проверять работу базовых функций и операторов как-то несерьезно...
Теперь в курсе я думаю)
 
Цитата
ВладиславКМВ написал:
Можно ли сделать эту операцию каким=либо абсолютным способом, что бы результат операции не зависел от размеров исходных и целевых кривых (т.к. эта фрезеровка параметрическая, универсальная для всех типов и размеров фасадов)? И без дополнительных вычислений для синхронизации кривых.
Ладно, добавил простую формулу, уравнял длины, всё наладилось. Но вылезла следующая проблема.
Для фрезеровки как фрагмента в статусе установлено правило "Автоматически создавать булевую операцию" (см.скр.1). Однако, при вставке в сборку на гнутом фасаде не создаёт (скр.2) Причём булевая не исправляется даже ручным способом. На плоском фасаде это правило работает нормально. Почему на гнутом не работает? Пример в приложении.
Скрытый текст
Успех это способность идти от одной неудачи к другой без потери энтузиазма.
(У.Черчиль)
 
Цитата
Денис Пользователь написал:
Vite, вы написали "double abs_b = abs(12.0-9.2);" где 12-9,2=2,8. или я что-то пропустил?
Результат аналогичный.
T-FLEX CAD 17.1.6.0
 
Я тут накидал, и заметил что при суммировании все нормально (см рисунок). .... в 12 версии так же :shock: .... так что косяк из далека. :shock:
:shock:
logig.png (24.16 КБ)
Изменено: Денис Пользователь - 16.02.2016 23:01:04
 
Это снова я и снова с оператором сравнения. Еще одна интересная фишка.
На рис.1 две группы с почти одинаковым набором переменных, отличие в следующем: 1)слегка отличаются названия переменных 2)при вычислении L_DeltaY_Critical и xL_DeltaY_Critical используются разные цифры, но результат при этом одинаковый. Заметьте, какой здесь разный результат получается при вычислении NoVis_Shift и хNoVis_Shift, хотя он, по логике, должен быть, не важно правильный или нет, но обязательно ОДИНАКОВЫЙ. NoVis_Shift вычислился неправильно (=1), хNoVis_Shift - правильно (=0).
На рис.2 показано, что если в вычисление xL_DeltaY_Critical подставить те же цифры, что и в вычислении L_DeltaY_Critical, то NoVis_Shift и хNoVis_Shift вычисляются теперь одинаково, но неправильно.
На рис.3 меняем комбинацию цифр в вычисление и, вуаля, результат сравнения снова правильный.
Вот некоторые комбинации для вычисления L_DeltaY_Critical и xL_DeltaY_Critical, которые дают в операции сравнения правильный ответ : 12.3-10.1, 4.4-2.2, 11.9-9.7, и неправильный: 2.3-0.1, 12-9.8, 12.2-10. Другие комбинации не искал и остальные операторы не проверял, веселья и так хватило. Получается, результат операции сравнения зависит от конкретных цифр, которые использовались при вычислении его операнда, а не только от его значения. Бред какой-то. Может кто проверит у себя этот пример, он вроде небольшой. Может быть у меня в компе что-то не так или уже в отпуск пора.
Рис 1.png (8.22 КБ)
Рис 2.png (7.71 КБ)
Рис 3.png (6.78 КБ)
Учебная 15.0.10 Win7/64bit
 

думается дело в машинной точности вещественных чисел. Ваш вариант построения уравнения на скрине. Обратить внимание, что уравнение "в" записано в одну общую строчку со всеми сравнениями.
Изменено: SaprOnOff86 - 17.02.2016 15:27:38
 
Может применение функции округления до заданной точности решит проблему?
 
Talester, видимо в ТФ проблемы с математикой. :shock: :cry: :( :idontnow: :[
logig1.png (9.7 КБ)
 
В некоторых случаях при изменении количества нолей в умножаемом числе изменяется и дробная часть в хвостике. Получается если 2,2>2,2 значит так оно и есть .... В общем нашли проблему, а как ее будут решать ? да и вообще как такое может быть???!!! Что нада прописать что-бы 12-9,8=2,199999999991 а не 2,2!
logig2.png (9.55 КБ)
 
Цитата
Денис Пользователь написал:
В некоторых случаях при изменении количества нолей в умножаемом числе изменяется и дробная часть в хвостике. Получается если 2,2>2,2 значит так оно и есть .... В общем нашли проблему, а как ее будут решать ? да и вообще как такое может быть???!!! Что нада прописать что-бы 12-9,8=2,199999999991 а не 2,2!
Я думаю этот касяк из той же оперы, когда масса при плотности 0 равнялась не 0, когда коннекторы на отверстиях были не чётко на поверхности, а +0.0000001.... Ничего удивительного я уже не нахожу в данной ситуации.
 
Цитата
Sila Musli написал:
Ничего удивительного я уже не нахожу в данной ситуации.
А я вот нахожу удивительное: при 100500 официальных пользователях - или никто на подобные косяки не нарывался (что еще более удивительно) - или кто-то на их исправление забил болт (в принципе, объясняет ситуацию)
Счаз начнется про " ...в 15 версии всё будет! " )))
Практика - критерий истины (с)
 
Видимо, все исходные данные приводятся к плавающей точке, вычисления тоже производятся, приводятся и хранятся во FLOAT. А то что мы видим на экране это результат некого округления, а не реально хранящегося значение.Подобная стратегия применяется и в MS EXCEL, что часто приводит к непоняткам, особенно среди неопытных юзеров. Но там можно принудительно установить точность вычисления после запятой, а самое главное есть замечательная кнопка "Точность как на экране", которая сразу все расставляет по местам. Если я, к примеру, использую TF для 3D-печати, то точности 0.01 мне хватило бы выше крыши, а про эти проблемы я бы даже не догадывался.
Цитата
B_S_V написал:
Может применение функции округления до заданной точности решит проблему?
Наученный предыдущими приключениями решил сначала проверить работу функции округления, т.к. до этого не разу не использовал. Получилось не очень, см. рис. Из опыта программирования я ожидал, что должно быть, например ROUND(2.22,0) =2, ROUND(2.22,1) =2.2, ROUND(2.22,2) =2.22, ROUND(2.22,9) =2.22. Но полученные результаты ROUND я никак объяснить не могу. Кстати, замена B=12.02-9.8 на B=2.22 и прямая подстановка ROUND(2.22,3) не меняет результаты округления.
ROUND.png (10.51 КБ)
Учебная 15.0.10 Win7/64bit
 
Цитата
Talester написал:
Наученный предыдущими приключениями решил сначала проверить работу функции округления, т.к. до этого не разу не использовал. Получилось не очень, см. рис. Из опыта программирования я ожидал, что должно быть, например ROUND(2.22,0) =2, ROUND(2.22,1) =2.2, ROUND(2.22,2) =2.22, ROUND(2.22,9) =2.22. Но полученные результаты ROUND я никак объяснить не могу
смотри: round (число, кол-во_знаков_после_запятой)
т.е:
round(2.22, 2) = 2.22
round(2.22, 1) = 2.2
round(2.22, 0) = 2
Практика - критерий истины (с)
 
Цитата
awmalchuk написал:
Цитата
Talester написал:
Наученный предыдущими приключениями решил сначала проверить работу функции округления, т.к. до этого не разу не использовал. Получилось не очень, см. рис. Из опыта программирования я ожидал, что должно быть, например ROUND(2.22,0) =2, ROUND(2.22,1) =2.2, ROUND(2.22,2) =2.22, ROUND(2.22,9) =2.22. Но полученные результаты ROUND я никак объяснить не могу
смотри: round (число, кол-во_знаков_после_запятой)
т.е:
round(2.22, 2) = 2.22
round(2.22, 1) = 2.2
round(2.22, 0) = 2
А чем ваш ROUND отличается от приведенного в моем тесте? Это вы показали, как эта функция ДОЛЖНА работать, чего я тоже ждал, а я показал как она ДЕЙСТВИТЕЛЬНО у меня заработала (см. рисунок). Результаты даже близко не похожи.
Учебная 15.0.10 Win7/64bit
 
Вроде как всегда было так
Okr.jpg (53.99 КБ)
 
Цитата
B_S_V написал:
Вроде как всегда было так
Спасибище огромное! Так заработало. В справке нет примеров применения ROUND и я действовал по аналогии с другми языками программирования, а там вторым аргументом всегда указывается именно сколько нужно знаков после запятой, а не формат/множитель. Буду дальше терзать ТФ.
Риторический вопрос, а что же, интересно, ROUND показывал в моем тесте и как понять его результаты?
Изменено: Talester - 18.02.2016 10:57:22
Учебная 15.0.10 Win7/64bit
 
Полезная статья:
- Машинная арифметика и идиомы численного программирования
T-FLEX CAD 17.1.6.0
 
Цитата
Talester написал:
Риторический вопрос, а что же, интересно, ROUND показывал в моем тесте и как понять его результаты?
Трудно сказать, надо смотреть, как это устроено.
Кстати, ROUND работает и на округление до 10, 100, и т.д. Главное, чтобы округляемые числа соответствовали величине округления.
Страницы: Пред. 1 ... 163 164 165 166 167 168 ... 419 След.