Adding and subtracting exact values to float

Question

Question:

The total amount of floating points is finite, there's about 2^32 of them. With a float, you can go directly to the next or previous one using java.lang.Math.nextAfter. I call that a single leap. My main quesion, composed of sub questions is, how can I navigate on floats using leaps ?

First, how can I move a float to another with multiple leaps at once ?

public static float moveFloat(float value, int leaps) {
    for(int i = 0; i < Math.abs(leaps); i++)
        value = Math.nextAfter(value, Float.POSITIVE_INFINITY * signum(leaps));
    return value;
}

That way should work on theory but is really unoptimized. How can I do it in a single addition ?

I also need to know how much leaps there's between 2 floats. Here's the example implementation for this one:

public static int getLeaps(float value, float destination) {
    int leaps = 0;
    float direction = signum(destination - value);

    while(value * direction < destination * direction) {
        value = Math.nextAfter(value, Float.POSITIVE_INFINITY * direction);
        leaps++;
    }

    return leaps;
}

Again, same problem here. This implementation isn't suitable.

Extra:

The thing I call a leap, does it have an actual name ?

Background:

I'm trying to make a simple 2D physics engine in Java and I have trouble with my floating point operations. I learned about relative error float comparison and it helped a bit but it's not magic. What I want is to be exact with my floating points.

I already know a lot of base ten numbers cannot be exactly represented with floating points but execptionally, I don't care. All I want is exact float arithmetic in base 2.

To simplify, in my collision detection and response process, I check if shapes overlap (let's stay in one dimension for this example) and I replace the 2 shapes overlapping using their weight.

See this example:

If the black lines are the float values(and the space between each other leaps) whatever the precision is, I want to place both shapes (colored lines) to be exactly at the brown position. (The brown position is determined by the weights ratio and by rounding. What I call penetration is the overlaping area/distance. If the penetration would of been 5, red would been pushed by 1 and blue by 4).

The problem is, do to that I have to keep the penetration of the collision (in this case the penetration is exactly the ULP of the float, or 1 leap) in a float and I suspect this leads to inexactitude. If the penetration value is bigger than the coordinates of the shapes, it will be less precise so they won't be exactly replaced at the good coordinate.

What I imagine is to keep the penetration of the collision as the amount of leaps I need to get from one to the another and use it afterwards.

This is a simplified version of the current code I have:

public class ReplaceResolver implements CollisionResolver {
    @Override
    public void resolve(Collision collision) {
        float deltaB = collision.weightRatio * collision.penetration; //bodyA's weight over the sum of the 2 (pre calculated)
        float deltaA = 1f - deltaB;

        //the normal indicates where the shape should be pushed. For now, my engine is only AA so a component of the normal (x or y) is always 0 while the other is 1
        if(deltaB > 0)
            replace(collision.bodyA, collision.normalB, deltaA); 

        if(deltaA > 0)
            replace(collision.bodyB, collision.normalA, deltaB);
    }

    private void replace(Body body, Vector2 normal, float delta) {
        body.getPosition().x += normal.x * delta; //body.getPosition() is a Vector2
        body.getPosition().y += normal.y * delta;
    }
}

Obviously, this doesn't work properly and accumulates floating point precision error. The error is well handled by my collision detection which checks for float equality using ULP. However it breaks when crossing 0 because of the ULP going extremely low.

I could simply fix an epsilon for a physic simulation but it would remove the whole point of using floats. The technique I want to use lets the user choose his precision implicitly and theorically should be working with any precision.

Answer 1

Underlying IEEE 754 floating point model has this property: if you re-interpret the bits as Integer, taking the next float after (or before depending on the direction) is just like taking the next (or previous) integer, that is adding or subtracting 1 to the bit pattern re-interpreted as integer.

Stepping n times is adding (or subtracting) n to the bit pattern. It's as simple as that as long as the sign does not change, and you don't overflow to NaN or Inf.

And the number of different floats between two floats is the difference of two integers if the signs agree.

If signs differ, since the float has a sign-magnitude like representation, which does not fit the integer representation, you'll then have to exert a bit of arithmetic.