X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 5 Jan 2016 04:27:33 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Merging stuff. How to make it happen
In-Reply-To: <CAJXU7q831fi7+iNYD_9J75y3cjAp1__Ao8nHewuz1emNYYrvUg@mail.gmail.com>
Message-ID: <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>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-308620398-1451964453=:9035"
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-308620398-1451964453=:9035
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE



On Mon, 4 Jan 2016, Peter Clifton (petercjclifton AT googlemail DOT com) [via geda=
-user AT delorie DOT com] wrote:

>
>
>On 4 Jan 2016 19:48, "DJ Delorie" <dj AT delorie DOT com> wrote:
>>
>>
>> > 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.=C2=A0 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=20
talking about pcb-rnd (forked from a 2013 verison of pcb).

While working on the cycle drag and semi-related negative box selection, I=
=20
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=20
couldn't find anything trivial. I figured there were two problems:

1. There was no much generic geometric "does this line intersect that=20
circle" like code; instead, search.c has some IsPointOnLine() and co.,=20
which take complex PCB object type as one end of the comparison. This is=20
totally fine for DRC, but if you want to implement something else and you=
=20
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=
=20
DJ said, is that everyone coded something locally. A random example is the=
=20
"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=20
point number, as it is in nanometer), and values are large, calculations=20
may overflow. E.g. assume signed 32 bit coords, you get about 2.1 meters=20
as max board size. Now look at rubber_callback(): at some point it does an=
=20
x*=3Dx. This means x has to be wider than int32_t else the actual limit=20
comes down to sqrt(2.1). In that piece of code the "intermediate=20
calculation type" is double. This could work well with 32 bit coords as=20
double provides 53 bit base. However if the user configures pcb to use 64=
=20
bit coords, this is not true anymore (although the board needs to be=20
ireally big to reach 53 bits). Theoretically we'd either need some=20
clipping on the int coord side or long doubles for intermediate=20
calculations. When converting between ints and floats, there may be some=20
system specific behaviour around rounding - some code doesn't seem to care=
=20
about this.

For all these, I think it's reasonable to create a centralized, generic=20
(non-pcb-complex-type-oriented) geometry lib that could remove code=20
duplication, could centralize the solution for clipping/rounding. Ideally=
=20
the complex-pcb-type functions would deal with interpreting the types=20
and then call the generic geometry functions too. It could not only help=20
removing potential bugs but would ease adding new code that needs to deal=
=20
with geometry.


--0-308620398-1451964453=:9035--