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.

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.

Absolute exit condition:

abs (xnew - xold) < epsilon

Relative exit condition (valid only when dealing with non-zero values)

abs ((xold+xnew)/xnew) <epsilon


If you cannot apply this, then either:

1) You are dealing with VERY small values, close to the minimal precision (2.2250738585072014e-308, on 64-bit doubles),

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

To solve this you should:

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!

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



Where epsilon is

On Thu, Jun 25, 2009 at 09:17, Daniel Fischer <daniel.is.fischer@web.de> wrote:
Am Donnerstag 25 Juni 2009 04:14:19 schrieb Sean Bartell:
> > When adding a new node/hex to the graph/maze, I pick an existing node and
> > get all of its neighbour co-ordinates, filtering out co-ordinates that
> > represent nodes already present in the graph. The problem is that, due to
> > floating point errors, these co-ordinates are not be exact. If hex A has
> > the co-ordinate for hex B in its list of adjacent hexes, hex B would not
> > necessarily have the co-ordinate for hex A in its own list. Things get
> > mismatched quickly.
>
> You won't be able to get it working easily with floating-point numbers.
> Ideally, you would use integers for the code you're describing, then scale
> them to the proper floating-point values later.

Say the hexagons have side length 2, the centre of one is at (0,0) and one of its vertices
at (2,0).
Then the centre of any hexagon has coordinates (3*k,m*sqrt 3), for some integers k, m and
any vertex has coordinates (i,j*sqrt 3) for integers i, j. So in this case, he could work
with floating point values; using a large tolerance, he could build a gigantic grid before
having false results.

But of course, it is much better to use (k,m), resp. (i,j), as coordinates and translate
that to floating point only for drawing.
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners



--
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.