Issue with coords
That's exponential format. Read "1.92882e-014" as 1.92882 x 10 (raised to the power of) -14; also written as "...x10 ^-14". AutoCAD uses that for displaying very, very large and small numbers. *Anything* to x10^-14 is way freaking small, just as anything x10^14 is astronomically big.
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
@Anonymous wrote:
.... im not using any amount of units that big or small. ....
Maybe not that big, but certainly you are using amounts that small. 10 to the minus 14 is essentially zero -- almost as close to zero as AutoCAD can handle. A point coordinate will sometimes come out that way [scientific notation] as the result of the calculations involved.
You should be able to use the resulting points, even if they look kind of funny in list-of-coordinates display.
Kent Cooper, AIA 
opazojonatan wrote:
The code hasnt (is that the word, "hasnt"?) that problem in any drawing but that one... Problem appears when i draw something too far away from the 0 (exact point was '(2588319.8 5976989.7)) o move something to somewhere that far. I have "fixed" it by not moving anything, but i will have to do it later or sooner. And yes, code should work anywhere on the drawing but its not. I will post it here tonight or tomorrow, maybe im doing something wrong or not doing something basic (im new at this)
There are limits to what can be represented as a number in a program - this is common with almost all computer systems dealing with numbers. The coordinates are stored as double-precision floating point numbers in the WCS. As those numbers get large (and I'm talking REALLY big numbers here), precision gets sacrificed in order to physically store the number. You'll find this more often a problem when working with 3D solids, such as extruding and revolving.
You should always strive for keeping the majority of work close to the WCS origin; if you require a different set of coordinates establish a named UCS at the appropriate location.
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
Hi,
Even close to the WCS origin you may have this kind of accuracy issue due to the double-precision floating numbers.
(polar '(0. 0. 0.) pi 1.) returns (-1.0 1.22465e-16 0.0) instead of (-1.0 0.0 0.0)
This is why we should always use a tolerance when comparing numbers points and so on.
@Anonymous wrote:
.... (10 0.0 ...........) with that last number in cientific notation. ....
In that case, since it's the Z coordinate and you didn't include a Z coordinate in your Line command point designations, could it be that your ELEVATION System Variable setting is not zero?
Kent Cooper, AIA
no, that 10 was the prefix of the point when you extract it with (ASSOC 10 (ENTGET ())... Today i gave up on it and continued working just to find another challenge involving UCS and entmake... But i guess i should ask in another post. Im going to check elevation but i think i was zero
Guess i will continue to finding problems while my actual work keeps being this boring and slow (not that slow as two months ago but still can be speeded up) 
@Anonymous wrote:
no, that 10 was the prefix of the point when you extract it with (ASSOC 10 (ENTGET ())... ....
Then are there two numbers [not just one "last number"] in scientific notation? For a Line as in your code sample, there should be X, Y and Z coordinates in addition to the 10 [or the 11 for the other end].
Kent Cooper, AIA