Re: Floating-point bit hacking: iterated nextafter() without loop?

From: Daniel Vallstrom (daniel.vallstrom_at_gmail.com)
Date: 10/17/04 

Date: 17 Oct 2004 09:13:35 -0700

Ack! No replies! Bump. Or should I take the fact that there have
been no replies to mean that the program supplied in the first
post does work in practice?p

daniel.vallstrom@gmail.com (Daniel Vallstrom) wrote in message news:<629d1766.0410140214.7e5d39f2@posting.google.com>...
> I am having trouble with floating point addition because of the limited
> accuracy of floating types. Consider e.g. x0 += f(n) where x0 and f are
> of some floating type. Sometimes x0 is much larger than f(n) so that
> x0 + f(n) == x0. For example, x0 could be 2**300*(1.1234...) while f(n)
> is 2**100*(1.4256...). If x0 + f(n) == x0 I still sometimes want the
> addition of f(n) to x0 to have some effect on x0. A good solution seems
> to be to update x0 to the nth value greater than x0.

For the background to the problem, I forgot to say that f(n)>0 and
increases with n, i.e. n0<n1 -> f(n0)<f(n1). Also, the various
floating values involved aren't god given but rather some heuristic
measures. Hence, when you want to add f(n) to x0, it sometimes makes
sense to increment x0 n times instead of doing nothing when the
accuracy of the floating type is too small (i.e. when x0 + f(n) == x0).

> Something equivalent to this:
>
> for ( ; n != 0; n-- )
> {
> x0 = nextafter( x0, DBL_MAX );
> }
>
> The problem with the above loop is that it may take too long because n
> could be quite large. Moreover, very many such loops would be executed.

To see that the approach involving iterated nextafter() calls is
infeasible, consider that values of n could on average be around
2**24, like in the program in the first post. Each such n-iterated
nextafter() loop will take about a second to compute. Furthermore,
thousands or millions such loops could very well have to be executed.

[snip suggested solution to the problem]

Any input is appreciated. Regards,

Daniel Vallstrom