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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
