Re: gEDA-user: pcb crooked traces

[Armin Faltl <armin.faltl@xxxxxx>]

Karl Hammar wrote:
> The claims about floating point so far are:
>
> 1, they have too great rounding error
> 2, equality operator ("==") is unusful
>   
I assure you, this is a serious problem, not minor detail, at least in
mechanical CAD where everyone uses float or double. How I know this?
By programming mechanical CAD myself ;-)
> 3, integer arithmetics is for the performance of it
>
> Well, I/we have found out that
> 1, the rounding error is less than the size of an atom
> 2, so is any integers eqaulity operator when 1 == 1 nm
> 3, the gain isn't 100times, not even 10 times, it's a mere one digit 
>    figure, and the bottlenet is elsewhere
>
> Up to now my only intent in this has been to say "that claim is false", 
> nothing else. But now I'm starting to feel that using integers is 
> actually the root cause of the "jagged lines" and mil/mm problems.
>   
With floating point numbers you'll get jagged lines as well - you can't 
avoid
them there, even with great care. The jagged lines btw. do not only 
depend on
the internal model representation but to a big degree on the display 
implementation.
> On the downside for integers we have, if I may cite John Doty:
>
>   "There are subtle problems with carrying real number analytic
>   geometry into a discrete domain."
>
> So far I have not found any good reasons for using integers, and John 
> has presented a wery good one for NOT using them. If we can get rid of
> thoose "subtle" problems, we will have a more healthy program and it
> will also be easier for new developers to join (in that part).
>   
I respect John and many of his arguments but
"There are subtle problems with carrying real number analytic geometry 
into a discrete domain."
is not a good reason per se. There are other subtle problems with 
expressing positions
with limited accuracy.
For integer grids, the end point of lines etc. are on the grid *by 
definition*.
So you can state that something "is at that point" or it isn't, float: 
"chances, it's near here".

About accumulation of error I now found an example: just move stuff 
around many times
with floating point representation - it will drift off the "grid" a bit 
on every move, if you
just add the distances that came from the cursor positions. If there is 
an internal grid
(e.g. 1nm) and all visible construction grids are natural multiples of 
that, this cannot happen.
The optimal solution is probably to use the best of both, where appropriate.


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