[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: pcb crooked traces
At 05:04 PM 10/8/2010, you wrote:
Rick Collins:
> At 02:28 PM 10/8/2010, you wrote:
> >Andrew Poelstra:
> > > On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote:
> >...
> > > > The only practical consideration I see is, that the
internal unit of PCB
> > > > allows handling with integer-arithmetic (makes comparisons a lot
> > > > faster and safer than floating point).
> >...
> >
> >That might be true, but if you are talking about an internal
> >representation with nm resolution, then you have the same problem as
> >for the floating point, there are too many separate values that
> >basically is the same value and you can't tell them apart looking at a
> >board.
> >
> >...
> > > I don't think we could reasonably use floating-point. There is no
> > > room for rounding error when designing tight areas of a PCB.
> >
> >That is nonsense, it is all about tolerances.
> >
> >1, going from physical components to footprint file is basically a
> > big averageing operation
> >
> >2, going from pcb-file to physical pcb is a big rounding operation
> > with some added noise, or do you believe you can make pcb's with
> > nm's precision?
>
> Yes, it is about tolerance... and error. How much error will be
> introduced into a design if the system rounds all metric measurements
> to 0.01 mils? How much tolerance is acceptable? When you can
...
Please, I was commenting about the misunderstandings about
"floating-point", not about mils and mm's.
With integer types you get aliasing artifacts, which actually is a
rounding error. We have this problem in the current incarnation of pcb.
That is what you aren't getting. The problem is not "aliasing" in
any way I understand aliasing. It is that you can't represent an
exact metric value in an inch system. When you multiply an arbitrary
number of few digits by 2.54 (convert inches to metric) you get two
or three more digits than you started with. Try dividing the same by
2.54 (convert metric to inches) and you get a lot more digits than
you started with, maybe infinite, I'm not sure. So in an inch based
system you will never be able to represent metric numbers
exactly. The opposite is not true, a metric based system can
represent an inch value exactly. So you will not get a round off
error of an input value. All points you need to calculate will be
exact and the jaggies won't happen.
This is not the same a finite resolution of a display or other bit
mapped output. We aren't talking about the pixels lighting up on a
CRT... er, LCD. We are talking about the end point of a trace not
being in the right position so that a 45 degree trace can not connect
them... exactly. That is what produces the jagged traces the OP
complained about, if I understand the discussion correctly.
So, in what way are floats worse than ints (I'm talking about
representaion, not about performance) and why could we not "reasonably
use floating-point"?
Floats aren't any worse if they have the resolution... but they
aren't any better either!
> There are other possible issues. When a metric input value is
> rounded off and then replicated, as someone said, for large
> connectors or mechanical attachments, the accumulated error can
> become significant and parts not fit.
...
> > > Suppose we stored a scaling factor in the .pcb files, of x10, x100,
> > > x254, etc? Then we could use nanometer precision by default and go
> > > bigger if we need a bigger board.
...
> >C, As a side note, if you use double's for the internal representaion,
> > then you don't loose precision compared to having an int32_t. You can
> > convert an int32_t to an double and back without loosing precision.
>
> The issue is not using singles or doubles. The issue is whether the
> base unit is metric (which can perfectly represent inch units of
> interest) or whether the base unit are inch based which can't
> represent inch units perfectly.
>
> I suppose they could always change the base units to some small
> fraction of a mil so that even the accumulated error would always be
> negligible. But why bother changing and only getting an
> approximation if you can get it perfect?
Ack. I know that using a basic unit of mm's or part thereof will solve
the mil/mm problem.
My point was that this does not have anything with integer vs.
floating points.
Ok, I agree. I guess all this was about nothing.
And I also hinted the reader that he/she could swap the
32bit ints for doubles and you would get the exactly the same results
(unless you divide of cause, then doubles comes out better).
Now I'm lost again... maybe. If you stick with inches, no, using
doubles buys nothing. The point about using doubles is that to use
metric, it seems like going with a unit of nm is appropriate. Then
you are limited to 2 or 4 meter max value with 32 bit ints. Going to
double resolves that problem by giving you another factor of 4
billion in your range.
I guess we are talking past each other while agreeing... yes?
Rick
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user