| Thread Previous • Date Previous • Date Next • Thread Next |
On 4/18/2012 4:23 PM, Dick Hollenbeck wrote:
On 04/18/2012 02:48 PM, jean-pierre charras wrote:Le 18/04/2012 20:25, Dick Hollenbeck a écrit :I am working on this today. My gut says this: Basically it comes down to the fact that we cannot describe an area larger than about 12 feet with the nanometer internal units.Jean-Pierre, Can you first look over the attached patch, then play with it. This basically fixes the crash, but I think there's more finishing touches that need to be done. I need to get back to work now. Thank you very much, DickI'll work on that tomorrow. I also make some tests. Under Windows I did now have crashes, but I had other issues. my opinion is with 32 bits integers we cannot handle more than something like 50 to 70 cm, with nanometers units. I noticed there are a lot of issues when calculating distance between 2 points. Assuming calculations are using integers, with 32 bits we can handle 2 meters distances only. if Xmax and Ymax are Y and Y difference between 2 points, only Y or Y max<= 1.4 meter, if sqrt( Xmax*Xmax + Ymax*Ymax) always< 2m. Because a distance is always>= 0, this means X and Y coordinates must have absolute coordinates< 70 cm. With margins around work area, and because Pcbnew and Gerbview use a page only with positive coordinates, the active area has a size< 50cm, roughly 20 inches, or A3 or B page size.
This in itself gives us another tool to reduce the impact of this problem. We could always offset the stored and loaded values rather than the actual drawing coordinates. This would remove the huge positive offset values when drawing and give us some more wiggle room. Although this may not be worth the effort because I'm sure it will require a significant amount of changes to get it to work properly. It may be better to finally bite the bullet and move to OpenGL as our graphics device and keep nanometers turned off until then.
We should do the calculation in double, and return the result as a double. The caller can then use that result any way it chooses, say storing it in something other than int, say double or long. There really is no hurry to scamper back into "int" until you actually have to store a coordinate in an object that you wish to retain. Otherwise working in doubles should be more common, should be the norm, delaying the conversion to "int" until the last possible moment. I thought there was a conceptual bug in the function Distance() this morning, and wrote a fix for it this morning. The biggest problem was that IN THERE, in "double Distance()" the result was being forced into an "int" then returned as a double. See attached.
Dick, thanks for fixing this. Wayne
Good software design should allow us to work through these issues. double Distance() is only one example of where unnecessary design steps were taken before. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
