LISP routine not cooperating fully

[Anonymous]

I've been fighting with this LISP for a few days now.  I thought I finally had it right, but I've noticed it's not moving all the objects to the right layers.  In the attached drawing, the lines indicated by the arrows are on the wrong layer.  Those tow lines are supposed to be on the "Hilmot-Frames" layer, but the darn LISP routine keeps incorrectly putting just these two lines on the "HILMOT-ROLLERS" layer.  

The LISP is supposed to put ONLY the lines 1.9" apart on the Rollers layer.  The 2 incorrect lines are NOT 1.9" away from anything, so I have no idea what's going on, especially since it's just those two lines, which don't appear to have any "special relationship" to anything else in the block.

Can someone help investigate this?  Thanks in advance!

[paullimapa]

It works after I did a BlockEdit and Erased those two columns of objects where the Lisp fails on the Lines and copied the columns where the Lisp succeeds.

Now it works (attached revised dwg). So that tells me there's something different about how those columns of Lines are drawn vs the others.

Area Object Link | Attribute Modifier | Dwg Setup | Feet-Inch Calculator
Layer Apps | List on Steroids | VP Zoom Scales | Exchange App Store

[Ranjit_Singh · Accepted solution]

Hi @Anonymous try the attached.

[Anonymous]

Thanks to both of you for your responses.  Paul, I did notice a while ago that the listed angles of the vertical lines are not all the same...some are 90 and some are 270, so I suspect that's why your comment about messing with the individual lines helped.  

Thanks also to you Ranjit.  You've given me some new material to study 🙂

[Ranjit_Singh]

you are welcome @Anonymous. There are 2 lines of code that I changed. In general, anytime when comparing entity data of type float, it's a good practice not to use the entire 15 digit precision. That's when you run into issues with "=" operator failing to check 1.9000.... I typically use only 4 digits of precision but it depends on the routine and it's application.

[paullimapa]

glad to have helped...

Area Object Link | Attribute Modifier | Dwg Setup | Feet-Inch Calculator
Layer Apps | List on Steroids | VP Zoom Scales | Exchange App Store

[Anonymous]

Ha, ok...this is WAY over my head and doesn't make a lick of sense.  

I've been researching this today; I added PRINC statements so I could see what my version and the corrected version are doing.  For example, when comparing two identical lines from each program:

MY INITIAL VERSION:

#<VLA-OBJECT IAcadLine 000001cbfaf3e718>) ((21.0 39.0) (21.0 7.10543e-015) 39.0

The CORRECTED VERSION:

#<VLA-OBJECT IAcadLine 000001cbfaf43bd8>) ((21.0 39.0) (21.0 0.0) 39.0

Now, I can certainly see how the corrected version, with the extra added code (mapcar '(lambda (x) (atof (rtos x 2 2))) is helping to clean up the extracted values...BUT...why on earth is the bad version saying that the total length a line with endpoints (21.0 39.0) to (21.0 7.10543e-015) is still 39.0?  That's ridiculous!!!

[Kent1Cooper]

---

@Anonymous wrote:

....why on earth is the bad version saying that the total length a line with endpoints (21.0 39.0) to (21.0 7.10543e-015) is still 39.0?  That's ridiculous!!!

---

Not so ridiculous, it seems to me....  7.10543e-015 is 7-ish x 10-to-the-minus-15th-power, or about 7 quadrillionths of a drawing unit, which is almost as close to 0 as AutoCAD can get.

[Anonymous]

ooops...hadn't seen the NEGATIVE power.  Doggone it!