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]" <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:	<alpine.DEB.2.00.1601050404350.9035@igor2priv>
References:	<CAC4O8c_p5bMB1cKzDEsQFSnbZvY3TgnczH94pO_qCoJmiv2iWQ AT mail DOT gmail DOT com>
	<CAJXU7q9rMcQpLU5020RoZTqskT4moOS6f3Ugw+g3_mhO565MLg AT mail DOT gmail DOT com>
	<CAC4O8c-nPx1isS2DA4=X1vQFVY51vQ6pAY6sSfHBMog_m0_2dg AT mail DOT gmail DOT com>
	<CAJXU7q8jLiY2oAGmkgfXfzdNoAg2xVRx8bxgAXyF_qqYs=9Dgw AT mail DOT gmail DOT com>
	<CAC4O8c8=Vh7DcVrdrG4GE7ssBNG_VuxDLw2JSyg=Bv7Lnvfysg AT mail DOT gmail DOT com>
	<CAJXU7q-iNx7PVbZHe_SC+VGs1SN-zOSPEyQjBc6CS2qD8wnpvw AT mail DOT gmail DOT com>
	<CAC4O8c8sm-jp7+jvV_QJ9Zskwb31JsmPUA+BY2UkUMg31_Htsg AT mail DOT gmail DOT com>
	<CAJXU7q_K3xSdNWaZy3AZ_zCCAGWjvasc8TrJYrD5xz-CZujYDA AT mail DOT gmail DOT com>
	<CAC4O8c_=Hch0ttt56fyfTFaw+tcpsNG9ZA9wyfeLCynK=Bqp0A AT mail DOT gmail DOT com>
	<CAJXU7q8eto_ByskRgpQJB47YjEqOc5vaXwQ-7tGsQfefC403eQ AT mail DOT gmail DOT com>
	<201601041946 DOT u04Jkn25014629 AT envy DOT delorie DOT com>
	<CAJXU7q831fi7+iNYD_9J75y3cjAp1__Ao8nHewuz1emNYYrvUg AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1601050404350 DOT 9035 AT igor2priv>
X-Mailer:	Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version:	1.0
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

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.

- Raw text -