Find exact insertion point

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

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)

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)))
)
)

@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

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!

@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.

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]

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.

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