Topic: [Solved] MID of a given arc

[Peter2]

EDIT: At the moment I pressed "Post" I got the idea ... Solution see below.

I have an arc, given with startpoint, endpoint, radius and centre. Should be easy, but at the moment I have no idea how to calculate the MID of the arc (I'm confused about direction of rotation, angles > 2pi  ...)

Any hints?
Thanks.

EDIT: Solution:

Code: [Select]

(polar zen (angle zen (mapcar '(lambda (x) (* 0.5 x))(mapcar '+ start end))) rad)which means ..
- calculate the middle of START and END (helppoint)
- calculate the point with Polar from centre with direction to helppoint and with length of radius
Should do it ...

Peter

[Kerry]

http://docs.autodesk.com/ACD/2014/ENU/files/GUID-8FF6D3D5-7EA5-4E9A-8A61-295C0562E7AE.htm
and
http://docs.autodesk.com/ACD/2014/ENU/files/GUID-F41FB58A-4645-404E-98B7-D4978A9A790B.htm

[Peter2]

Hi Kerry

thanks - you were to quick for my edit above. I'm sorry. But nevertheless, I have to learn a lot about the "vlax-curve" functions.

[ronjonp]

Hi Kerry

thanks - you were to quick for my edit above. I'm sorry. But nevertheless, I have to learn a lot about the "vlax-curve" functions.

See if you can dissect this:

Code: [Select]

