Jump to content
  • Advertisement
Sign in to follow this  
Gage64

Unity Divide by zero - not an error?

This topic is 3985 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I asked this as part of another post (here), but for this particular problem, I think I'm more likely to get answers here. I wrote some code that might occasionally divide by zero, but I only realized it after I wrote it. I then stepped through it with a debugger, and whenever a float was divided by zero, the result was something like 1.INF. In that particular code it doesn't seem to be a problem because those numbers are apparently not used (the numbers represent clip-space (and then screen-space) coordinates which are later clipped), but is it safe to do any calculations with these numbers? Am I just getting lucky?

Share this post


Link to post
Share on other sites
Advertisement
It's safe in the sense that your program will not die as a result of this. However, using these values will eliminate any hope of numerical stability in your program, so you should either make sure they don't appear, or design your program so that these values are correctly handled when they appear.

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
using these values will eliminate any hope of numerical stability in your program


I don't know if that part of the code needs numerical stability, but hopefully that will be answered in my other post.

Quote:
Original post by Evil Steve
I've also seen some pretty severe performance problems from using those "special" floating point values.


Could you please give some examples or point me to a resource that discusses this?

Thanks for the help so far.

Share this post


Link to post
Share on other sites
Quote:
Original post by Gage64
I wrote some code that might occasionally divide by zero, but I only realized it after I wrote it.


Might we see the code in question?

Share this post


Link to post
Share on other sites
Here is one such article, though it's rather old.

Unless you have floating point exceptions enabled (off by default) for division by zero, you will not get a fault as you would with integer division. You just get infinities, as you've observed.

Share this post


Link to post
Share on other sites
Quote:
Original post by Gage64
Quote:
Original post by Evil Steve
I've also seen some pretty severe performance problems from using those "special" floating point values.


Could you please give some examples or point me to a resource that discusses this?
I don't have any resources really, I had some raytracing code that wasn't working correctly and causing divisions by zero. That code took 4 times longer to run than the code that was correct and didn't cause division by zero (Although the code complexity was pretty much identical). This is probably an extreme case though, since I was doing thousands and thousands of floating point calculations.
I assume it's throwing floating point exceptions, and I know you can turn them off, but I never got around to testing that.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Might we see the code in question?


Here it is:


Vector2 project(const Vector3 &p) {
// Perspective projection
float x = p.x * distanceToCamera / (p.z * aspectRatio);
float y = p.y * distanceToCamera / p.z;

// Viewport mapping
int w2 = width / 2;
int h2 = height / 2;
return Vector2(x * w2 + w2, -y * h2 + h2);
}



This function takes a vertex in view space and projects it to screen space (it's part of a software renderer I'm working on).

Initially I didn't do any clipping to the near clipping plane (but I did do clipping in screen space). When an object moved behind the camera, I sometimes got inverted projections (because of the division by negative Z), and sometimes the program crashed, but I thought the crashes were normal because they were caused by a division by zero. When I added clipping to the near clipping plane, everything worked normally.

However, in my renderer, I calculate the view-space and screen-space positions before doing any clipping (I am basing the architecture of my renderer on this article), so I realized that I can still get a division by zero, but the crashes stopped. Now that I think about it, I don't know what was causing them (I don't have the old version of the code so I can't check).

The article doesn't say anything about this either. Maybe I should send the author an e-mail...

So I'm basically wondering if this will cause a problem, either with performance or with program correctness in general. If you need to see more code, let me know.

Share this post


Link to post
Share on other sites
Be careful with this, though.

On a technical c++ note, the result of divide by zero is undefined behavior. Specifically:
Quote:
If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression (5.19), in which case the program is ill-formed.
[Note: most existing implementations of C++ ignore integer overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point exceptions vary among machines, and is usually adjustable by a library function. ]


In other words:

Your implementation *may* give you an INF.
Your implementation *may* give you an NAN.
Your implementation *may* throw an exception.
Your implementation *may* let you adjust the behavior using library functions.
Your implementation *may* yield "3" (or any other number) and carry on like nothing happened.
Your implementation *may* have different results every time you run it.
Your implementation *may* have different results in different builds.
Your implementation *may* call abort() or terminate().
Your implementation *may* crash the machine.

Any code you write that depends on the behavior of your particular compiler and/or chipset, and is non-portable.


In this case, you can let the floating point exception happen, and take the appropriate performance penalty of 1.INF computations. But it is NOT a portable behavior, it isn't guaranteed to work in the future or on other compilers, and it is NOT a "correct" program (as you mentioned in the post above.)

Share this post


Link to post
Share on other sites
Quote:
Original post by frob
...


Well that's exactly what I was afraid of. I could check for a divide by zero, but that will cause a severe performance penalty and some of the benefits mentioned in that article (like the division by Z occurring simultaneously with the transformation) will probably disappear.

What bothers me the most is that the article doesn't say anything about this. I can certainly believe the author might rely on non-portable behavior, but in that case I think he should at least give a warning.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!