X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f X-Recipient: geda-help AT delorie DOT com Subject: Re: [geda-help] Weeding out rounding-error dot/lines? From: Richard Rasker To: geda-help AT delorie DOT com In-Reply-To: References: <1318794799 DOT 9014 DOT 61 DOT camel AT localhost> Content-Type: text/plain Organization: Linetec Date: Mon, 17 Oct 2011 21:40:51 +0200 Message-Id: <1318880451.3789.27.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1-2.2mdv2008.1 Content-Transfer-Encoding: 7bit Reply-To: geda-help AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-help AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Op maandag 17-10-2011 om 12:47 uur [tijdzone +0200], schreef Markus Hitter: > Am 16.10.2011 um 21:53 schrieb Richard Rasker: > > > I already defined a key binding for reporting net length, and now I > > found that the mil/mm rounding error sometimes causes problems in an > > insidious way: when an extra "mini-line" (dot) is created at a via or > > bend point, and this point is subsequently dragged along the line > > itself, the dot gets stretched into a line. > > If you copy/paste existing lines instead of using the line tool, no > mini-lines will appear. Also, don't pick lines at the ends if you > don't want them to stretch. The problem is that when laying down RAM data lines, I need to create and stretch loops and serpentine traces in order to match line lengths. Using existing lines in this process would make an already cumbersome process almost impossible to complete. And it's even rather trivial to create a script to find & destroy lines below a certain length in a .pcb file -- just search for lines with both X2-X1 and Y2-Y1 smaller than 2 units, like this one: Line[48819 247638 48819 247637 600 1200 "clearline"] The problem is that this isn't very handy, because I can only find the dots after the fact, not while they're created -- and lurk around, waiting to be stretched into lines, messing up length calculations. A fix would be rather desirable. The creation of these dots indeed seems to be caused by a metric rounding error, and can be reproduced like this: * Set the grid units to mm, with grid size = 0.1 mm * Draw a horizontal line, e.g. from [10.0000 10.0000] to [12.0000 10.0000] * Now move the cursor diagonally up from the end point, one step (0.1 mm) at a a time: [12.1001 9.8999]: OK [12.1999 9.8001]: OK [12.2999 9.7000]: OK [12.4000 9.5999]: OK [12.5001 9.5001]: stub line [12.5999 9.4000]: OK ... [13.2001 8.8001]: stub line ... It would seem that an inadvertent stub line is created when the last digit in both coordinates is 1, when starting out from a point with exact integer co-ordinates. If desired, I can do some more trial and calculation, and determine at which exact delta co-ordinate distances this occurs. Thanks for your reply anyway, Best regards, Richard Rasker