[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: pcb crooked traces

I don't think you are trying very hard. If the value input by the user in metric is rounded off to a value that is not exact, there is a loss of precision that can not be recovered no matter how "well programmed" the application is. I gave an example of when this would be significant and you seem to think that the programmer can make special cases to work around this. I'll lay it out again working in the abstract to show the possibilities. If you don't like the abstract, just adjust for a 0.8 mm pin spacing and you will see a real example that is close to the limit.
The user has a connector with metric spaced pins. When the metric value is input, the value is rounded off to the nearest 0.01 mil giving an error of 0.005 mil. At this point there is no way to recover that error, it is recorded in the system that way and the precision is lost. This value is used to calculate the position of all the pins in the connector resulting in an accumulated error of 0.005 * N. At 100 pins this the accumulated error is 0.5 mil. That may not be a show stopper, but I would prefer to avoid it if possible. At 200 pins the accumulated error is 1.0 mil, etc. Clearly this is quickly reaching a point of being very unacceptable.
Earlier you suggested that this can be dealt with by doing the pin position calculations in metric before converting to inches. Great idea, but who does the calculations? The user? The tool that generates the footprint? How do you educate the users so they all are aware of this problem so they can always work around it? I think this is a poor solution since it first requires that the limitation of the tool be known and worked around by everyone in the solution path. OR... the tool can be changed to remove the limitation by using 1 nm as the base unit which can represent both metric and inches ***WITHOUT ANY LOSS OF PRECISION***. It is that simple. Why adopt a messy, complex, error prone solution when a solution is available that deals with the problem simply, accurately and permanently? 

Rick


At 10:12 AM 10/10/2010, you wrote:

Rick Collins wrote:
While accumulation of error is an issue with floating point, the connector or any predefined 
shape is a particularely bad example:
At least I wouln't convert the spacing and then sum up the erratic value but convert all the original values, which gives exactly 1 conversion error per position, irrespective of the number of pins/position. And that's exactly how the read routines operate. To do it the wrong way, they would need to be fortune tellers, because there is 
no 'array' element in new-lib files.
Then please come up with some of your own. I am sure there is no shortage of examples just because I haven't thought of them.
I believe such an example will be hard to find in a well programmed CAD application. The reason is, that significant accumulation of discretization errors happens when 
nummerous small values get added to a large value or with small differences of
large numbers.
Typical examples for these problems are:

*) solving large badly conditioned linear equation systems
*) numerical treatment of initial value problems of ordinary differential equations 
*) statistical computations

Even for those apps there are algorithms that account for the problem -
skilled developers are aware of it and avoid it.
The general procedure in a CAD system is, to place "primitives" in a virtual
space with as few operations as possible and derive some data (screen view,
gerbers, drill coordinates,...) from this model as straight forward as possible, 
again involving only a hand full of operations per primitive. Since the
primitives are independent of each other, there is no accumulation of error.

One example of the tiny difference of large numbers is, to fill an area
with parallel traces, using the same trace width as center distance.
Depending on the display scale you might see chinks. As far as I know,
this is known bad practice. I'm not a developer of pcb, so if there
really are issues with this, others speak up please.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user