This question already has an answer here:
Rounding issue when using long long on PIC
(1 answer)
Closed 4 years ago.
char q[150];
void main(void){
System_Initialization();
UART_Init_2();
while(1){
double A=23.045610;
sprintf(q,"%f\r\n",A);
UART_Tx_2(q);}}
When I Read value of A its give 23.045410 instead of 23.045610
anyone know why this will happened?
i am using PIC18F67k22 controller and Xc8 Compiler
On the PIC18, the data types float and double are the same, and only 32 bits long. That is not enough bits to store more than five or so decimal digits. Therefore you can expect some rounding error at the end of the decimals.
Related
This question already has answers here:
Comparing float and double in C
(2 answers)
strange output in comparison of float with float literal
(8 answers)
Closed 1 year ago.
Can someone pls explain me why this is not printing hello?
int main(){
float i;
i=1.2;
while (i==1.2){
printf("hello");
}
Computers only store digital information. Integers can be represented accurately in binary, but floating point numbers are approximated.
It seems that in the approximations, additional tiny values are preventing your exact comparison from being true.
Now is a good time to google "what every programmer should know about floating point numbers" and read it. It will save you countless hours of future programming and debugging if you learn it early.
In addition, there are two floating point types "float" and "double". You are comparing a float to a double, so the approximations of the value are likely not the same approximation, creating more of a chance that the two values won't be equal.
This question already has answers here:
c++ pow(2,1000) is normaly to big for double, but it's working. why?
(3 answers)
Closed 1 year ago.
sorry if this is a silly question, I am relatively new to C programming. Thus I have probably misunderstood something fundamental about variables/overflows.
I made this simple program and I can't explain the result
#include <stdio.h>
#include <math.h>
int main() {
double number = pow(2, 1000);
printf("%f\n", number);
}
The result of that (compiled with gcc) is a humongous number that should never fit in a variable of type double: 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376.000000
Usually when I try to assign a constant that is too large for it's type the compiler gives me an error.
So my question is: What is this number? Why am I not getting any errors? Is the variable number actually storing this value? Plainly, what's happening?
Doubles are not stored like integers. This page explains how double are representated in memory
Doubles contain 1 byte of sign, 11 bits for the exponent and 53 bits for the sigificand precision. Thus you can store numbers up to 1.7*10^308. Thus, your number cand be represented in a double (although with a limited precision). When printing it with %f, you just get its numerical value (approximated).
In C, double type can fit more than 300 decimal digits! A double is stored in 8 bytes, holding a number in the range 2.3E-308 to 1.7E+308 (15 decimal places accuracy).
Reference: https://www.tutorialspoint.com/cprogramming/c_data_types.htm
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 5 years ago.
I came across this code recently. It produces strange results (lots of random digits after about the 18th digit.) I tried to find information on the limits to sprintf but could not find it. I am trying to figure out if the answer is actually correct or just garbage. When passed 0.025 (as a double) it prints out:
0.025000000000000001387778780781445675529539585113525390625
#define MAX_NUM_STR_LEN 128
void File_WriteNumber(File *fp, double value) {
char numbuf[MAX_NUM_STR_LEN];
int sz = sprintf(numbuf, "%.100g", value);
fwrite (numbuf , sizeof(char), sz, fp);
}
Answer is actually correct - not random digits.
double can typically represent exactly about 264 different values.
0.025 is not one of them with a binary64 double.
The closest double is 0.025000000000000001387....
The next closest double is 0.024999999999999997918...
sprintf() is doing just fine.
This question already has answers here:
Why does floating-point arithmetic not give exact results when adding decimal fractions?
(31 answers)
Closed 6 years ago.
On a 32-bit system, I found that the operation below always return the correct value when a < 2^31 but returns random results where a is larger.
uint64_t a = 14227959735;
uint64_t b = 32768;
float c = 256.0;
uint64_t d = a - b/ c; // d returns 14227959808
I believe the problem here is that the int-to-float operation returns undefined behavior, but could someone help explain why it gives such a value?
The entire calculation goes to float, then gets cast to a 64 bit integer. But floats can't accurately represent large integers, unless they happen to be powers of two.
This question already has answers here:
How to represent FLOAT number in memory in C
(11 answers)
Closed 7 years ago.
I was reading the way, how integers are stored in variables in c, that the last bit is used for the sign of the integer and the remaining bits are used to store the number.
But if we take a double variable and the long int variable in c, both has a size of 4 bytes but the float can store the very huge numbers up to a range of 1038 but long int of same size cant store such huge value.
I want to understand the mechanism which is used in storage in float.
The C language does not require any specific representation for floating point numbers.
Today, most C implementations are using IEEE floating numbers (exceptions are unusual, perhaps some Series Z mainframes from IBM).
Read http://floating-point-gui.de/
The complete explanation can be found here . Basically, the number is not fully stored, only approximately. The 32 bits are used to store as much precision as possible.