Inaccuracy between lines

[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:

1. 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).
2. The multiplication and division used to convert degrees to radians makes for another 16 digit error.
3. 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.