Mybowlcut

Very cool. I have had a similar idea for a while now - except in mine you could build traps to capture animals, use basic tools to hunt etc. Also, mine wasn't planned to be 3d. Which technologies are you using for this? Also, I notice that your names are Scandinavian? Where are you guys from?

In other words, your expectation of not losing precision in that process is unreasonable. Now, if the rest of your code is robust enough, whether you get 0 of -1.5308086E-15 shouldn't make much of a difference.

How would I ensure that it is? I'm assuming it's something to do with what haegarr said:

Notice that small errors may become a problem when being accumulated. E.g. concatenating many rotations will yield in a non-uniform scaling deformation because the small errors summed up will leave you with a non-pure rotation. If you have a situation like that you need to be up against it. Another situation is where precision plays a role, e.g. at marginal cases in point in polygon tests. In such cases you need to use precise data types and functions.

In the case of a rotation matrix that ends up not being orthogonal, you can re-orthogonalize it every few frames. If you use a quaternion it's actually easier to do.

Point-in-polygon tests are tricky. Ideally it should be the case that for a point on the border of the polygon it doesn't matter much whether you classify it as inside or outside.

Anyway, you didn't say what you will do with the result, so it's hard to tell if you'll run into trouble. You should educate yourself about how floating-point numbers work. There's just no way around it.

The function in question will be used for entity movement throughout a level.

The 'What Every Computer Scientist Should Know About Floating-Point Arithmetic' is beyond my knowledge of math. I'm satisfied with the result of this thread anyway - it seems that it's inescapable so I'll let it be until it actually affects the game.

Values directly along the x axis do return 0 if you measure along the y axis. The problem is that you cannot represent pi/4 exactly as a floating-point value, and you don't get something that is directly along an axis if you take another axis and rotate it by an amount that is close to pi/4 but not quite pi/4.

Oh, ok. Probably had a lot to do with the fact that I thought the value I was getting was larger than it was, as well. :s

In other words, your expectation of not losing precision in that process is unreasonable. Now, if the rest of your code is robust enough, whether you get 0 of -1.5308086E-15 shouldn't make much of a difference.

How would I ensure that it is? I'm assuming it's something to do with what haegarr said:

Notice that small errors may become a problem when being accumulated. E.g. concatenating many rotations will yield in a non-uniform scaling deformation because the small errors summed up will leave you with a non-pure rotation. If you have a situation like that you need to be up against it. Another situation is where precision plays a role, e.g. at marginal cases in point in polygon tests. In such cases you need to use precise data types and functions.

Looking at the bit pattern makes sense if you are checking something like a relative error. If you want to compare to zero, checking if the absolute value is less than epsilon is actually much more reasonable.

What is it you are trying to do that requires checking if the number is 0?

If you look at the original post, I want to make sure that the method returns 0 and not -1.5308086E-15 for the y axis when an angle of 90 degrees is passed in. Everyone is saying it involves floating point comparison, so that's why we're discussing how to go about it.

Edit: A similar value results from an angle of 270 degrees (4.5924254E-15). What I want is for values directly along the x axis to return 0 during a calculation only involving movement along the y axis, as seen in my original post.

Java has a build-in function to get the bit pattern of floats: Float.floatToIntBits(float), so that
int aInt = *(int*)&A;
will become
int aInt = Float.floatToIntBits(A);

Ah, thanks for that. Now I've got:

public static float getYDistanceMovedBy(float amount, float rotation) {
    return Math.abs(amount) * (float) -Math.cos(Math.toRadians(rotation));
}

public void testGetYDistanceMovedBy2() {
    float amount = 25.0f;
    float rotation = 90.0f;
    float distance = Geometry.getYDistanceMovedBy(amount, rotation);
    int maxUlps = 10; 
    
    assertTrue(almostEqual2sComplement(0.0f, distance, maxUlps));
}

boolean almostEqual2sComplement(float a, float b, int maxUlps) {
    // Make sure maxUlps is non-negative and small enough that the
    // default NAN won't compare as equal to anything.
    assert(maxUlps > 0 && maxUlps < 4 * 1024 * 1024);
    int aInt = Float.floatToIntBits(a);
    // Make aInt lexicographically ordered as a twos-complement int
    if (aInt < 0)
        aInt = 0x80000000 - aInt;
    // Make bInt lexicographically ordered as a twos-complement int
    int bInt = Float.floatToIntBits(b);
    if (bInt < 0)
        bInt = 0x80000000 - bInt;
    int intDiff = Math.abs(aInt - bInt);
    if (intDiff <= maxUlps)
        return true;
    return false;
}

That article says:

maxUlps cannot be arbitrarily large. If maxUlps is four million or greater then there is a risk of finding large negative floats equal to NANs. If maxUlps is sixteen million or greater then the largest positive floats will compare as equal to the largest negative floats.

As a practical matter such large maxUlps values should not be needed. A maxUlps of sixteen million means that numbers 100% larger and 50% smaller should count as equal. A maxUlps of four million means that numbers 25% larger and 12.5% smaller should count as equal. If these large maxUlps values are needed then separate checking for wrap-around above infinity to NANs or numbers of the opposite sign will be needed. To prevent accidental usage of huge maxUlps values the comparison routines assert that maxUlps is in a safe range.

Is the maxUlps going to be variable or can I use a fixed value? How do I determine it in either scenario?