Inaccuracy between lines

[irneb]

I've come across this scenario: when offsetting a line (while in a rotated UCS) the distance between the "parallel" endpoints differ by fractions of a unit (I'm working in millimeters so don't draw in fractions).

This seems to happen throughout all the drawings, only when operating in WCS does this not occur. Usually it's not a problem, as the variation is very slight (something like 0.01%) - but the error gets compounded over large buildings where you've offset many times. For example setting out a grid at 6000 intervals sometimes gives an overall dimension (over 18 lines) of 108003. Then I have to adjust each line slightly so their dims don't show something other than 6000, while the overall should show 108000. I know that you can't find a contractor to build at that accuracy, but I'd at least want my drawings to appear as if I've had a calculator at hand.

Is there some error in AutoCAD? I know that you get inaccuracies when using the Copy-n-Paste functions, as well as using the Express Tool's Flatten command, but these commands were not used in the problem drawings - exactly for the inaccuracy it creates.
The only thing I can think of is that there's a slight loss in accuracy when converting between WCS & UCS. Possibly because of a different floating point variable type used - something like single precision instead of double (or extended).

Has anyone come across this before, if so have you found a solution?

[rkmcswain]

I know that you get inaccuracies when using the Copy-n-Paste functions

What leads you to believe that?

Copy+Paste is no different than Wblock+Insert.
No accuracy is lost in either case.

The exception to this is if you are working in an area with very large coordinates since AutoCAD is only accurate to 15 significant digits.

Ref URL: http://www.intelcad.com/pages/autocad/index.htm

[arshiel88]

Flatten does give you inaccurate 'recreated' objects but not the copy and paste. My suspicion is that the error is when you rotate coordinate system and 99%, its a user error not the program itself.
I have a colleague that produced a very much inaccurate drawings, endpoints are not to endpoints, lines are overlapping, angles supposed to be the same but with little differences.
To escape from the blame, he said he used Educational version of AutoCAD. Can somebody please confirm this statement if this version really produce inaccurate drawings.

[jaberwok]

........ To escape from the blame, he said he used Educational version of AutoCAD. Can somebody please confirm this statement if this version really produce inaccurate drawings.


I've seen no evidence to support the claim.

[ekubaskie]

Plot the drawing. If he used the educational version it will have a watermark that says so.

If you DO get the watermark, slap the guy around, because that watermark will find it's way into any drawing touched by the ed version, and to any drawing that has content created in the ed version inserted, pasted, etc.

[david.scheu]

I can't reproduce the inaccuracy you're getting. Even at maximum UNITS precision, each endpoint of my 31st line is 180,000.00000000 from the corresponding endpoint of the first. UCS rotation doesn't seem to matter.

Are you seeing the discrepancy in a DIST command, or just when you dimension?

Do you get the same result if you use ARRAY, rather than repeated offsets?

[pertti.ahjokivi]

Same problems here.

Getting quite fed up with inaccuracies of a program, which is supposed to be accurate to 16 decimals...

As most of us in metric environment, I design in full millimeters, and seeing decimals in coordinates usually means that your model is screwed...

Apparently, one cause of inaccuracy can be found in AutoCad not having accurate angles, so when you copy something to an angle (ie. 90deg, 180deg, 270deg, etc...), the copied object goes slightly off the intended coordinates.

Discussing the problem with people using imperial system is also quite frustrating, because they simply cannot understand the problem (due to them having "infinite" number of decimals all the time...)

[michael.12445]

Actually I'm using Imperial units and also having accuracy problems - see my post(s) under the "Strange inaccuracies" thread.

In particular, I've noticed odd behavior in connection with osnaps - AutoCAD "finds" intersections, etc., that are very slightly off where the geometry actually intersects. (Yes, I know about how the limitations of display hardware can make snapping to arcs and circles appear to be off the geometry, but I'm seeing these inaccuracies with lines only.)

Michael Evans
Togawa Smith Martin Residential, Inc.

[rkmcswain]

Discussing the problem with people using imperial system is also quite frustrating, because they simply cannot understand the problem
I'd like to see this. Can you provide a step-by-step procedure to illustrate this? Thanks.

[irneb]

I've noticed odd behavior in connection with osnaps - AutoCAD "finds" intersections, etc., that are very slightly off where the geometry actually intersects.

That could be due to the "Alignment Point Acquisition" feature in AutoCAD (I think from 2006 onwards - could be wrong). What I've found is if you wait just slightly to long when hovering the cross-hairs over say an endpoint, you get a very slight distance away from that endpoint.

