[Haskell-beginners] High precision doubles

[Rafael Gustavo da Cunha Pereira Pinto]

oops:

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

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



On Thu, Jun 25, 2009 at 10:24, Rafael Gustavo da Cunha Pereira Pinto <
RafaelGCPP.Linux at gmail.com> wrote:

> 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 at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>
>
>
> --
> Rafael Gustavo da Cunha Pereira Pinto
> Electronic Engineer, MSc.
>



-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20090625/3f274a5e/attachment.html