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
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
