I'm not having any problems doing this, but I'm curious if there is a reason not to. say I am making a comparison: (a/b) > c, where b is zero According to my tests, a/b will be (what I interpret to represent) + or - infinity or NaN, depending on the sign of a. +infinity appears to be greater than any real number. -infinity appears to be less than any real number. NaN appears to be neither greater than nor less than any number. I just want to make sure these resutls will always be consistent (on windows).
I am not aware that GameMaker allows you to divide by 0. If it's working for you, my guess is that it's probably an undocumented feature, and you should avoid using it.
Please stop conducting these sorts of tests. The last thing we need is to tear a hole in the space-time contin-
Dividing by zero is not equivalent to infinity. It is undefined. The limit of the function a/b as b approaches 0 is infinite, and that is where the misconception comes from. That GM is not raising an error would imply that you are not dividing by 0, but more likely by 0.0000002 (as an example) as a result of using floats. Therefore, I would assume it is possible for b to equal -0.0000002 as well. Which would make your function inconsistent. Why do you want to divide by zero anyway?
I'm not too concerned about the definition of division by zero in mathematics, just how and if it is implemented consistently in gamemaker. I'm just taking advantage of a/0 = infinity (in gamemaker) to streamline some algorithms, and it is working fine, I'd just like to know that the implementation isn't going to be inconsistent. I'm only using them in comparisons.
But... it's not. In normal mathematics, or in gamemaker. I just tested it with show_debug_message(8/0) and I got a division by 0 error. The answer shouldn't be and isn't infinity. More to the point, gamemaker can't even express infinity, so what exactly are you trying to do?
I apologize, you're right. I had no idea that was possible. Regardless, I'm still curious about why you're trying to make use of this. I can't think of a single situation where dividing my zero is actually useful.
The goal is not to divide by zero, but to sidestep the consequences. I might show what I'm doing just as soon as I figure out for sure whether or not what I'm doing isn't completely foolish.
If you truly want to sidestep the consequences, surely something like the following would be better: Code: if (b==0) { if (a > 0) { aa = 999999999; } else if (a < 0) { aa = -999999999; } } if (aa > c) { // Whatever your goal is... } This way, you're avoiding funky divide by 0 maths entirely. I don't know what your (a == 0) case needs to be, because I don't know the context, but to me, this kind of solution seems safer.
Yeah, as I said earlier, dividing by 0 probably isn't safe. Even if it does work reliably, you have no idea of whether it'll still work several months down the road when new updates are released.
Yeah, that's just exactly what I'm trying to find out. As it turns out, my algorithm might have been flawed anyway, but for other reasons. I'd still like to know what standard exactly gamemaker is using, and whether it will remain consistent (at least on the windows platform).
Just have b default to some low number and you won't ever have a problem. Code: (a / (abs(b) < 0.000001 ? sign(b)*0.000001 : b) ) > c EDIT: fixed a mistake made while tired
Shouldn't that be: Code: (a / (abs(b) < 0.000001 ? sign(b)*0.000001 : b) ) > c ? This should probably work too: Code: (a / (b + ((b==0) * 0.000000000000000000001)) > c edit - maybe not
Yea, my bad. I was tired when I wrote the response. It should be Code: (a / (abs(b) < 0.000001 ? sign(b)*0.000001 : b) ) > c