result must be as : 100.58
but on serial monitor it is 100.00
float frequency;
frequency = 1000000/9942;
Serial.print("Freq: ");
Serial.println(frequency);
The compiler defaults to using integers for calculations. The division is done using integers, then the answer is converted from an integer to a float.
You need to tell the compiler that at least one of the numbers is a float, easily done as follows:
frequency = 1000000.0/9942.0;@david_2018
9942 value coming from reading pulse width
time_1_H = pulseIn(13,HIGH);
frequency = 1000000/time_1_H;
Serial.print("Freq: ");
Serial.println(frequency);
the result still 100.00
Is time_1_H a float?
Did you try the following:
frequency = 1000000.0/time_1_H;
1 Like
int time_1_H;
float frequency;
It was already explained to you that division of two integer types is done with integer division.
Just thoughts from my side:
a) if you do 1000000/9942 it could mean for compiler to do:
- do an INTEGER (not float) division as 1000000/9942 (the result is 100 (as INTEGER))
- now convert result 100 (INTEGER) to float (results in 100.0)
==> I am pretty sure this is what happens here: you do the division for values as int, but it converts int result to float afterwards (and losses all the decimal point results)
b) try this:
frequency = 1000000.0/9942.0;
Make sure the operands are already float and the division is a floating point division (not an int division).
or:
frequency = (float)1000000/(float)9942;
A typical problem to deal with different types, when is the conversion done... (behind the scene).
Also:
floating point number can be always a bit "off", incorrect: the floating point conversion cannot represent exactly the/any value. There can be "noise" (inaccuracy).
There are examples that a simple division goes "wrong", e.g. also in Python:
when float math goes wrong
One example is this coding style (with floating point numbers):
float a, b, x;
...
if ( (a / b) == x) {
This is NEVER true (will never match exactly)!
Floating pointer numbers are always a bit incorrect, the representation of their value can be a bit off (and also a bit random, on the lowest digits).
So, an exact comparison of the values with float will NEVER match exactly.
You have to deal with an "error range", to round values or to consider an "allowed" plus/minus offset (error) for a result in order to say it is "equal".
My suggestion at least:
make sure, the operands are already with the right type (here float).
Otherwise, compiler will do operation first as integer (losing all digital points) and then convert into float. It has to do also with operator precedence:
operator precedence
Here you see:
- the 1000000/9942 - the division - has higher precedence as the assignment (=), so, due to
integer numbers - the division takes place as integer numbers (without any decimal point result) - the lower precedence is the assignment, the =
now the conversion to float in order to assign and int to the float result variable happens afterwards
1 Like
@tjaekel
Thanks for detailed explanation
That is NOT true. Floats CAN be exact, depending on the value. But the odds of seeing an exact value, for any particular value, are low, because floats have limited precision. For example, some values can always be represented exactly, like 2.0, 0.5, and many, many others. But for the result of any real-world calculations to come out to any particular exact value are slim, due to the limite precision. A number that displays as 2.000000 is NOT necessarily ==2.000000. The actual value may be, for example, 2.0000001. This is why you should never use == with floats. Instead use something like:
if (abs(x - 2.000000) < 0.000001) { Do something here }
This will test to see if the difference between the actual value, and the expected value is very small.
A single-precision float, as used in all AVR-based Arduino processors, has a maximum precision of about 6.7 significant digits.
Sure, some value will match exactly but in general float numbers never match perfectly.
When I have used "never" I mean: do not assume it matches always exactly.
(I am sure the example you gave is exactly how to deal with this "problem")
We are talking about the same, just that my "generalized" (simplified) conclusion has exceptions ("it can match"). I tried to make it easier to avoid "traps".
I like "simplified, general rules" to avoid mistakes: and one is: "floats never match exactly" (never mind there are exceptions but who would deal with it as "when it could be accurate", sometimes, but when?).
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.