API КОМПАС пробивает очередное дно

Автор Lemieux, 06.01.25, 00:11:48

« назад - далее »

0 Пользователи и 4 гостей просматривают эту тему.

Lemieux

Это просто жесть. Вот такого я не ожидал от КОМПАС  :-)))  :bebebe: :fly:
Это просто днище. Смотрим скрины.
Очередное днище API.png
Очередное днище API 2.png

Где там Голованев Валерий Александрович? Как прокомментируете это УГ? Когда писали свой ВиМП норм было?

Будь я начальником этого шалмана, в кабинете клавы и мышки летали за такое УГ. Меня злость переполняет. И это убожество пытаются ещё защищать. Позор. Что-то мне подсказывает, что как раз в АСКОН работают Полесовы.

UU

Да, это днище началось, когда Компас стал 64-разрядным, когда ты знаешь, что размер 45, а он на 0,00000000000000000001 отличается от 45.
Думаю куча глюков из-за этого мусора.

Toptotal

 :w: хорошо что я предвидел это и слез с Компаса и перелез сначала на т-флекс, поплевался и проблевался и полез на Солид.. чему рад и кайф испытываю..от старого 2014, тогда индусов еще так массово не загоняли кодить..
Ну программеры рассказывали как стали массово передаваться индусам все , начились такие проблемы во многих вещах и софте западном.
Аскон походу тоже решил экономить.. может студентов привлекать.

Lemieux

Я поражаюсь. В телеге все плечом к плечу встали защищая разработчиков АСКОН  :laugh:
Да какая разница направлен вектор строго вверх 0,0,1 или чуть под углом 0,0,0.999999999999567. Ну потерялись где-то данные, какая разница. А потом пользователи ловят глюки при работе с КОМПАС.
Люди даже не понимают, что работая с такими данными ошибка будет накапливаться в геометрической прогрессии. И если сделать десяток векторных преобразований и вот мы уже имеем не 1, а 0.99.
Я теперь понимаю почему иногда, две детали якобы выровнены строго по осям координат, а вставляешь их в сборку, начинает накладывать сопряжения, а какая-либо деталь может провернуться на небольшой градус.

Vi2

Цитата: Lemieux от 06.01.25, 10:41:43Да какая разница направлен вектор строго вверх 0,0,1 или чуть под углом 0,0,0.999999999999567. Ну потерялись где-то данные, какая разница. А потом пользователи ловят глюки при работе с КОМПАС.
Люди даже не понимают, что работая с такими данными ошибка будет накапливаться в геометрической прогрессии. И если сделать десяток векторных преобразований и вот мы уже имеем не 1, а 0.99.
Я теперь понимаю почему иногда, две детали якобы выровнены строго по осям координат, а вставляешь их в сборку, начинает накладывать сопряжения, а какая-либо деталь может провернуться на небольшой градус.
Все и так понимают, что, работая с плавающей точкой, нельзя сравнивать на точное соответствие, - всегда проверяется отклонение по модулю.

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

Lemieux

Цитата: Vi2 от 06.01.25, 12:15:51Все и так понимают, что, работая с плавающей точкой, нельзя сравнивать на точное соответствие, - всегда проверяется отклонение по модулю.

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

Как я понимаю, Вы не смотрели мой скрин или даже не поняли о чём тема. Конечно не где накапливаться ошибке.  :laugh: Я теперь понимаю почему КОМПАС и приложения к нему такие убогие. Отклонение по модулю относительно осей МКС. Это звучит как оксюморон.  :-)))

СВ

(А что, братва, может быть случиться чудо и простой Ростовский парень перевернёт российскую КАД-индустрию, как, к примеру, известный Хосе́п Мари́я Гвардио́ла-и-Са́ла изменил футбол?)

Toptotal

Удивляет что со стороны парень это показал , а где были разработчики Компас и где их тесты и проверка?? Или и так сойдет, работает же че проверять :)

Lemieux

Цитата: СВ от 06.01.25, 14:39:15(А что, братва, может быть случиться чудо и простой Ростовский парень перевернёт российскую КАД-индустрию, как, к примеру, известный Хосе́п Мари́я Гвардио́ла-и-Са́ла изменил футбол?)
Я ничего не пытаюсь перевернуть, я лишь обращаю внимание на основополагающие вещи. Понимаете в чём прикол. Берётся 3D движок, DirectX, OpenGL, Vulkan, сначала настраивается на вывод графики, а потом уже в него засылаются данные. Львиная доля этих данных это просто информация о вершинах объекта, а уже из них формируются рёбра, грани. Большинство операций это с векторами и матрицами. Это если упрощённо, а то сейчас набегут отцы и начнут лечить про отклонение по модулю. И я с Рассказово, а работаю в Ростове. Кстати, да, играю в футбол.

ja49619

МОДЕРАТОР, не хочешь подбанить этих всем и всегда недовольных нытиков, которые 2 слова не могут сформулировать в четкую мысль?

UU

Цитата: ja49619 от 06.01.25, 18:56:42МОДЕРАТОР, не хочешь подбанить этих всем и всегда недовольных нытиков, которые 2 слова не могут сформулировать в четкую мысль?
Огласите пожалуйста, весь список.

Vi2

Цитата: Lemieux от 06.01.25, 13:24:54Как я понимаю, Вы не смотрели мой скрин или даже не поняли о чём тема. Конечно не где накапливаться ошибке.  :laugh: Я теперь понимаю почему КОМПАС и приложения к нему такие убогие. Отклонение по модулю относительно осей МКС. Это звучит как оксюморон.  :-)))
Для тебя же было важно это значение, раз ты его вывел. Так вот чтобы с чем-то сравнивать, нужно брать отклонение по модулю. Если будешь выводить, то будет чёткая 1, потому что там есть округление. Так в чём твоя проблема?

