Programming Challenge 11/22
Regards @_gile
Here my attempt of demonstration by inequations of its logical deduction.
;Premise:r1>r2
;Option 1: r1-r2>r1+r2 -> r2<0, FALSE
;Option 2: r1-r2<r1+r2 -> r2>0 -> TRUE
;If r1>r2 and r2>0 -> r1+r2>r1-r2 (Gile Conclusion)
Carlos Calderon G
>Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
@calderg1000 a écrit :
Regards @_gile
Here my attempt of demonstration by inequations of its logical deduction.
;Premise:r1>r2 ;Option 1: r1-r2>r1+r2 -> r2<0, FALSE ;Option 2: r1-r2<r1+r2 -> r2>0 -> TRUE ;If r1>r2 and r2>0 -> r1+r2>r1-r2 (Gile Conclusion)
Sorry, I should have said: "because r1+r2 is always greater than abs(r1-r2)" or "because sqr (r1+r2)) is always greater than sqr(r1-r2)" (we are using the Pythagorean theorem).
That means we do not have to care if r1 is greater or smaller than r2.
A generic function.
It replies to the challenge when called with flags = 2.
;; assign
;; Assigns DXF values of the supplied ename to the symbols
;;
;; Arguments
;; ename : ename of the object
;; codeSymList : list of dotted pairs (dxfGroupCode . symbol)
;;
;; Example;
;; (assign line '((10 . starttPt) (11 . endPt)))
(defun assign (ename codeSymList / l)
(setq l (entget ename))
(mapcar
'(lambda (x) (set (cdr x) (cdr (assoc (car x) l))))
codeSymList
)
)
;; circleTangents
;; Draws tangents between two circles (if possible)
;;
;; Arguments
;; circle1 : ename of the first circle
;; circle2 : ename of the second circle
;; flags : a value indicating which tangents to draw,
;; sum of the following values:
;; - 1: outside tangents
;; - 2: inside tangents
(defun circleTangents
(circle1 circle2 flags / c1 r1 c2 r2 a1 c b d a2 l)
(assign circle1 '((10 . c1) (40 . r1)))
(assign circle2 '((10 . c2) (40 . r2)))
(setq a1 (angle c1 c2)
c (distance c1 c2)
)
(foreach x (list (list 1 - 0) (list 2 + pi))
(and
(< 0 (logand (car x) flags))
(setq b ((cadr x) r1 r2))
(< b c)
(setq d (sqrt (- (* c c) (* b b))))
(setq a2 (atan d b))
(setq l (vl-list*
(list (+ a1 a2) (+ a1 a2 (caddr x)))
(list (- a1 a2) (- a1 a2 (caddr x)))
l
)
)
)
)
(mapcar
'(lambda (p)
(entmakex
(list (cons 0 "LINE")
(cons 10 (polar c1 (car p) r1))
(cons 11 (polar c2 (cadr p) r2))
)
)
)
l
)
)
Testing command:
(defun c:test (/ c1 c2 kw)
(if
(and
(setq c1 (car (entsel "\nFirst circle: ")))
(setq c2 (car (entsel "\nSecond circle: ")))
(progn
(initget 1 "Inside Outside Both")
(setq kw (getkword "\nTangents to draw [Inside/Outside/Both]: "))
)
)
(circleTangents
c1
c2
(cond
((= kw "Inside") 2)
((= kw "Outside") 1)
(T 3)
)
)
)
(princ)
)
Regards.
Here my code applying only plane geometry, by the calculation method of the center of inverse homothety. I hope the architect @dbroad will kindly confirm its validity. I have observed that the other proposals have raised the solution by applying trigonometric functions, which should generate an unexpected margin of error.
(defun tan_int (s1 s2 / spm c1 c2 px1 px2 po pm1 com lspt pt1 pt2 pr1 pr2 pt3 pt4)
(setq
spm (vla-get-modelspace (vla-get-activedocument (vlax-get-acad-object)))
)
(setq c1 (cdr (assoc 10 (entget s1)))
c2 (cdr (assoc 10 (entget s2)))
px1 (vlax-curve-getpointatparam s1 (* 1.5 pi))
px2 (vlax-curve-getpointatparam s2 (* 0.5 pi))
po (inters c1 c2 px1 px2)
pm1 (mapcar '* (mapcar '+ c1 po) '(0.5 0.5 1.))
com (vla-addcircle spm (vlax-3d-point pm1) (* (distance c1 po) 0.5))
)
(setq lspt (vlax-invoke (vlax-ename->vla-object s1)
'IntersectWith
com
acExtendNone
)
pt1 (list (nth 0 lspt) (nth 1 lspt) (nth 2 lspt))
pt2 (list (nth 3 lspt) (nth 4 lspt) (nth 5 lspt))
pr1 (vlax-curve-getparamatpoint s1 pt1)
pr2 (vlax-curve-getparamatpoint s1 pt2)
pt3 (vlax-curve-getpointatparam s2 (+ pr1 pi))
pt4 (vlax-curve-getpointatparam s2 (+ pr2 pi))
)
(entdel (vlax-vla-object->ename com))
(vla-addline spm (vlax-3d-point pt1) (vlax-3d-point pt3))
(vla-addline spm (vlax-3d-point pt2) (vlax-3d-point pt4))
)
(tan_int (car(entsel "\nSelect Circle1: "))(car(entsel "\nSelect Circle2: ")))
Carlos Calderon G
>Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
@calderg1000 a écrit :
I have observed that the other proposals have raised the solution by applying trigonometric functions, which should generate an unexpected margin of error.
Could you elaborate about "unexpected margin of error", please ?
By the way, I strongly suspect that the IntersectWith, vlax-curve-getParamAtPoint or vlax-curve-getPointAtParam functions used with circles work with trigonometric calculations.
Gil thank you for your answer.
I mean that any procedure that obeys a mathematical calculation due to the application of trigonometric formulas have a degree of precision that is limited by the rounding factor. Which should be much less by applying graphic geometric procedures. My solution proposal is for a totally graphic methodology, only that I have ignored the use of the compass and the protractor. Using the functions that allow me to find parameters
and interceptions. Well after all it is true I have been able to verify that the margins of error are negligible...
Carlos Calderon G
>Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
I don't think there is any specific inaccuracy due to the use of trigonometric functions (and, again, they are certainly used internally for geometric calculations with circles).
There is an unavoidable inaccuracy with real numbers in computer science that should be well known to anyone who does programming.
This inaccuracy is due to the binary coding of floating-point numbers. AutoCAD uses the double-precision floating-point format that provides accuracy down to 15 or 16 significant digits.
You can try the following simple non trigonometric operation (a substraction);
_$ (= 0.1 (- 1.1 1.0))
nil
Why ? We can see these values with 16 digits using the rtos function:
_$ (rtos 0.1 2 16)
"0.1000000000000000"
_$ (rtos (- 1.1 1.0) 2 16)
"0.1000000000000001"
Also with constant PI, the precision does not exceed 15 decimal places:
_$ (rtos pi 2 16)
"3.141592653589793"
_$ (rtos pi 2 17)
"3.141592653589793"
_$ (rtos pi 2 18)
"3.141592653589793"
@calderg1000 a écrit :
My solution proposal is for a totally graphic methodology,
Your algorithm is indeed the transcription of a graphical method, but it uses functions like IntersectWith or vlax-curve* functions that necessarily use analytic geometry.
A purely graphical method on paper has a precision of the order of the thickness of the pencil line, the equivalent in computer science would have a precision of the order of the pixel.
@john.uhden a écrit :
I might agree, but I think that rtos doesn't work past 16 places.
Unfortunately we have no other way of seeing so many places.
rtos doesn't work past 16 places because the double-precision floating-point format only provides accuracy down to 15 or 16 significant digits.
You can try something like this to see that the 17th decimal place is no longer reliable:
_$ (= 0.123456789012345678901234 0.12345678901234568)
T
And when we talk about "significant digits" it also takes into account the digits before the decimals.
_$ (= 1234567890.1234567890123456 1234567890.1234567)
T
_$ (= 12345678901234567.999999999 12345678901234567)
T
As does rtos:
_$ (rtos 1234567890.123456789012345678901234 2 24)
"1234567890.123457"
This is a phenomenon often encountered by those who work with coordinates far from the origin.
@john.uhden wrote:
.... I think that rtos doesn't work past 16 places. ....
Be careful of the distinction between decimal places and significant figures. The (rtos) function can handle more than 16 decimal places, if the figures immediately following the decimal point are zeroes, which are not significant if they precede the first significant figures starting later:
Command: (rtos (/ pi 1000) 2 18)
"0.003141592653589793"
18 decimal places, 16 sig-figs.
And extending that....
Command: (rtos (/ pi 100000) 2 20)
"0.00003141592653589793"
20 decimal places, 16 sig-figs.
Conversely, it can't handle as many as 16 decimal places if some of its allowance of 16 sig-figs is eaten up before the decimal point, as demonstrated in Message 18.