(defun _mid (ename / ep)
  (if (not (vl-catch-all-error-p (setq ep (vl-catch-all-apply 'vlax-curve-getendparam (list ename)))))
    (vlax-curve-getpointatdist ename (/ (vlax-curve-getdistatparam ename ep) 2.))
  )
)
;; (_mid (car (entsel)))

[Kerry]

ronjonp,

Mine is similar ; except I multiply by 0.5 instead of dividing by 2.0

[ronjonp]

ronjonp,

Mine is similar ; except I multiply by 0.5 instead of dividing by 2.0

[Kerry]

I've had a little think about the multiply/divide issue.
Popular belief WAS that multiplying by a value was more economical than dividing by a value.
I haven't done any research on this so I'm not sure is this was ever or is still true.
It's one of those geeky habits one develops I s'pose.

I imagine the efficiency difference would depend on the language and compilation.

added:
And perhaps efficiency is affected if the value or it's reciprocal is an integer.

[owenwengerd]

And perhaps efficiency is affected if the value or it's reciprocal is an integer.

On binary hardware, a multiply or divide by two is a simple shift-by-one, which is as easy as it gets.

[irneb]

In general I do think * is faster than /. See some writeup here: http://stackoverflow.com/questions/4125033/floating-point-division-vs-floating-point-multiplication

On binary hardware, a multiply or divide by two is a simple shift-by-one, which is as easy as it gets.

Usually if you're compiling your code and the compiler actually optimizes for that yes. If AutoLisp does it in FAS or even in its interpreted state I'm not sure. Also these are floating point numbers, so a simple shifting of bits isn't exactly how it happens: rather an increment/decrement of the exponent (might even be faster). So if ALisp's interpreter and/or compiler recognises multiplication / division by 2, then yes it should perform faster, else it'll use the longwinded way - in which case multiplication will always be faster.

Actually from tests the AutoLisp interpreter actually seems to have no effective difference in speed between / and *, not even between integer and real numbers. And not even between 2 or 3 as divisor:

Code: [Select]

_$ (quickbench '((/ 123456 2) (* 123456 2) (* 123456 0.5) (/ 123456 2.0) (/ 123456. 2) (* 123456. 2) (* 123456. 0.5) (/ 123456. 2.0) (/ 123456 3) (* 123456 3) (* 123456 0.3333333333333333) (/ 123456 3.0) (/ 123456. 3) (* 123456. 3) (* 123456. 0.33333333333333333333333333333333) (/ 123456. 3.0)))
Benchmarking ................ done for 32768 iterations. Sorted from fastest.
Statement                                Increment  Time(ms) Normalize  Relative
--------------------------------------------------------------------------------
(/ 123456 3)                                 32768      1137      1137      1.08
(* 123456 2)                                 32768      1170      1170      1.05
(/ 123456.0 3.0)                             32768      1171      1171      1.05
(* 123456 3)                                 32768      1185      1185      1.04
(* 123456.0 0.333333)                        32768      1185      1185      1.04
(/ 123456 2)                                 32768      1186      1186      1.04
(/ 123456.0 2)                               32768      1186      1186      1.04
(/ 123456 3.0)                               32768      1187      1187      1.04
(* 123456 0.5)                               32768      1201      1201      1.03
(/ 123456.0 3)                               32768      1201      1201      1.03
(* 123456.0 3)                               32768      1202      1202      1.02
(/ 123456 2.0)                               32768      1216      1216      1.01
(* 123456.0 2)                               32768      1217      1217      1.01
(* 123456.0 0.5)                             32768      1217      1217      1.01
(* 123456 0.333333)                          32768      1218      1218      1.01
(/ 123456.0 2.0)                             32768      1232      1232      1.00
--------------------------------------------------------------------------------
As for the OP: If you want to find all sorts of other calcs on arcs, I've found this to be a great resource.

[Kerry]

< .. >

As for the OP: If you want to find all sorts of other calcs on arcs, I've found this to be a great resource.

I miss Stig. Hope he is well.

[Kerry]

Hi

interesting discussions here. The "vlax-curve"-functions are great, but how to handle it with an basic algorithm for pocket calculators?

But, back to the roots...

I saw that my "solution" I posted above has some lacks - especially if the "included angle > pi".

Example: I have two following red lines with points A - B - C. With A - B - C I can create an arc, and with 3P-arc-calculation I can calculate CEN and RAD. But how to calculate the included angle, if the arc is > PI or if the arc runs over the "0 PI"? How to calculate the MID?

We know the following points
A
B
C

So we know the distance from A->B, B->C, A->C.
We know the radius.
So we can calculate the angles A, Cen, B and B, Cen, C
The sum of these will be the enclosed angle.

[Stefan]

EDIT: Solution:

Code: [Select]

(polar zen (angle zen (mapcar '(lambda (x) (* 0.5 x))(mapcar '+ start end))) rad)which means ..
- calculate the middle of START and END (helppoint)
- calculate the point with Polar from centre with direction to helppoint and with length of radius
Should do it ...

You can use angles instead points.
This vanilla solution should work for any arc.

Code - Auto/Visual Lisp: [Select]

1. (defun C:MIDARC (/ mid_arc ss i)
2.   (defun mid_arc (e / c s f a n r)
3.     (setq e (entget e)
4.           c (cdr (assoc  10 e))         ; center point [OCS]
5.           s (cdr (assoc  50 e))         ; start angle
6.           f (cdr (assoc  51 e))         ; end angle
7.           n (cdr (assoc 210 e))         ; normal vector
8.           r (cdr (assoc  40 e))         ; radius
9.           a (-                          ; angle center -> mid point
10.               (/ (+ s f) 2.0)
11.               (if (> s f) pi 0)         ; subtract pi, if start angle > end angle
12.             )
13.     )
14.     (trans (polar c a r) n 0)           ; arc midpoint [WCS]
15.   )
16.  
17.   (if
18.     (setq ss (ssget '((0 . "ARC"))))
19.     (repeat (setq i (sslength ss))
20.       (entmake
21.         (list
22.          '(0 . "POINT")
23.           (cons 10 (mid_arc (ssname ss (setq i (1- i)))))
24.         )
25.       )
26.     )
27.   )
28.   (princ)
29. )

[Kerry]

Stefan,
I think Peter wants a solution that is purely mathematical , not object/entity based.
ie:

< .. > but how to handle it with an basic algorithm for pocket calculators?

[Peter2]

...I think Peter wants a solution that is purely mathematical , not object/entity based....

Yes, this was my original target. But in the meantime I see that the "cost/efficiency ratio" of the pure mathematical solution is very bad; I hoped it could be a "two liner".

But it is not, and I'm very happy with the entity-based solution you showed me. So I don't want to waste your time any longer, for me it is solved.

(But if somebody has a solution and wants to share it - it would be appreciated)

[fixo]

And perhaps efficiency is affected if the value or it's reciprocal is an integer.

On binary hardware, a multiply or divide by two is a simple shift-by-one, which is as easy as it gets.

Thanks Owen, I like it:
http://otb.manusoft.com/2013/01/quirkypolyline-exposing-foolish-programmers.htm
Probably. it may helps to thread starter