Topic: Getpoint Precision.

[Didge]

I feel pretty stupid for asking this, I suspect this'll lead to one of those "DOH!!-slap head" moments.

Anyway, I have a Map3D 2006 dwg that refuses to return accurate (getpoint) coords.  It does it's thing as usual but rounds the returned coords up or down to the nearest unit.  It appears to be 'dwg' specific so Im guessing it's a system variable issue.

I've checked through the usual tweaks such as  Dimzin, Lunits, luprec, Unitmode, -dwgunits  but no joy. 

Am I missing something blindingly obvious?

I forgot to mention, everything seems to work fine in paper space.

[LE]

Are you simple calling something like:

Code: [Select]

(setq pt (getpoint "\nPick a point: "))

?

I do not have A2006.

[CAB]

See if this helps.
http://www.theswamp.org/forum/index.php?topic=1962.msg25629#msg25629

[Didge]

Nothing as extravagent as that LE, just a solitary  (getpoint)  in model space.

Thanks CAB, but nothing in that thread seems to help in this case.

I've attached a 2000 version of the 'dwg' in question, no objects, just an empty dwg.

[LE]

I tested your drawing... and...
It might be my eyes... but seems that getpoint is returning the right output....

[CAB]

Well the get point returns an accurate number but does not display it.

Code: [Select]

Command: (setq a (getpoint))
(586922.0 191777.0 0.0)

Command: !a
(586922.0 191777.0 0.0)

Command: (- (car a) 586922.0)
0.187917
You see the fraction is there.
That is the nature of ACAD when the numbers get that large.

[LE]

What are you doing with those points?

One way to get more precision is to use:

(setq pt (getpoint "\nPoint: "))
(rtos (car pt) 2 16)
(rtos (cadr pt) 2 16)
(rtos (caddr pt) 2 16)

[ronjonp]

LE,

Funny you post that...I just put this together:

Code: [Select]

(setq pt (getpoint "\nPick a point: ")
       x (rtos (car pt)2 15)
       y (rtos (cadr pt)2 15)
       z (rtos (caddr pt)2 15)
      pt (list x y z)
)
How would the list be converted back to a usable point and keep the precision?

Ron

[T.Willey]

I have found that the precision is always there, it just doesn't always display right.  What they are showing is a way to SEE it correctly.

[CAB]

Reals
A real is a number containing a decimal point. Numbers between –1 and 1
must contain a leading zero. Real numbers are stored in double-precision
floating-point format, providing at least 14 significant digits of precision
Note that VLISP does not show you all the significant digits.
Reals can be expressed in scientific notation, which has an optional e or E followed
by the exponent of the number (for example, 0.0000041 is the same
as 4.1e-6). Numbers such as 3.1, 0.23, –56.123, and 21,000,000.0 are valid
AutoLISP reals.

[LE]

^
What CAB... found too....

[CAB]

Also read this thread.
http://tinyurl.com/nbzue

[Didge]

The following demonstrates the problem, (not sure how to post an image here)
Notice how 'ID' and 'Getpoint' return different values for the same point. Maybe this is a Map3D issue I'm unfamiliar with.

LINE Specify first point:
Specify next point or [Undo]:
Specify next point or [Undo]:

Command: id
Specify point: _endp of  X = 15024.689     Y = -127900.431     Z = 0.000

Command: (getpoint)
_endp of (15024.7 -127900.0 0.0)

[T.Willey]

Try this.

Code: [Select]

(foreach i (getpoint)
 (princ (strcat "\n " (rtos i 2 4)))
)


[LE]

What are you doing with those points?

Update me....  :whistle:

[Didge]

I was completing some code to automatically generate pipeline longsections by picking a 2d polyline drawn above a TIN (see 'triangulation' thread) when I noticed the issue. The coding seems to work well, but I can't remember getpoint ever rounding display co-ordinates before.

CAB appears to be correct in that acad is retaining the decimals but displaying them rounded, this gives me peace of mind in my calculations, but it still doesn't explain whats forcing the rounding.

If I start a new drawing all seems fine again, so I still suspect a system variable at the heart of things.

[CAB]

The number displayed by getpoint will round more as you move away form 0,0
In the NEW drawing, are you near 0,0 ?

[Didge]

As predicted "DOH !!" - <slaps head>  Guess who feels stupid now?

Yes that was it CAB, the rounding is indeed relative to the origin, in all my years of coding I've never noticed this before.

If this place wasnt virtual I'd buy you guys a beer.

Thank-you all for your assistance, I will be able to sleep tonight, albeit while wearing my stupid hat