Какъв е този гаден проблем с точността при чертане с Autocad 200, 2004, 2006!!!
Ако координатната система е завъртяна произволно (каквато и да е само не и световната), след офсет на линия на точно разстояние измервам разстоянието между двете линии и установявам че - в единия край (от крайна до крайна точка) разстоянието е точно (пр. 100.0000000) а като премеря от единия край до перпедикуляра на втората линия - 100.0000001 !!!! И от там - ако офсетна втората (нова) линия - започва едно натрупване на тази грешка и след "n" брой офсети или други действия - разликата става порядъчна (пр. 100.00000456). Установих че няма никакво значение каква "precision" е зададена в опциите за мерните единици.
Що за безумие е това и има ли начин да се избегне? (а ми се налага да чертая в други координатни системи)

Интересен проблем ! Прочетох го 5 пъти , но малко съм тъп и не можах да възпроизведа ситуацията ... ако може някаква картинка или направо файла !

Ами по думите на човека се оказва, че "Offset" не пренася обектите успоредно.

Съдържаниет е скрито
Влезте за да го видите

Именно! Когато си в някаква координатна система (не световна) не знам какво бърка и офсетнатите линии не са успоредни! Не всеки път, но доста често. Най-вече ако офсетваш полилинии. Но не знам дали проблемът е в офсета или в меренето - защото ако премеря между две крайни точки от end point до end point - Разстоянието е точно, а ако премеря от endpoint до perpendicular - вече не е!

Проблемът идва от синусите и косинусите. При трансформация на координатните системи, алгоритъмът, по който се прави изчислението е с една матрица, където участвуват синусите и косинусите - ако не се лъжа в документацията за ObjectARX-а беше обяснено и онагледено доста подробно. Всички компютри и калкулатори дават някаква незначителна грешка при изчисляването на трансцендентните функции, защото алгоритъма е такъв, но тази грешка в болшинството от случаите е незначителна и няма практическа стойност. Погледни и в твоя случай - дори и единиците, в които работиш да са метри - грешката, която получаваш е 0.1 микрона
Разбира се имаш възможност с написване на определени собствени програми да си повишиш точността ако е толкова критично
Най-вероятно алгоритъмът за намиране на перпендикуляр също да е по подобен начин и затова да получаваш два различни резултата - ендпоинт то ендпоинт и ендпоинт то перп.
Най- левашкият начин за да не натрупваш грешката е да офсетваш не последната линия, а винаги една и съща (първата).
А иначе за по-мързеливите (като мене )са направили и командата Array, дето няма нужда да се хабя като ненормален да чукам по линиите, ами просто задавам колко копия и на какво разстояние ми трябват

Да, има го този проблем с AutoCAD-а. При работа от команден ред не ми е правило впечатление, но някой от функциите на AutoLISP също връщат грешни стойности някъде след 5-6 знак. И това е проблем защото програмата гърми. Но там има начин този проблем да се заобиколи.
Ако ти пречи много, напиши по-подробно какво искаш да направиш. Може да се измисли нещо.

Ако това е вярно ми даваш страхотен отговор.
алгоритъма е такъв, но тази грешка в болшинството от случаите е незначителна и няма практическа стойност.
Има си здрава практическа стойност като откаже да ти педитира полиниите, че краищата им не се докосват заради отклонения по х илиу, макар и в десетия знак! Побърках се да използвам филет за такива случаи, добре, че в 2006 има опцията Multiple pedit и там можеш да зададеш толеранс, аджаба, тия линии ако крашщата им са два метра един от друг, докосват ли се или не?
Няма майтап, проблемът ми е драстичен ако започна проект върху геодезична основа - тегля си осите, после ги прехвърлям в някаква не завъртяна под 36.95867985 града кооридинатна система ... става мазало ... нищо не се педитира, накрая излиза по-лесно да си почнеш проекта отначало.
Досега си мислех, че моооже да идва от ползването на купчина оснап режими наведнъж, ама ти направо ме открехна! Полагайте си основата в координатната система, която ще е приоритетна!

Резултат от вида

69,99999999

отдавна не ме изненадва. Не знам средство за оправяне.

Веднъж констатирах случайно, че понякога има разлики и между различните версии. На 14 обемът на едно тяло беше различен спрямо обема на абсолютно същото тяло в 2002 и то даже в 6-ия знак.

Редактирано от ASSASSlN на 09.06.05 18:27.

a iskam da razbra kakto kakzvash geodezichna osnova znachi postoianno bachkash s niakvi razlichni mashtami i kak se spraviash s problema s shriftovete a imam na predvid kato premenavash ot edin mashab v DRUG vseki shrift poodelno li go opraviash ili si bachaksh s land-a

Това нещо го има решено доста отдавна в Autocad Map- имаше някаква функция, която при дигитализиране проверява дали краищата на отсечките попадат на някакво минимално разстояние една от друга - и ако да - ги прави да съвпадат. В чистия Autocad можш да си го направиш с една съвсем обикновена програмка на всеки от възможните езижи за програмиране - VC, VB, VisualLisp или Autolisp. Най- просто става с последните 2 - имаш функция equal, която сравнява две числа, като третия (незадължителен параметър е точността). Т.е. ако зададеш, че точността е 0.01 тази функция ще ти върне, че 2.00 и 2.01 примерно са равни. От тук нататъка трябва за точките да го приложиш три пъти за всичките координати и след това ако трябва да модифицираш крайните точки на линните - или втората точка я правиш да съвпада с първата, или първата отива във втората или преместваш и двете точки в точката посредата им- вече въпрос на избор


Сега за синуси, косинуси, тангенси и т.н. съм забравил какъв беше точно числения метод по който се изчисляват - но беше някакъв степенен ред на някой си - и от там идва загубата на точност.