Line Length Accuracy

[Anonymous]

Is it possible for a lisp routine to measure line length accuracy more/less precise than AutoCAD itself when the precision in AutoCAD is set to its highest? The reason I am asking, we have a lisp routine that exports line lengths to an Excel spreadsheet and separates into differing categories based primarily upon line length (as far as I know). Although I am sure line entities have specific qualities other than length that could cause them to list differently (i.e. - handle, start/end point, etc.), are there any other aspects of a line entity in AutoCAD, other than length, that could cause it to somehow affect the listing of the lines length through a lisp that would cause this anomaly?

Many thanks!

[Kent1Cooper]

How does the routine find the length to report it to Excel?  Depending on how it does, you may be able to force it to use any level of precision you want.  And it may "know" the precision to a greater degree than it "shows" in display.  Here's what the Command:-line display shows as the Length property of a certain Line [as a VLA object] under my current Units precision setting:

Command: (vla-get-length obj)
7.77817

A LIST command on it returns [in part]:

Length =0'-7 3/4"

also because of my current Units and precision settings.

But it "knows" its length to a far greater precision than that:

Command: (rtos (vla-get-length obj) 2 17)
"7.778174593052022"

So if you can feed out the result of an (rtos) function, you can tell it what precision you want, regardless of how it shows it to you on-screen.

[dgorsman]

Is this a *very* minor difference?  If the length is calculated, particularly where the line varies across more than one axis, it may generate minor differences for different calculations.  Equality tests for floating-point calculations (such as length) should include a fuzz factor to account for this.

[Anonymous]

The lines being measured are simple individual line segments with one start point and one end point, and not even that long in reality. I have stripped down the drawing to a minimum of drawing elements in order to isolate the problem so these lines are close to being the only items in the drawing except for a few other simply objects necessary for the entire program to work. I am not exactly sure how the lisp routine measures the length of the lines since the measuring function is small part of the overall program created by someone else. I may have time to search the program and discover this later. Being slightly familiar with lisp, what would be some of the most basic functions for measuring lines like this that I have described? Seeing that this part of the program is so minute, I am fairly sure the function would be the most basic way of accomplishing this in lisp.

[Kent1Cooper]

---

@Anonymous wrote:

.... I am not exactly sure how the lisp routine measures the length of the lines since the measuring function is small part of the overall program created by someone else. .... what would be some of the most basic functions for measuring lines like this that I have described? ....

---

Look for either a (distance function using the two ends of the Line as arguments.  Or, if it converts the Line to a VLA object, a (vla-get-Length function using the object name as an argument, or alternatively (vlax-get objectname 'Length).  [If you don't find any of those, there are other, more cumbersom, ways it could be done, such as applying Pythagoras's Theorem to the coordinates of the subtraction of one point from the other, or something, but that seems unlikely.]

[dgorsman]

The method of getting the length is less important than the means of comparison.  If checking to see if two lengths are identical (or any comparison of non-discrete values), the comparison should allow for the inevitable small differences that will crop up.

[Anonymous]

I guess I'm sort of going back to my original question with this reply but, would I not be able to set my decimal precision to its highest mark and see from listing the two lines if there was actually any difference between their distances that would result in them being seperated into differing length categories in my spreadsheet, or, would I have to use some kind of lisp function that would do this more accurately? I guess what I am trying to determine is if it a length difference at all that is causing them to be separated at the processing to Excel juncture, or if it could possibly be another characteristic of the line entity that is causing this, such as a "comparison" function that you mentioned. FYI - I did have time today hurridly search the entire program lisp for the distance functions and the vl* functions. Found several distance functions but no vl* functions such as those mentioned in the earlier reply.

[leeminardi]

The lenght of a line is not stored with the line object.  It is a calculated value.

Both AutoCAD and VisualLISP use double-precision real numbers for line coordinates and calculations.  This means that coordinates have approximately 15 significant figures of precision.  AutoCAD will only show up to 8 decimal places.  To check the precision of calculations beyond 8 decimal places you could move geometry to be further from the WCS origin.  For example, set unit precision to 0.00000000 (8 places).

Add a line from 10002.8765432198, 0 to 10000.9876543219, 10000

Excel gives the calculated length between the two points as:10000.0001783951

Using LIST or DIST the length will be displayed as: 10000.0001784  

Setting the ends of the line with VLSIP and then caluculating the length

(setq p1 (getpoint "\nGet end #1"))

(setq p2 (getpoint "\nGet end #2")) 

(setq d (distance p1 p2))  yields 10000.0

However, this is not the full precision of d.  If you subtract 10000 from this value you  will get the rest of the precision.

(setq dd (- d 10000)) yields 0.000178395

Which agrees with the Excel calculation to 14 significant figures.

[Anonymous]

With a bit more searching I was able to find a lisp routine that calculates the length of the lines in question to a greater degree of precision and found them to be a different length (599.9999999999963 compared to 600.0000000000008). I have conducted tests to determine how the lines could have resulted in these minute length differences and have found that trimming, stretching, scaling by reference, and lengthening the lines length do not alter their true length as far as AutoCAD is concerned, and I know that the user would not have purposely drawn the lines at this level of precision. It may have been caused by a mis-pick of the mouse or an osnap issue. At this point I think it might be best to treat the symptoms rather than trying to look further for a cure so I am in search now of a more precise Lenthen command that will allow the user to "true-up" the subject lines in other that they match. The standard AutoCAD Lenthen command does not alter the line length at this level of precision. Does anyone know of such a routine, or how to create one in LISP?

[Kent1Cooper]

---

@Anonymous wrote:

.... It may have been caused by a mis-pick of the mouse or an osnap issue. .... I am in search now of a more precise Lenthen command that will allow the user to "true-up" the subject lines in other that they match. The standard AutoCAD Lenthen command does not alter the line length at this level of precision. Does anyone know of such a routine, or how to create one in LISP?

---

That seems a likely cause.  As for fixing things drawn that way, do a Search for words like "regularize" or "force to grid" or other wordings that can help you find topics like adjusting all Line endpoints to the nearest grid position that's a clean multiple of whatever increment you specify.  There are several such routines on these Forums, probably mostly in the Customization area.  They have their limits [e.g. they won't "clean up" the length of a Line that's not orthogonal, if what they do is adjust endpoints to grid positions], but you may well find something that will correct most conditions.