Mail Archives: geda-user/2016/01/04/22:25:34
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--
- Raw text -