Traditionally you’d have to write float number = 1.23f; and the very important part was the f at the end. However when you use them in RobotC, it gives you an error for putting the f. And I don’t know if you should convert the float into an int when doing arithmetic with both variable types. In fact if I doesn’t matter, then why don’t we always use floats regardless if it’s being used as an int or not (I know that ints are used for counting and basic arithmetic where floats are use for more precision on calculations and here are other reason of course). If it doesn’t really matter then why don’t we have a “number” type that can use both ints and floats (specifically it recognizes a 1 as a 1.0). Your thoughts?
I don’t ever recall C working that way, and I’ve been using it since 1983.
You should read up on type coercion, but the short story is that ints will be converted to floats automatically and the result will be converted back to whatever is needed for the lvalue before it is used.This process is called “coercion” and it’s worth learning a few of the ways it can help and hurt. One important thing to remember is that when floating point type is converted to integer type, the fractional part is truncated; no rounding occurs.
Use the type “float” when you want a fractional or floating point number. Use an integer type when you’re counting something, performing integer arithmetic, or when you want a whole-numbered result.
Floats are not more “precise”, they’re just capable of representing fractional quantities. You shouldn’t use a floating point type to represent a quantity you know to have only whole-numbered values, since floats do a rather poor job of representing integers. Floats can’t represent all integers. If you use a float to represent an integer which you increase by one every time through a loop, for instance, you’ll find there are gaps and jumps in what integer values the variable can hold.
I didn’t mean floats are more precise but they allow for more precise measurements since they can go to decimals. And about coercion, when I tried it in my code it “messed up” somehow and gave back a value of 0. That’s why I’m weary when putting the two together.
@kypyro 's point is that they do not allow for more precise measurements. Let me give you a real-world example. You measure the length of a tabletop in meters and get 0.875 m and claim this is far more precise than I could record with only integers. I measure the same tabletop and get 875 mm, exactly the same precision. Precision with these numbers is not quite what you’re thinking it is.
What did you put in your code? Note what @kypyro said about coercion. Let’s say you do (x/y)*z - parentheses only for clarification here. What if x and y are int and z is a float. Now consider what happens if y>x. You get an int between 0 and 1, truncated to 0. Then you multiply that 0 by z to get 0. Most likely you’re running into problems like this. This is why you don’t want to code things like a joystick value cubed divided by 127^2. You need to be careful about how you handle the data types here.