AutoCAD does provide 2 ways of circumventing this problem: 1 turn the Object Snap Tracking ON/OFF (F11 key). 2 Or rather - what I prefer is change the Alignment Point Acquisition from Automatic to Shift to Acquire. This you change in the Options dialog (Drafting page). The that tracking vector only shows after you've hovered over the relevant point & pressed the Shift key, otherwise you will always just select the endpoint, intersection, etc - not some vector distance away from the point you want.

[victoria]

Have any of you tried the changing the VIEWRES to maximum? 20,000

[rkmcswain]

Have any of you tried the changing the VIEWRES to maximum? 20,000

VIEWRES only affects visibility, not the accuracy of drawing geometry.

[CADDmanVA]

What leads you to believe that?

Copy+Paste is no different than Wblock+Insert.
No accuracy is lost in either case.

The exception to this is if you are working in an area with very large coordinates since AutoCAD is only accurate to 15 significant digits.

Ref URL: http://www.intelcad.com/pages/autocad/index.htm

I'll argue that till the day I die! Using accelerator keys creates anonymous blocks and will quickly bloat the daylights out of a drawing. I think using them is fine IF AND ONLY IF you purge the block out after the move.


Actually I'm using Imperial units and also having accuracy problems - see my post(s) under the "Strange inaccuracies" thread.

In particular, I've noticed odd behavior in connection with osnaps - AutoCAD "finds" intersections, etc., that are very slightly off where the geometry actually intersects. (Yes, I know about how the limitations of display hardware can make snapping to arcs and circles appear to be off the geometry, but I'm seeing these inaccuracies with lines only.)

I've noticed this problem with OSNAPS too. Another problem I have rather frequently is using the tangent tangent radius routing for circles. According to AutoCAD, the created circle is tangent to both objects, but TRIM says otherwise. I never thought about math errors or accuracy errors before now though..........

[mmccarter]

Flatten does give you inaccurate 'recreated' objects but not the copy and paste. .
I would take issue with this statment.
I have seen the flatten command do wild things with the geometry and position of the contents of a drawing after it has been run. Seen it many many times.

[michael.12445]

I'd be curious to see if anybody else gets the same results with this as I do...try running this on any given file whose line entities are supposed to be exactly vertical or horizontal:

