ripuz Posted May 28, 2012 Share Posted May 28, 2012 Hi! Does anyone know how to find the exact insertion point of a block with autolisp? And with "exact" I mean with all decimals. If a block is inserted with snap and then moved 0.0000001 to the left. Is it then possible to find that block with autolisp? Thanks in advance / Thomas Quote Link to comment Share on other sites More sharing options...
pBe Posted May 28, 2012 Share Posted May 28, 2012 contrary to what other people think, when you retrieve the insertion point of a block , it WILL give you the exact coordinate. You may not "see" it, but i tell you now. IT IS. Try inserting a block at 0,0 coordinates. and move that block 0.0000001 then use (Cdr (assoc 10 (entget (Car (entsel))))) You will get something like (1.0e-007 0.0 0.0) Quote Link to comment Share on other sites More sharing options...
MSasu Posted May 28, 2012 Share Posted May 28, 2012 The code below will allow you to see the available number of decimals: (if (setq itemBlock (ssget ":S" '((0 . "INSERT")))) (progn (setq pointIns (cdr (assoc 10 (entget (ssname itemBlock 0))))) (prompt (strcat "\Insertion point:" "\n X = " (rtos (car pointIns) 2 18) "\n Y = " (rtos (cadr pointIns) 2 18) "\n Z = " (rtos (caddr pointIns) 2 18))) ) ) Quote Link to comment Share on other sites More sharing options...
irneb Posted May 28, 2012 Share Posted May 28, 2012 @pBe: While the example shows correctly, I think it might be unclear about rounding off errors. If the insertion point is somewhere away from 0,0,0 and also ever so slightly off a full number (integer) then you might find that the display of the insertion point omits the decimals (this is due to the LUPREC setting). @ripuz: Even if you set the precision as high as possible, it might still not display all the decimals. The returned value (as pBe's shown) is still the "exact" point though, it might just be difficult to display to absolute accuracy. All calculations on such point uses the double precision floating point value returned with entget, not the value you see on the command line in the list command. It's not "perfect" accuracy, but it's as good as it gets, since acad itself only uses double precision floating points internally. There are some small errors (called floating point errors), which might crop up - but they're generally to 16 decimal digits or less. http://en.wikipedia.org/wiki/Floating_point Quote Link to comment Share on other sites More sharing options...
ripuz Posted May 28, 2012 Author Share Posted May 28, 2012 contrary to what other people think, when you retrieve the insertion point of a block , it WILL give you the exact coordinate. You may not "see" it, but i tell you now. IT IS. Try inserting a block at 0,0 coordinates. and move that block 0.0000001 then use (Cdr (assoc 10 (entget (Car (entsel))))) You will get something like (1.0e-007 0.0 0.0) Okey, I see... I did as you said and i got the same answer as you but only when x are close to zero. If the block is located at 99.999999, 100 the answer will be (100.0 100.0 0.0). I got your point though... That the coordinates is the right coordinates, it´s just not displayed exactly. And to show it: (rtos (Cadr (assoc 10 (entget (Car (entsel))))) 2 Thanks for you quick reply pBe! Quote Link to comment Share on other sites More sharing options...
ripuz Posted May 28, 2012 Author Share Posted May 28, 2012 @pBe: While the example shows correctly, I think it might be unclear about rounding off errors. If the insertion point is somewhere away from 0,0,0 and also ever so slightly off a full number (integer) then you might find that the display of the insertion point omits the decimals (this is due to the LUPREC setting). @ripuz: Even if you set the precision as high as possible, it might still not display all the decimals. The returned value (as pBe's shown) is still the "exact" point though, it might just be difficult to display to absolute accuracy. All calculations on such point uses the double precision floating point value returned with entget, not the value you see on the command line in the list command. It's not "perfect" accuracy, but it's as good as it gets, since acad itself only uses double precision floating points internally. There are some small errors (called floating point errors), which might crop up - but they're generally to 16 decimal digits or less. http://en.wikipedia.org/wiki/Floating_point Thanks irneb, now I´ll understand. Quote Link to comment Share on other sites More sharing options...
MSasu Posted May 28, 2012 Share Posted May 28, 2012 Also keep in mind that the precision is inverse proportional with the "size" of the number: (rtos 12.345678901234567 2 18) [color=magenta];Return> "12.34567890123457"[/color] (rtos 1234567.8901234567 2 18) [color=magenta];Return> "1234567.890123457"[/color] (rtos 12345678901234.567 2 18) [color=magenta];Return> "12345678901234.57"[/color] Quote Link to comment Share on other sites More sharing options...
irneb Posted May 28, 2012 Share Posted May 28, 2012 Yes, the ~16 digits means 16 in total. Not 16 after the decimal point. So as Mircea's shown the rounding / floating point error becomes worse the further you are away from 0,0,0. For this reason I prefer drawing as close as possible to 0,0,0 and using UCS's for stuff like coordinate references. Quote Link to comment Share on other sites More sharing options...
pBe Posted May 28, 2012 Share Posted May 28, 2012 I got your point though... That the coordinates is the right coordinates, it´s just not displayed exactly.Thanks for you quick reply pBe! Good for you @Msasu/Irné All bases covered Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.