Today i needed to convert an array of 1's and 0's to a number (DEC, BIN or HEX, either would be fine). For that i created a function that should read every position the array and multiply it by 2 to the power of the position on the array.
(something like this -> x_*2^i)_ Problem is, for powers greater than 1, the pow function is returning wrong numbers (always the "correct answer"-1) the code: //##################### byte BinToDec(byte x[], int siz){
dec=0;*
for (m=0;m<siz;m++){*
unsigned int a =pow(2,(siz-m-1));*
unsigned int b = x[m];*
_ dec=dec+((b)*(a));_
}*
return dec;* } //###################### here is the code with some Serial.prints for troubleshooting. //###################### byte BinToDec(byte x[], int siz){
dec=0;*
Serial.print("\t\t");*
Serial.println(dec);*
for (m=0;m<siz;m++){*
Serial.print(m);*
unsigned int a =pow(2,(siz-m-1));*
unsigned int b = x[m];*
_ dec=dec+((b)*(a));_
Serial.print("\t\t");*
Serial.print(dec);*
Serial.print("\t\t");*
Serial.print(b);*
Serial.print("\t\t");*
Serial.print(a);*
Serial.print('\t');*
Serial.println(siz-m-1);*
}*
for (k=0;k<siz;k++){*
Serial.print(x[k]);*
}*
Serial.print("\t");*
Serial.println(dec);*
return dec;* } //###################### And some of the print returns:
0* 0 127 1 127 7 1 127 0 63 6 2 127 0 31 5 3 127 0 15 4 4 127 0 7 3 5 127 0 3 2 6 127 0 2 1 7 127 0 1 0 10000000 127 Sorry for the messy post, but can someone explain to me what is happening, and why is the pow function returning wrong data?
yeah, that is an easy way to go around the problem. But I am still curious why is pow() giving me those values.
I suspect it might have something to do with the variables i am using, as the parameters in pow() should be float, and maybe the difference is somewhere in the rounding of the result... Just a guess.
NEVER rely on floating point calculations to produce exact results. Due to the algorithms used to perform floating point arithmetic, they can only provide approximate results.
Jiggy-Ninja: NEVER rely on floating point calculations to produce exact results. Due to the algorithms used to perform floating point arithmetic, they can only provide approximate results.
Right.... "approximate results" having 6-7 significant digits, which is FAR more than the vast majority of applications ever required...
RayLivingston:
Right.... "approximate results" having 6-7 significant digits, which is FAR more than the vast majority of applications ever required...
Regards,
Ray L.
Even if it's only 0.000001% off, it's still an approximation. If you rely on floating point math to produce exactly equal results (such as comparing with ==), your code will fail.
Jiggy-Ninja:
Even if it's only 0.000001% off, it's still an approximation. If you rely on floating point math to produce exactly equal results (such as comparing with ==), your code will fail.
He's relying on pow(2,7) to produce 128, and it's not. It's apparently evaluating to an ever so slightly lower value, which gets rounded down to 127 when converted to an integer.