[quote name='Mybowlcut' timestamp='1320651463' post='4881301']
I'm roughly familiar with epsilon comparison, but I was under the impression that it was a far smaller threshold than -1.5 (the value in question)? I'm also a bit confused as to how comparison relates to my problem when there are none taking place. If it was a smaller number (ie < 1), I'd understand...

The value [color="#1C2837"]-1.5308086E-15 actually represents something like -0.0000000000000153 - which is rather close to 0.

[color="#1C2837"]

You can think of the "E-15" as a shift of the decimal point. Its a short hand notation for extremely large or small numbers.

[color="#1C2837"]

The previous posters have linked some nice resources, especially rip-off's post.

[/quote]
Thank you for taking the time to explain it without being condescending, unlike certain people in other threads I've made... very helpful.

I'm roughly familiar with epsilon comparison, but I was under the impression that it was a far smaller threshold than -1.5 (the value in question)? I'm also a bit confused as to how comparison relates to my problem when there are none taking place. If it was a smaller number (ie < 1), I'd understand...

The value isn't -1.5.


http://en.wikipedia.org/wiki/Scientific_notation#E_notation

[quote name='Mybowlcut' timestamp='1320652023' post='4881304']
...Ok, so basically clamp to 0 if it's an acceptable margin of error?

It depends on the circumstances:

The value you're computing is a distance. If it is measured in meters and express the distance between 2 atoms then you shouldn't clamp it. But if it is a distance in meters between 2 people meeting at the streets a resolution of 0.001 is good enough.

You actually do a comparison by invoking assertEquals(0.0f, distance). For this you should use an Epsilon expression. For sub-sequent uses as transformation parameter you'll usually need not clamp the distance but use it as is.

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.
[/quote]
Hmm. I've been doing a bit of reading (I appreciate the links given, but I'm not mathematically minded and so opted for something with simpler examples) and it seems that my idea of using a fixed value for the epsilon wouldn't be a good idea. I'd like to use something like AlmostEqual2sComplement, but am not sure about two things:

1. How to do the same thing in Java (in terms of the dereferencing etc.)
2. What to use for maxUlps

Here is the [font="Courier New"]AlmostEqual2sComplement[/font] mentioned in the article:
bool 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 = *(int*)&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 = *(int*)&B;
if (bInt < 0)
bInt = 0x80000000 - bInt;
int intDiff = abs(aInt - bInt);
if (intDiff <= maxUlps)
return true;
return false;
}

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.[/quote]

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

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 [color="#1C2837"]-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.

[color="#1C2837"]Edit: A similar value results from an angle of 270 degrees ([color="#1c2837"]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.