I am reading this and still don't understand what is the question. You should never operate two floating point numbers expecting to result zero. Period.<br><br>Floating point numbers are intrinsically imprecise. Every time you write an interactive process with floating points in the exit conditions, you should use some tolerance, either relative or absolute. <br>
<br>Absolute exit condition:<br><br>abs (xnew - xold) < epsilon<br><br>Relative exit condition (valid only when dealing with non-zero values)<br><br>abs ((xold+xnew)/xnew) <epsilon<br><br><br>If you cannot apply this, then either:<br>
<br>1) You are dealing with VERY small values, close to the minimal precision (2.2250738585072014e-308, on 64-bit doubles), <br><br>2) You are dealing with small and big numbers, differing by 37 orders of magnitude amongst them, when the small number will be set to 0<br>
<br>To solve this you should:<br><br>for 1) Scale your numbers... double, multiply by 1024, whatever, as long as they separate from the minimal precision. It is like putting your maze under a HUGE microscope!<br><br>for 2) Addition in situations as this one is like adding a pinch of salt on the ocean. For multiplications, try using Log-domain operations... That might work... Praying might work as well...<br>
<br><br><br>Where epsilon is <br><br><div class="gmail_quote">On Thu, Jun 25, 2009 at 09:17, Daniel Fischer <span dir="ltr"><<a href="mailto:daniel.is.fischer@web.de">daniel.is.fischer@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Donnerstag 25 Juni 2009 04:14:19 schrieb Sean Bartell:<br>
> > When adding a new node/hex to the graph/maze, I pick an existing node and<br>
> > get all of its neighbour co-ordinates, filtering out co-ordinates that<br>
> > represent nodes already present in the graph. The problem is that, due to<br>
> > floating point errors, these co-ordinates are not be exact. If hex A has<br>
> > the co-ordinate for hex B in its list of adjacent hexes, hex B would not<br>
> > necessarily have the co-ordinate for hex A in its own list. Things get<br>
> > mismatched quickly.<br>
><br>
> You won't be able to get it working easily with floating-point numbers.<br>
> Ideally, you would use integers for the code you're describing, then scale<br>
> them to the proper floating-point values later.<br>
<br>
Say the hexagons have side length 2, the centre of one is at (0,0) and one of its vertices<br>
at (2,0).<br>
Then the centre of any hexagon has coordinates (3*k,m*sqrt 3), for some integers k, m and<br>
any vertex has coordinates (i,j*sqrt 3) for integers i, j. So in this case, he could work<br>
with floating point values; using a large tolerance, he could build a gigantic grid before<br>
having false results.<br>
<br>
But of course, it is much better to use (k,m), resp. (i,j), as coordinates and translate<br>
that to floating point only for drawing.<br>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Rafael Gustavo da Cunha Pereira Pinto<br>Electronic Engineer, MSc.<br>