Mixing variable types in RobotC expressions

About 3.5 billion years ago, when I first learned programming, I was taught never to mix float and integer variables in the same calculation. I was taught to re-cast the variables so they were all the same type before completing a “mixed” expression, since integers and floats are represented differently in the CPU.

Recently I noticed a student had rampantly mixed integers and floats throughout his program, and yet his robot seemed to work fine - um, well, most of the time. I then was told that C languages usually provide automatic “up-conversion” in mixed type arithmetic expressions, so an expression using both floats and integers will get the integers converted to floats.

But then I noticed the student had some while conditions that looked like **measurement != 0 ** in which measurement had been declared as a float. I was surprised that his code ever broke out of the while loop since the float was being compared to an integer 0 and I was guessing that a perfect match would be necessary to break the loop.

Anyway, I’m just wondering what RobotC does with floats and integers. Is it just super-forgiving in cases like this? or is an integer zero actually converted to something like 0.000 when compared to a float? and, if so, to how many decimal places, etc. ?

So starting from the top

C languages do provide automatic up conversion when needed. This can be used to do simple casting. The expression
5/2 computes to 2
1.0*5/2 computes to the float 2.5.

The comparisons act in the same way. The int is casted to a float. Floats are inherently less precise than an int so a comparison between an int and a float can result in a true return value. It is just a hell of a lot more likely if the float you are comparing is relatively close to the int. And what is considered relatively close changes based off of the size of the int. Float/ int comparisons don’t always fail or no one would fall into the trap. The thing that makes it need to be drilled into people’s heads is that it isn’t consistent from a human perspective.

That’s still true in C, just not to the same degree it was in Fortran, where your teacher or teachers likely learned the rule.

In Fortran instead of testing for zero, it used to be common practice to test that the absolute value of the variable was less than some small quantity near zero. That’s not typically done in C for a couple of reasons.

RobotC probably has some caveats of its own, however, C uses coercion to implicity convert from one type to the next. That’s why things usually work. Until they don’t.

I see lots of code posted in the forum here that relies on coercion (implicit type conversion) to work. Often, it’s clear the author didn’t know he/she was relying on a language feature they probably don’t understand in order for their code to work. Occasionally, there’s evidence the original author did understand coercion, but then the code is blindly copied without any thought to why it’s being done a particular way.

I’ll cite some examples later, gotta pick up a VEX team and head to a practice/lab session.

One important tip:
Coercing or casting a float into an int does not cause the value to be rounded. It is truncated instead. That’s a big difference, and some code won’t work as expected because of it.