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.