When i run the software in the Nano, I see that the decimal MF is 38.9000015258 and not 38.9.
how can i decrease this "15258" to 38.9
i have tried to:
MFcorr = MF - 15258
but not work well
i appreciate all the help
ed
Simple: don't use floats. Use integer maths instead.
Instead of using the actual value, use the "milli" value. For instance, instead of volts (3.2V) use millivolts (3200mV). Instead of degrees C (25.6 DegC), use milliDegrees C (25600 mDegC). Instead of Hz (143.2Hz) use milliHertz (143200mHz)...
majenko:
Simple: don't use floats. Use integer maths instead.
Instead of using the actual value, use the "milli" value. For instance, instead of volts (3.2V) use millivolts (3200mV). Instead of degrees C (25.6 DegC), use milliDegrees C (25600 mDegC). Instead of Hz (143.2Hz) use milliHertz (143200mHz)...
+1
Instead of measuring in decimal-point meters that would be measuring in millimeters.
If you need 6 places then use micrometers (millions of a meter).
Just watch your variables.
int is good -32768 to 32767 which if all 9's gives you 4 places max (9999).
long is good -4294967296 to 4294967295 gives you 9 places of 9's (999999999).
long long (64 bit integer) gives you 19 places.
Put the decimal point in when you print the number out to keep your accuracy.
1002 mm = 1.002 m
1002 / 1000 = 1 .... print 1 then print .
1002 % 1000 = 2
2 / 100 = 0 .... print 0
2 % 100 = 2
2 / 10 = 0 .... print 0
2 / 1 = 2 .... print 2
That operation can be done in a while loop or a for loop.
Midway:
When i run the software in the Nano, I see that the decimal MF is 38.9000015258 and not 38.9.
how can i decrease this "15258" to 38.9
I agree with the suggestions to use fixed-point arithmetic instead of floats. However, the original problem you described is not really about the value of the expression - it is only about how that value is represented as a string. There are various ways to control how floating point numbers, and which options are available to you will depend on how you're doing that representation - which you haven't shown us.
I'll stick with Kernighan and Plauger: "Floating point numbers are like piles of sand; every time you move one you lose a little sand and pick up a little dirt."
If the errors occur at random, we might expect a cumulative error of sqrt(N) ?m. However, if we are not vigilant in designing our numerical algorithms, these errors can propagate in very unfavorable and non-intuitive ways, leading to cumulative errors of N ?m or worse.
When I worked on any code that involved money; billing, payroll, taxes, etc, I stayed away from floating point. When I coded for NC and CNC cutting machines, I stayed away from floating point.
Besides, Arduino has no FPU. Floating point crawls without an FPU. Even 64-bit integers is faster.
There is no correction. Just like when you convert 1/3 to decimal you get 0.3333333333..., there is no exact binary conversion from 38.9 base 10 to binary. You have to live with it or use integers, as has been pointed out. Welcome to computer science!
the selected frequency = 1 MHz (also with a strange number at the end "1192")
1.0000001192 = Freq
The strange number is .0000001192, which in your case is too small to affect the results.
Even if Freq equaled .9999998808 it wouldn't make much difference.
Midway, I wonder if you understand math or numbers?
20.0000400543 / 20 = 1.000002002715, the error is digits a float can't store but the print generates. A float (Arduino double and float are THE SAME) is only good to 6 or 7 digits which means you don't have 20.0000400543 but actually 20.00004. But SO WHAT?
30.0000782012 < 30.001 < 30.1 < 31.0
You have ranges like 46.25 to 170. 46.250099999 is less than 46.26 let alone 170!
The error is not significant. Where the digits are is more important than what the digits are.
If you need exact then use fixed-place integers.
And just BTW, I hope that you don't expect to measure 46.25 MHz and faster with an Arduino that runs at 16 MHz.