V5 Math Error

I made a program just for fun and it calculates 1/0. i alsways outputs 12. Anyone know why?

What a math function becomes undefined, for example 1÷0 = infinity, there’s a few choices of how to handle the issue. One is to simply let the processor hang forever because it doesn’t know what to do with it, or, the programmers can put in place some sort of error-handling condition such as posting a flag that the function is undefined, or in this case, it looks like returning the value of zero was done. Some would think that getting a value of zero back would be better than the brain just hanging.


See also:


i mispoke. it for some reason will always output 12.
does that chnge your responce?

1 / 0 is still infinity, but take a look at Mentor 355 answer. I can’t tell you why it gives you 12, one of the programmers will have to weigh in on that, but maybe if you post a snip of your code that is giving you the 12 someone might be able to figure it out

1 Like

Screenshot 2022-11-14 11.46.02 AM

As one of the posts to the Stack Overflow states:

Note that C standard says (6.5.5):

The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined.

So something/0 is undefined (by the standard) both for integral types and Floating points. Nevertheless most implementations have fore mentioned behavior (±INF or NAN).

Thus, rightly or wrongly, the C standard puts the onus on the user to avoid undefined behavior such as this. I have not tried this program on the V5 Brain, but compiling a simple:

#include <stdio.h>

int main() {
        int a=0;
        int b=1;
        int c=b/a;

And compiled against gcc 7.5.0 leads to a Floating point exception (core dumped), which is also seemingly strange behavior (how can integer math result in a floating point exception). This goes back to the programmer being responsible for avoiding undefined behavior from the compiler. You are responsible for defining (and programming) what the “right” answer is when dividing by zero on a case-by-case basis.

The standard VexCode makefile includes the -fno-exceptions which may be why this code doesn’t cause the V5 program to crash, which is arguably the correct behavior - I’m sure roboteers would rather their program continue working after a divide-by-zero than crash