Hi. I have the following code:
int resistance = [SOME NUMBER BETWEEN 0 TO 1000, like 689]
resistanceValue = random(resistanceValue*0.9, resistanceValue*1.1)
What will happen when the resistanceValue are not integers? There's no explanation of this in the documentation and I have not been able to find a forum question on this matter.
Random takes longs for input parameters the .xxxxx is dropped.
Never used random() like that, BTW as that function requires integer (long, actually) parameters they'll be implicitly cast. So "resistanceValue0.9" is an integer going from 0 to 899, and "resistanceValue1.1" from 0 to 1099.
If you need decimals I think you could change it to something like:
float resistanceValue = 0.9*resistanceValue + random(0,3)/10.0;
Oh no, I don't need decimal points on the random output. Still, thanks!
why would you never use it like that ? implicit conversions are part of the language, it's OK to do it as long as you know what happens.
Yep, I know that! But I mean I've always used integer random values, never had to generate float ones (when decimals are needed, I know I can just divide by 10 or 100 or whatever precision I need).
Explicit casts are more clear for people that want to change your code (and your later self).
My C++ compiler puts warnings on them... (xcode on mac).
A lot of things are allowed in C. But not necessarily always good...
Indeed.
The spec states
Numeric conversions
Unlike the promotions, numeric conversions may change the values, with potential loss of precision.
...
Floating–integral conversions
- A prvalue of floating-point type can be converted to a prvalue of any integer type. The fractional part is truncated, that is, the fractional part is discarded. If the value cannot fit into the destination type, the behavior is undefined (even when the destination type is unsigned, modulo arithmetic does not apply). If the destination type is bool, this is a boolean conversion (see below).
so it's part of the norm and behaviour is fully documented.
But because it can lead to undefined behavior if the floating-point value cannot be represented as an integer value, indeed many compiler will raise a warning.
usual rules with companies I've seen:
When an expression contains operands of different built-in types, and no explicit casts are present, the compiler uses built-in standard conversions to convert one of the operands so that the types match. The compiler tries the conversions in a well-defined sequence until one succeeds. If the selected conversion is a promotion, the compiler doesn't issue a warning. If the conversion is a narrowing, the compiler issues a warning about possible data loss. Whether actual data loss occurs depends on the actual values involved, but we recommend that you treat this warning as an error.
When someone reviews your code, he will ask: did programmer realize that there is an implicit cast here?
Did the programmer realize that 10.8 will be changed into 10?
Could that be a problem?
If a simple (uint32_t) is added, it is immediately clear that the programmer did realize that a cast is needed.
It is 10 characters extra and it will save others (and you) time in the end...
agreed (almost you need to cast as a long, not an unsigned Long - so just int32_t or just long )
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.