Re: gEDA-user: pcb crooked traces

[karl@xxxxxxxxxxx (Karl Hammar)]

Rick Collins:
> 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:
...
> >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.
...

Maybe I should use the word "truncation" instead. I thought that 
the aliasing effect would make my point obious because most of you
have experienced it.

Wikipedia:
 "In signal processing and related disciplines, aliasing refers to an
 effect that causes different signals to become indistinguishable (or
 aliases of one another) when sampled."

> >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!

Agree, though there are corner cases e.g. x/3 gives truncation for 
integers, and big_value * big_value2 can give overflow where a double 
will thrive.

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

Yes, don't dissmiss floating-point on false grounds. If it is for the 
performance, fine, but then you have to test.

If ints and doubles comes out equally in a performance test, I'd choose
doubles, since arcs, sin() etc. is done in doubles (unless you are using
your own function tables).

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

Well, it buys me a little, but it is not the solution for the mil/mm 
problem.

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

Absolutely.

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