Expecting calculation to be 0

Started by
19 comments, last by Mybowlcut 12 years, 5 months ago

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:

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

Advertisement

[quote name='alvaro' timestamp='1320699318' post='4881523']
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:

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

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.

[quote name='Mybowlcut' timestamp='1320699810' post='4881524']
[quote name='alvaro' timestamp='1320699318' post='4881523']
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:

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

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

This topic is closed to new replies.

Advertisement