kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Apr 29, 2013 at 02:56:47AM -0500, Dick Hollenbeck wrote:
> Please state the file and line number please.

OK, one example: 

In PCB_BASE_FRAME::GlobalChange_PadSettings (pcbnew/globaleditpad.cpp)
on line 232 pad_orient is computed from the pad orientation and the
module orientation. pad_orient is an int.

Later in the function it's used for pad->SetOrientation (after being
used for filtering), so it loses precision. You could say that's a bug
in the global pad dialog, but shifting the blame doesn't fix the
problem.

In DRC::doTrackDrc the angle is computed using ArcTangente which returns
an int. Not strictly related but it helps (given that just the other day
someone talked about numeric instabilities in the DRC). Again, probably
nobody would notice it since tracks are mostly multiple of 45 degrees.
However in DRC::checkClearancePadToPad the bounding pad polygon is
computed from the truncated angle so it could possibly give wrong
results (maybe with huge pads :D)

> The rest is bullshit.

Your opinion, not mine. I hope somebody else think the same of me.

If angles are defined to be integers you can (usually) put them in
doubles; if angles are 'promoted' to doubles and you actually *can* have
fractional angles (i.e. fraction of decidegree) you should check that
they aren't truncated on the way (when it matters; for screen drawing
probably a truncation is not significant). Otherwise you could simply
say that the resolution is one decidegree and use a double for
convenience (but then why promote it to int in the first place?)

Just decide what an angle is.

-- 
Lorenzo Marcantonio
Logos Srl