Я в отладчике часть вижу такие величины. Причём все операции с плавающей точкой изначально неточные. Например, (1.0/3.0)*3.0 != 1.0. Ошибка будет, в зависимости от разрядности, в большой разрядности. И это не является проблемой.

А вот когда система начнёт подгонять под красивые числа, то вот там начнётся ахинея.
+ Благодарностей: 1

Lemieux

Цитата: Vi2 от 06.01.25, 21:35:59Для тебя же было важно это значение, раз ты его вывел. Так вот чтобы с чем-то сравнивать, нужно брать отклонение по модулю. Если будешь выводить, то будет чёткая 1, потому что там есть округление. Так в чём твоя проблема?

Я в отладчике часть вижу такие величины. Причём все операции с плавающей точкой изначально неточные. Например, (1.0/3.0)*3.0 != 1.0. Ошибка будет, в зависимости от разрядности, в большой разрядности. И это не является проблемой.

А вот когда система начнёт подгонять под красивые числа, то вот там начнётся ахинея.
Есть глобальная система координат, на ней есть ось Z, 0,0,1. Если я сопрягаю с этой осью любой доступный объект, который возвращает вектор, то я жду у этого объекта такое же значение 0,0,1, а не 0,0,0.99999999999956. Допустим я получаю два вектора и пытаюсь их проверить на коллинерность. Один вектор не заглючил и 1, а другой заглючил и имеет значение 0.999999999956. И что я получу? А если такое же проводить при определении нормали? Мне что каждое значение отслеживать и округлять его? А Вы знаете какие накладные расходы накладывает округление?

Цитата: Vi2 от 06.01.25, 21:35:59А вот когда система начнёт подгонять под красивые числа, то вот там начнётся ахинея.
Цитата: Vi2 от 06.01.25, 12:15:51Все и так понимают, что, работая с плавающей точкой, нельзя сравнивать на точное соответствие, - всегда проверяется отклонение по модулю.
Вы уж определитесь, надо подгонять или не надо. Вы же не лох.

IgorT

А по каким причинам нельзя округление применять? Когда это единственный способ добиться работоспособного кода. Весьма часто встречался с подобным.
Компьютер ведь не человек! Иногда бывает подобное в вычислениях. Наша задача их отловить и поправить.

Lemieux

Цитата: IgorT от 06.01.25, 22:18:06Когда это единственный способ добиться работоспособного кода
Тут ещё надо определить, единственный это способ или нет.

Цитата: IgorT от 06.01.25, 22:18:06А по каким причинам нельзя округление применять?
Это накладные расходы. Представьте Вам нужно прочитать сборку, в которой 10к деталей, в каждой по 25 вершин, в среднем. И вот тут мы начинаем вычислять рёбра, грани, нормали граней, нормали вершин, нормали кривых. Представьте несколько миллионов операций и мы везде будем округлять.

IgorT

Цитата: Lemieux от 06.01.25, 22:25:46Тут ещё надо определить, единственный это способ или нет.
Это накладные расходы. Представьте Вам нужно прочитать сборку, в которой 10к деталей, в каждой по 25 вершин, в среднем. И вот тут мы начинаем вычислять рёбра, грани, нормали граней, нормали вершин, нормали кривых. Представьте несколько миллионов операций и мы везде будем округлять.
Ну если найдется более совершенный способ, то это здорово! А если нет, то да, придется миллионы операций делать. Но это сработает.

Vi2

Цитата: Lemieux от 06.01.25, 21:57:46Есть глобальная система координат, на ней есть ось Z, 0,0,1. Если я сопрягаю с этой осью любой доступный объект, который возвращает вектор, то я жду у этого объекта такое же значение 0,0,1, а не 0,0,0.99999999999956. Допустим я получаю два вектора и пытаюсь их проверить на коллинерность. Один вектор не заглючил и 1, а другой заглючил и имеет значение 0.999999999956. И что я получу? А если такое же проводить при определении нормали? Мне что каждое значение отслеживать и округлять его? А Вы знаете какие накладные расходы накладывает округление?
Я же говорю, сравнивается отклонение. Наверное, коллинеарность векторов учитывает погрешность. И не нужно округлять.

Не можете привести свой код определения коллинеарности? Ну чтобы оценить Ваши скиллы в этом.

IgorT

Цитата: Vi2 от 06.01.25, 22:42:14Я же говорю, сравнивается отклонение. Наверное, коллинеарность векторов учитывает погрешность. И не нужно округлять.

Не можете привести свой код определения коллинеарности? Ну чтобы оценить Ваши скиллы в этом.
Может быть надо помнить не только об этом частном случае? Такое может быть и в других ситуациях. Округление универсально. Бывало такое.

Vi2

Цитата: IgorT от 06.01.25, 22:58:28Может быть надо помнить не только об этом частном случае? Такое может быть и в других ситуациях. Округление универсально. Бывало такое.
Коллинеарность векторов проверяется не только по ортам абсолютной СК. Так что неизвестно куда округлять, например, под углом 45 градусов.

IgorT

Цитата: Vi2 от 06.01.25, 23:18:51Коллинеарность векторов проверяется не только по ортам абсолютной СК. Так что неизвестно куда округлять, например, под углом 45 градусов.
Так ведь до целого же. 44,999999 и 45.0000000000000000001 должно быть принято как 45. Разве не так?