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