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