Ok,
So i have been wondering about this for a long time now.
Whenever i want to divide a floating number with another, for example
float a=1024.0/3.0
or float a=1024.00/3.00
a is at most only 2 decimal places. What if i want larger numbers, as in more decimal places in the answer? what do i have to do for that?
PS: i have tried it on the Dues as well as Uno, they both behave the same.
Regards
Here you go. Serial.print() - Arduino Reference
psgarcha92:
a is at most only 2 decimal places
No it isn't - the float data type provides 6 - 7 digits of precision. But when you print the value, you're only printing it to two decimal places.
@HazardMind, thanks alot for that answer.
Guys, you would not believe what i found.
when you use the calculator in Windows, and divide 22 by 7
22/7=3.1428571428571428
When you use python and do the same,
22.0/7.0=3.142857142857143
When you do 22.0/7.0 on an Arduino mega:
22.0/7.0=3.142857074737548
On a Due,
22.0/7.0=3.142857074737549
On a Stellaris Launchpad,
22.0/7.0=3.142857074737548
Why are these values different than what the calculator and Python3 calculates? why these errors? Why are the Boards giving values so different?
Regards
psgarcha92:
@HazardMind, thanks alot for that answer.Guys, you would not believe what i found.
when you use the calculator in Windows, and divide 22 by 7
22/7=3.1428571428571428
When you use python and do the same,
22.0/7.0=3.142857142857143When you do 22.0/7.0 on an Arduino mega:
22.0/7.0=3.142857074737548On a Due,
22.0/7.0=3.142857074737549On a Stellaris Launchpad,
22.0/7.0=3.142857074737548Why are these values different than what the calculator and Python3 calculates? why these errors? Why are the Boards giving values so different?
Regards
Windows likely does the calculation in double precision, which has 53 binary bits of precision in the mantissa. On my Linux system, in double precision, it prints out: 3.1428571429. In general, with double precision, you will get 15-16 decimal digits of precision, and the exponent can go up to 1e307.
If you declare the variables float, it will do it in single precision, which has 24 binary bits of precision. On my Linux system, in single precision, it prints out: 3.1428570747. In general with single precision, you will 7-8 decimal digits of precision, and the exponent range can go up to 1e38.
Now, if you had declared the variables 'double', on the Arduino, it would still print out 3.1428570747, because the Arduino maps double into float. If you used double on the Due, it should print out 3.1428571429.
The difference in the last digit, is likely due to the way the library converts floating point to textual reresentations.
If you used a calculator program or standalone calculator, it may have done the calculations in base 10, rather than doing it in base 2, and converting to base 10 for output as computers do.
Some computers have decimal floating point arithmetic as part of the basic instructions (you have to use _Decimal32, _Decimal64, and _Decimal128 to get decimal floating point types instead of binary floating point type.). Some others have decimal floating point as an software only implementation. I would imagine most embedded chips do not have the decimal support in the library. FWIW, both the Due and the AVR chips do not have hardware floating point on the chip, so when you do calculations in floating point, it takes hundreds to thousands of instructions to do the floating point operation.
If you want to read up on the binary formats used in computers, that is defined in IEEE 754 (and 854). For a summary, go to IEEE 754 - Wikipedia.
I hope you're not considering all those representations of 22/7 as more or less correct representations of pi.... 8)
M_PI is defined in math.h. Good as anything, I suppose.
root@here:~# grep M_PI /usr/include/math.h
# define M_PI 3.14159265358979323846 /* pi */
# define M_PI_2 1.57079632679489661923 /* pi/2 */
# define M_PI_4 0.78539816339744830962 /* pi/4 */
# define M_PIl 3.1415926535897932384626433832795029L /* pi */
# define M_PI_2l 1.5707963267948966192313216916397514L /* pi/2 */
# define M_PI_4l 0.7853981633974483096156608458198757L /* pi/4 */
better take 355.0/113.0 = 3.1415929... as approximation, slightly more difficult to remember but far more precise than 22/7,
the next better approximation of PI by a "integer division" is involving 6 and 5 digit numbers
a small python script to find more accurate pi approximations and you see the sudden jump in digits after 355/113
error = 10.0
for n in range(1,n):
x = round(math.pi * n)
p = x / n
if abs(p - math.pi) < error:
error = abs(p - math.pi)
print x, "/", n, "\t", error
start of output
3.0 / 1 0.14159265359
13.0 / 4 0.10840734641
16.0 / 5 0.0584073464102
19.0 / 6 0.0250740130769
22.0 / 7 0.00126448926735
179.0 / 57 0.00124177639681
201.0 / 64 0.000967653589793
223.0 / 71 0.000747583167258
245.0 / 78 0.000567012564152
267.0 / 85 0.000416183001558
289.0 / 92 0.000288305763706
311.0 / 99 0.000178512175652
333.0 / 106 8.32196275291e-05
355.0 / 113 2.66764189405e-07
52163.0 / 16604 2.66213257216e-07
52518.0 / 16717 2.62610550639e-07
...
104348.0 / 33215 3.31628058348e-10
208341.0 / 66317 1.22356347276e-10
312689.0 / 99532 2.91433543964e-11
833719.0 / 265381 8.71525074331e-12
1146408.0 / 364913 1.61071156413e-12
3126535.0 / 995207 1.14264153694e-12
4272943.0 / 1360120 4.04121180964e-13
5419351.0 / 1725033 2.22044604925e-14
I imagine OP is using 22/7 as an example because it's a simple test of the accuracy of a floating point calculation system. Since 22/7 = 3.142857 142857 142857... ad infinitum, it's easy to know if your system got it right.