(defun ratout()
(setq a (ssget "X" '( ( 0 . "line" ) ) ))
(setq k 0)
(while (< k (sslength a))
(if (not
(or (eq (caddr (assoc 10 (entget (ssname a k))))
(caddr (assoc 11 (entget (ssname a k))))
) ;y-coordinates match - line is horizontal

(eq (cadr (assoc 10 (entget (ssname a k))))
(cadr (assoc 11 (entget (ssname a k))))
) ;x-coordinates match - line is vertical

(eq (- (caddr (assoc 10 (entget (ssname a k)))) (caddr (assoc 11 (entget (ssname a k)))))
(- (cadr (assoc 10 (entget (ssname a k)))) (cadr (assoc 11 (entget (ssname a k)))))
) ; line is diagonal at 45 degrees

(eq (- (caddr (assoc 10 (entget (ssname a k)))) (caddr (assoc 11 (entget (ssname a k)))))
(- (cadr (assoc 11 (entget (ssname a k)))) (cadr (assoc 10 (entget (ssname a k)))))
) ; line is diagonal at 135 degrees

)
)
(progn
(command "change" (ssname a k) "" "p" "color" "30" "")
)
)
(setq k (+ k 1))
)
)

- to use it, load "ratout.lsp" and then type (ratout) at the command: prompt. If your drawing uses color 30, you should change "30" to another color in the line

(command "change" (ssname a k) "" "p" "color" "30" "")

What this does is find any line that's not either horizontal, vertical, or diagonal at 45 or 135 degrees, and then changes its color to orange (color 30). Of course, this will also flag lines that are intentionally angled, but I'm interested in the ones that are supposed to be orthogonal. I'm finding on files that have been around a while and undergone lots of editing, almost every line is off. I'm also finding that I can produce lines that are off in a new file by using tools that I thought were meant to ensure accuracy, i.e., osnaps, polar snap, etc. (no, I am NOT trying to "eyeball" anything!)

I'd be very curious to see what others come up with...

Thanks,

Michael Evans
Togawa Smith Martin Residential, Inc.

[rkmcswain]

I'll argue that till the day I die! Using accelerator keys creates anonymous blocks and will quickly bloat the daylights out of a drawing. I think using them is fine IF AND ONLY IF you purge the block out after the move.

I wasn't talking about drawing bloat. I was talking about the accuracy of entities copied from drawing to drawing using either wblock/insert or copy/paste. There is no difference.



I've noticed this problem with OSNAPS too. Another problem I have rather frequently is using the tangent tangent radius routing for circles. According to AutoCAD, the created circle is tangent to both objects, but TRIM says otherwise. I never thought about math errors or accuracy errors before now though

It all leads back to the 15 significant digits of accuracy. The more places you use up on the left side, there fewer there are on the right for calculations.

[irneb]

I wasn't talking about drawing bloat. I was talking about the accuracy of entities copied from drawing to drawing using either wblock/insert or copy/paste. There is no difference.
I don't know, I've found that normal copy-n-paste gives me inaccuracies. But when I copy with a base point this doesn't happen. I think the reason may be something to do with the "base point" AutoCAD assigns automatically when you don't explicitly assign one.


It all leads back to the 15 significant digits of accuracy. The more places you use up on the left side, there fewer there are on the right for calculations.
I think this is exactly what's going on ... I've tried looking at each line's x & y values. These start with a fractional (decimal) value - so the 15-16 digits are already used fully. Then since all numbers in computer terms are in binary (base 2), this converts very badly into decimal (base 10) numbers (http://en.wikipedia.org/wiki/Floating_point). So what I've found is that moving all the lines to a round number as base - removes the inaccuracies.

Unfortunately I can't always apply the above fix. Sometimes I've got a site-plan (spanning more than 1km - i.e. 1 000 000mm) which has several sets of grid-lines at different angles. These start very seldom on a round number (because they're at different angles). I usually create a UCS for each set so I can rotate the view to plan & have all my polar angle snaps work with the relevant grid-set. So the fact that I'm using at least 6 digits at the left & then have a gird-set at an angle from WCS, I can see 2 places where that 15-16 digits gets used up.

[irneb]

I'd be curious to see if anybody else gets the same results with this as I do...try running this on any given file whose line entities are supposed to be exactly vertical or horizontal:

I've tried your code, unfortunately it gives me way to much incorrect "error" lines (nearly everything). So I've created a similar LSP (TESTLINES.LSP) attached. When I run this on a ground-floor plan I get:
About to check lines for accuracy or perpendicular with a tollerance of 0.01000000 degrees.
11635 lines found in current drawing.
617 lines found not perpendicular.

And I've checked this, most of those "error" lines are walls (see attached screen capture - Capture_4.jpg). The lines in WHITE are those found as off by 0.01 degrees. They've been created at exactly 0, 90, 180, or 270 of WCS. Then trimmed when creating the windows & recesses. As you can see some of the left-over lines don't give the error.

The extents of the floor plan ranges from (-187000;-35400) to (1335100;803900). The range of the screen capture is (830500;581400) to (848400;592200).

[rkmcswain]

I don't know, I've found that normal copy-n-paste gives me inaccuracies.

But it still shouldn't be any different than wblock/insert.

When you "copyclip" entities, AutoCAD simply blocks them out to a DWG file in your %temp% directory. When you pasteclip into a drawing, it's simply inserting that block.

[irneb]

When you pasteclip into a drawing, it's simply inserting that block.
Yes that's true. Unfortunately when you copyclip (not copybase) AutoCad calculates the insertion point as the left-bottom-most point of the entities you've selected, or if you've zoomed in closer than that then the left-bottom coordinates of the visible screen. This is usually not a point a rounded coordinate distance from the entities (unless you've zoomed-out sufficiently & your left-bottom-most entity has a rounded coordinate for its left-bottom-most point - which it wont if it's an arc or a "skew" line).

Thus everything gets placed in this block at fractional coordinates, even if you haven't drawn them that way - i.e. you get into that 15-16 points of accuracy scenario again.

This is also one of the reasons (not the major one by far) why you should never create a block without explicitly specifying a base point (insertion point).

Another thing about the "bloating" is that wblock & insert does the same thing, as all the current (and standard) styles such as text, dims, tables, layers, etc. are included in that DWG file, even if the entities you've selected to wblock has nothing to do with those styles. The only way (I know of) to "copy" a block from one drawing to another without all that clutter piggy-backing with it is: using DesignCenter, browse to the current open drawings, browse to the blocks in the relevant drawing & drag-n-drop the block you want.

[Richard.Kent]

Michael, I ran it on a file of mine and it found more lines not ortho than the other program posted below. Yours ran fine here and changed a bunch of lines to color 30. I know I didn't use copy paste on this drawing, in fact I rarely use that command. I do use copy with base point and paste with base point.

[michael.12445]

Yes, the ratout.lsp file I posted was a quick-n-dirty effort to detect lines that are off of vertical or horizontal, and it's merciless - it just uses the (eq) lisp function to compare x- and y-coordinate endpoints of lines, and if the values are not exactly equal - in every one of their 64 bits worth of double precision - the line will be flagged. There is no tolerance and no angular calculation involved.

I haven't experimented with copy / paste, but I have noticed inaccuracies resulting from the use of polar tracking during editing operations. For example:

Typing in the coordinates explicitly to make sure they're exact, in a new drawing draw a line from 0,0 to 1,0, then to 0,1, and then "close" to make a right triangle with two equal sides each 1 unit long. Now, with "Polar" on (F10), invoke the MIRROR command, select all 3 lines, and for the mirror axis, select either Endpoint at 0,0 or 0,1, move the cursor above or below the figure until the 90 or 270 degree tracking vector appears, and select a point along the tracking vector. This will create another triangle on the left side of the first one.

Now, type (setq a (ssget)) at the Command: prompt, and select either the newly created vertical or horizontal line at the Select objects: prompt. Then type (entget (ssname a 0)) to list the data describing this line (you may need to press F2 to see all of it in the text window). The sub-groups that begin with "10" and "11" are the x-, y-, and z-coordinates of each endpoint. Since this line is the product of mirroring a perfectly horizontal or vertical line about an axis that was supposed to be perfectly vertical, either the x- or y-coordinates of each endpoint should match exactly, but they don't. On my computer, one is generally off by a tiny amount, on the order of 1.0e-16.

Now granted, this is an extremely small error, but it's larger than the smallest number theoretically possible even with single-precision floating representation, let alone double-precision. Since we're using AutoCAD for construction documents whose tolerance is generally no smaller than 1/4" (0.25 units), I'd be perfectly willing to forgive such a tiny error, if only AutoCAD was, too. But as the objects get larger, the error gets proportionally larger, too - and over time, edits upon edits are apparently able to compound the errors to the point where they begin interfering with operations like PEDIT join, BHATCH, TRIM, EXTEND, etc.

This kind of reminds me of when the very first "scientific" calculators came out and would give the sine of 30 degrees as 0.4999999999999 instead of 0.5. It appears that AutoCAD indeed allocates double-precision real numbers for coordinates, but takes some shortcuts somewhere when these coordinates are used in calculations. I would have thought that the polar tracking mechanism should be better able to cope with the very common situation of horizontal or vertical tracking vectors. But it doesn't, so I'm sticking to F8 (Ortho) for now.

Michael Evans
Togawa Smith Martin Residential, Inc.

[CADDmanVA]

But it still shouldn't be any different than wblock/insert.

When you "copyclip" entities, AutoCAD simply blocks them out to a DWG file in your %temp% directory. When you pasteclip into a drawing, it's simply inserting that block.


Another thing about the "bloating" is that wblock & insert does the same thing, as all the current (and standard) styles such as text, dims, tables, layers, etc. are included in that DWG file, even if the entities you've selected to wblock has nothing to do with those styles. The only way (I know of) to "copy" a block from one drawing to another without all that clutter piggy-backing with it is: using DesignCenter, browse to the current open drawings, browse to the blocks in the relevant drawing & drag-n-drop the block you want.

Yes, absolutely. Which is where some of the bloat comes from. The other source, which is what I harp on, is the creation of anonymous blocks (the ones with A$... for a name). Not only do these cart along style definitions (similar to bound XREF's), but the hog up space in the block table in the drawing's header. To prove it to a few in my office, I created a drawing with just a block in it (prior to blocking it). Then I saved a version with the objects blocked and copied several times, then I did the same in a new drawing using the accelerator keys. The final drawing was considerably larger than the second, and tended to produce errors when AUDIT was ran on it. What errors did AUDIT find? Invalid handles and insertions on anonymous blocks.

[irneb]

On my computer, one is generally off by a tiny amount, on the order of 1.0e-16.
Thanks, now that puts it into "perspective" (not orthogonal - excuse the pun). I tried that and got a line with the following: (10 -1.0 3.67394e-016 0.0) (11 3.67394e-016 1.0 0.0) .... uhhh .... shouldn't that have been (10 -1.0 0.0 0.0) (11 0.0 1.0 0.0)?

True, the error is EXTREMELY small 1/10 000 000 000 000 000, you wont notice it except when using LISP - list & properties don't show that many digits. But that's at one unit, I generally work around 1 000 000 units and as you say every edit adds another of those errors on top of the previous - similar to the compound interest idea where you take out a loan for 20 years and end up paying 4 times as much.

What's strange though is that my original problem was when using OFFSET - no polar tracking involved. Although the lines were probably drawn using polar tracking to start with. Sorry to see that particular feature discontinued in my set of "allowed" AutoCAD commands - yet another to avoid like the plague!

[irneb]

Doing a lot more investigation into this, I think I've finally figured out what's going on:
When AC uses polar (tracking or with @Distance<<Angle), it generates the point by using the trigonometry formulas Sin/Cos/Tan. Now for these to work properly (and seeing AC is written in C++) it needs to first convert the Degrees to Radians - C++'s trigonometry functions use radians instead of degrees. So if the user types in 90 as the degrees, the resulting angle is actually calculated as Pi(90/180) = 1.570796.... radians. From this it can never be truly saved as a right-angle. Since the value for Pi is not exact (especially if you also consider that 16 digit problem).

So here's why the error becomes more than just the 16 digit accuracy problem:

The value used for Pi is not absolutely accurate - probably already off by the 16 digit error (at best - depends on what C++'s constant value is for Pi).
The multiplication and division used to convert degrees to radians makes for another 16 digit error.
Then finally the polar function (using Sin/Cos/Tan) for ACad causes another 16 digit error on top of that.Then of course you start using points for reference which already contain this error, then compound these for the next point. In this way the 16 digit error grows to such a proportion that you have errors in the order of more than one unit.

Just figured out that the same applies for the use of LWPolylines. Their internal structure uses polar dimensioning: Distance<Angle+/-Bulge. The older 2D Polylines use lines and arcs as sub-entities of the polyline. So even if you've drawn a LWPolyline using only coordinate points or Ortho lines - you end up with these errors (worse for each consecutive vector in that PL).

Me thinks I'll have to set PLINETYPE=0 and use CONVERTPOLY extensively to revert to 2dPolylines. After which I'll have to fix the errors for these polylines - hopefully they then stay fixed.

[Wile E Coyote]

I was just about to create a new post but before I do, I'll see if my problem is related to this one:-

I use construction lines a lot at work, mainly to line up elements in plans, views etc.
I noticed a problem yesterday but didn't get to the bottom of the problem until today. Although I've got ortho on, construction lines (Rays etc.) aren't at 90 degrees they are off "slightly". This wouldn't be a problem over short distances on a mechanical detail say, but over longer distances - between views of a site - the problem shows up.

[dherbstr]

Wile:

Can you use the XLINE command to substitute for your construction lines?

[s_morgan_b]

An earlier post made mention of the floating point that autocad utilizes.

The further you get away from the 0,0,0 origin, the more the floating point comes into play. This means that end points may be a fraction away from each other. They look the same but they will not actually meet.

A good example to show this is using the concrete hatch. Create a boundary and hatch it at or near 0,0,0. Next, do one over around the 5,000,000 mark and note that the hatch is "fragmented".

[irneb]

An earlier post made mention of the floating point that autocad utilizes.

The further you get away from the 0,0,0 origin, the more the floating point comes into play. This means that end points may be a fraction away from each other. They look the same but they will not actually meet.

A good example to show this is using the concrete hatch. Create a boundary and hatch it at or near 0,0,0. Next, do one over around the 5,000,000 mark and note that the hatch is "fragmented".For that reason it's best practise to use 0,0,0 in the drawing as a basepoint unrelated to the true word coordinates. To obtain a "siteplan" on some "true" coordinate system you could then always just xref that "building" into the site at its "correct" position. If you don't like xrefs for this, then do the same as if it was a block - basepoint close to geometry of block (instead of 100's of miles off to the side). But even in such case I tend to pick a point close to / on the site boundaries as the 0,0,0 of the DWG where I actually draw them - for coordinating points I then xref that into a "special-case" DWG which is used for only that purpose. Changing your UCS doesn't help, since all you're really doing is introducing yet another conversion error on top of what's already there. For me (in architecture) it works since coordinates are probably 0.001% of my work - for the rest I want dimensions to work out & not show some arb fraction where there shouldn't be one!

It's not just hatches which have these issues, it's the actual linework itself. If it was only hatches - it is possible to set each hatch's base-point - which alleviates the fractioning.

I keep on finding that people misunderstand the concept of 0,0,0. You don't necessarily want to insert/attach at 0,0,0 - you rather want to DRAW FROM 0,0,0. Insert or attach @436457673367,23434343634,585656 and rotate @23.456789 makes for a lot less inaccuracy than trying to DRAW in that particular UCS.

And Rays & Construction lines still have this problem as well - especially when drawn in such UCS.

Thus: draw as close as possible to WCS's 0,0,0 and try to stick with ORTHO lines on the WCS. Create a block / xref if you have to place the combined result in a different position and/or rotation.