Re: gEDA-user: pcb crooked traces

[karl@xxxxxxxxxxx (Karl Hammar)]

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.

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"?

> 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. 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).

Regards,
/Karl Hammar

---------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57




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