X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=czD5Hr8bSrl7cB7FnLDbxNZ9coAAMwJ2evgdJEnpx84=; b=bJcGfQC2A6yxRB7NLhZkfXnDm0IQ0US7anTAGCs4x4E04eon1c05/Tv2FXFGW2LwwX wDBLtDu8rameeIoWE14esyWpQdg3jDGnoHKiRkcj4u+DUIo4UorQ/ruWnM0T/5Z6EZXP q/LJE+BXMoaY6jwbYjS69u634jYDUM52YdmM9jaE27ECI/IKEoqqFANDlEtN41ntWF6H ewTlvv8mmDyxEBQVfYFq99WFdxJudmV+PwK4suctKbnot9Vz96h/XorETuuCMdQESye0 od8bYET8/sNfJC0iQIsHGxBlsl7QCZa2MkjuiZ5UC4Lac5IiolwkCBArSLDysIcWCu0S UnpQ== X-Received: by 10.194.109.194 with SMTP id hu2mr97081566wjb.134.1451976996469; Mon, 04 Jan 2016 22:56:36 -0800 (PST) Date: Tue, 5 Jan 2016 07:56:31 +0100 From: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] Merging stuff. How to make it happen (Geometric library) Message-Id: <20160105075631.9c23fc20d921e8f2c6427653@gmail.com> In-Reply-To: References: <201601041946 DOT u04Jkn25014629 AT envy DOT delorie DOT com> X-Mailer: Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u056uhZT022839 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Regarding geometric libraries http://www.cgal.org has an impressive developers list. Stephan Böttcher brought up clipper http://angusj.com/delphi/clipper.php a short while ago and started to write on a gerber file clearance checker http://www.psjt.org/code/drc/screenshot.png, have the project here http://www.psjt.org/code/ Nicklas Karlsson > >> > With regards rewriting geometry functions, I'd be interested in a why - > >if > >> > they already worked. The old code looking ugly would be a fine reason, > >just > >> > be extra sure the replacements will be well behaved ;) > >> > >> They were being duplicated all over the place.  We discussed this a > >> while back and agreed that collecting all the 2D/3D generic math > >> functions in one spot made sense. > > > >I'm drawing a distinction here between "collecting" and "rewriting". The > >later needs at least some justification. > > > > I am not sure about the state of the git head mainstream version, I'm > talking about pcb-rnd (forked from a 2013 verison of pcb). > > While working on the cycle drag and semi-related negative box selection, I > needed a few calls that decided whether objects touch an axis aligned box. > > I though there was some easy way to do this with existing infra, but > couldn't find anything trivial. I figured there were two problems: > > 1. There was no much generic geometric "does this line intersect that > circle" like code; instead, search.c has some IsPointOnLine() and co., > which take complex PCB object type as one end of the comparison. This is > totally fine for DRC, but if you want to implement something else and you > really need to check aritrary theoretical objects, they can't be reused. > > 2. Other parts of the code seem to struggle with this. The solution is, as > DJ said, is that everyone coded something locally. A random example is the > "rubber_callback()" that checks if a line touches a selection box. > > Since the coordinate type is an integer (I consider it sort of a fixed > point number, as it is in nanometer), and values are large, calculations > may overflow. E.g. assume signed 32 bit coords, you get about 2.1 meters > as max board size. Now look at rubber_callback(): at some point it does an > x*=x. This means x has to be wider than int32_t else the actual limit > comes down to sqrt(2.1). In that piece of code the "intermediate > calculation type" is double. This could work well with 32 bit coords as > double provides 53 bit base. However if the user configures pcb to use 64 > bit coords, this is not true anymore (although the board needs to be > ireally big to reach 53 bits). Theoretically we'd either need some > clipping on the int coord side or long doubles for intermediate > calculations. When converting between ints and floats, there may be some > system specific behaviour around rounding - some code doesn't seem to care > about this. > > For all these, I think it's reasonable to create a centralized, generic > (non-pcb-complex-type-oriented) geometry lib that could remove code > duplication, could centralize the solution for clipping/rounding. Ideally > the complex-pcb-type functions would deal with interpreting the types > and then call the generic geometry functions too. It could not only help > removing potential bugs but would ease adding new code that needs to deal > with geometry.