I'm a beginner of C. When I use printf format %Lf, I got a wrong result. My code is like below.
long double dip = 5.32e-5;
printf("%Lf can be written %Le\n", dip, dip);
And I got the result as below:
0.000000 can be written 3.172882e-317
I wrote my code in vs code + MinGW. Any mistakes in my code?
It seems MinGW doesn't support %Lf format by default.
Adding -std=c99 compiler option may get it work.
This code worked on my MinGW gcc 4.8.1 with -std=c99 option (I didn't use vs code):
#include <stdio.h>
int main(void) {
long double dip = 5.32e-5;
printf("%Lf can be written %Le\n", dip, dip);
}
output:
0.000053 can be written 5.320000e-005
Related
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed last month.
First, my environment:
Distributor ID: Bunsenlabs
Description: BunsenLabs GNU/Linux 10.5 (Lithium)
Release: 10.5
Codename: buster
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
I working on an old C program and ran into a rounding error in the program. I have copied the code into an the program "example.c" below:
main()
{
float acntBalance;
int dollars;
int cents;
float fcents;
dollars = 303466;
cents = 95;
fcents = cents * 0.01;
acntBalance = dollars + fcents;
printf("Dollars(%d) + Cents(%f) = %f \n",dollars,fcents,acntBalance);
}
and compiled this code using the GNU compiler as follows:
gcc -w -g -o example example.c
Adding 303466 dollars to 95 cents should be 303466.95,
but prints out as 303466.937500.
This is an accounting program and being 1 cent off is not acceptable.
This looks like a bug to me, but it has been so long since I worked on a C program, so I will say "user error" is the mostly like problem here. But this seems so basic, that I don't see where I am making an error.
If the error is not mine, is it H/W or S/W. I have run the program on 2 different hosts, so it leads me to believe it is a S/W error. But where?
Can anyone see an error in my code?
%.1f = one decimal place
%.2f = two decimal places
...
printf("Dollars(%d) + Cents(%f) = %.2f \n",dollars,fcents,acntBalance);
I ran a program like this:
#include <stdio.h>
int main(void)
{
float aboat = 32000.0;
double abet = 2.14e9;
long double dip =5.32e-5;
printf("%f can be written %e\n",aboat,aboat);
printf("And it's %a in hexadecimal, powers of 2 notation\n",aboat);
printf("%f can be written %e\n",abet, abet);
printf("%Lf can be written %Le\n",dip,dip);
\\ this statement can not print rightly
return 0;
}
but it print like this :
32000.000000 can be written 3.200000e+004
And it's 0x1.f40000p+14 in hexadecimal, powers of 2 notation
2140000000.000000 can be written 2.140000e+009
-1950228512509697500000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000.0
00000 can be written 272.500183
as you can see , this result must be incorrect. but I can not find error, so is it a bug attribute to IDE ? I use JetBrains CLion 2017.3.4.
thanks for remind.this is my CMakeList.txt:
cmake_minimum_required(VERSION 3.9)
project(untitled1 C)
set(CMAKE_C_STANDARD 11)
add_executable(untitled1 main.c)
And the gcc version is 6.3.0
I'm porting some code from 32 bit to 64 bit, and ensuring the answers are the same. In doing so, I noticed that atan2f was giving different results between the two.
I created this min repro:
#include <stdio.h>
#include <math.h>
void testAtan2fIssue(float A, float B)
{
float atan2fResult = atan2f(A, B);
printf("atan2f: %.15f\n", atan2fResult);
float atan2Result = atan2(A, B);
printf("atan2: %.15f\n", atan2Result);
}
int main()
{
float A = 16.323556900024414;
float B = -5.843180656433105;
testAtan2fIssue(A, B);
}
When built with:
gcc compilerTest.c -m32 -o 32bit.out -lm
it gives:
atan2f: 1.914544820785522
atan2: 1.914544820785522
When built with:
gcc compilerTest.c -o 64bit.out -lm
it gives:
atan2f: 1.914544701576233
atan2: 1.914544820785522
Note that atan2 gives the same result in both cases, but atan2f does not.
Things I have tried:
Building the 32 bit version with -ffloat-store
Building the 32 bit version with -msse2 -mfpmath=sse
Building the 64 bit version with -mfpmath=387
None changed the results for me.
(All of these were based on the hypothesis that it has something to do with the way floating point operations happen on 32 bit vs 64 bit architectures.)
Question:
What are my options for getting them to give the same result? (Is there a compiler flag I could use?) And also, what is happening here?
I'm running on an i7 machine, if that is helpful.
This is easier to see in hex notation.
void testAtan2fIssue(float A, float B) {
double d = atan2(A, B);
printf(" atan2 : %.13a %.15f\n", d, d);
float f = atan2f(A, B);
printf(" atan2f: %.13a %.15f\n", f, f);
printf("(float) atan2 : %.13a %.15f\n", (float) d, (float) d);
float f2 = nextafterf(f, 0);
printf("problem value : %.13a %.15f\n", f2, f2);
}
// _ added for clarity
atan2 : 0x1.ea1f9_b9d85de4p+0 1.914544_797857041
atan2f: 0x1.ea1f9_c0000000p+0 1.914544_820785522
(float) atan2 : 0x1.ea1f9_c0000000p+0 1.914544_820785522
problem value : 0x1.ea1f9_a0000000p+0 1.914544_701576233
what is happening here?
The conversion from double to float can be expected to be optimal, yet arctangent functions may be a few ULP off on various platforms. The 1.914544701576233 is the next smaller float value and reflects the slightly inferior arctangent calculation.
What are my options for getting them to give the same result?
Few. Code could roll your own my_atan2() from an established code base. Yet even that may have subtle implementation differences. #stark
Instead, consider making code checking tolerant of the minute variations.
This question already has answers here:
gcc: printf and long double leads to wrong output. [C - Type conversion messes up]
(5 answers)
Closed 7 years ago.
When I run the Ansi C program below, a value of "0.000000" is printed out. Does anyone know why the value "561.308000" is not being printed out? I am using Dev-C++ to run the program, and the compiler I am using is: Mingw port of GCC (GNU Compiler Collection), version MSVCRT 2.95.2-1.
#include <stdio.h>
#include <stdlib.h>
main()
{
long double x = 561.308;
printf("%Lf",x);
}
Compiling with gcc (GCC) 4.8.1 on Windows 7 64bit with this command is worked. (Add -std=c99 to the option to have the compiler work with C99)
gcc -Wall -Wextra -std=c99 test.c -o test.exe
the zero might be the return value of the main()
it is printed
Could you try :
printf("Answer is : %Lf",x);
to see whether you got 0.000000 or Answer is: 0.0000
And how about
printf("Answer is : %Lf", 561.38888);
I have this:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
long double x = 561.308;
printf("%Lf",x);
return 0;
}
I have an algorithm coded in MATLAB, which contains complex arc cos of some value (computation requires arccos of 15, which is approximately 3.4i). I want to code C or C++ counterpart of this code running on my Windows 7 PC. Actually, I want to produce it as a mex function compiled with Visual Studio C++.
I included "complex.h" and used cacosf function (complex arccos returning float _Complex) but I could not compile it as a mex function because Visual C++ compiler does not have "complex.h" support. However, mex file can take libraries as input, so I can compile my c code with another compiler that MATLAB does support (for example mingw, I integrated it to matlab with gnumex utility.) I downloaded Bloodshed C++ IDE which uses mingw at backend, I can compile my c++ code. The following C++ code represents a similar operation to my goal:
#include <stdio.h>
#include <complex.h>
int main() {
float _Complex myComplex;
myComplex = cacosf(5);
printf("Complex number result of acos(5) is : %f + %fi \r\n",crealf(myComplex),cimagf(myComplex));
return 0;
}
The output should be:
Complex number result of acos(5) is : 0.000000 + -2.292432i
However I get
Complex number result of acos(5) is : -1.#IND00, -0.000000
When I compile my C++ code with Linux GCC on Ubuntu 14.04 computer with Eclipse CDT Luna I get
The output should be:
Complex number result of acos(5) is : 0.000000 + -2.292432i
Where can I be wrong? Why can't I compile this code in Windows + mingw setup?
Note: I can compute cacosf(0) as 1.570796 + -0.000000 when I use mingw.
What version of mingwrt are you using? With mingwrt-3.21.1, the following works for me, (cross-compiling on a Linux host, and running under wine):
$ cat foo.c
#include <stdio.h>
#include <complex.h>
int main()
{
double _Complex Z = cacos(5.0);
printf( "arcos(5) = (%g, %gi)\n", __real__ Z, __imag__ Z );
return 0;
}
$ mingw32-gcc -o foo.exe foo.c
$ ./foo.exe
arcos(5) = (0, -2.29243i)
This seems to be consistent with your expected result. However, if you use any mingwrt version pre-dating mingwrt-3.21, (and the less said about utterly broken mingwrt-4.x the better), then there is a known bug resulting from arbitrarily deeming any purely real cacos() argument value greater than (1.0, 0.0i) to be outside the valid domain, (as would be the case for acos() on its real part), which would yield the result you report.
Visual C++, as the name says, is a C++ compiler. C++ uses the <complex> header and std::complex<float> type. Since C++ has overloading, you can call std::acos for complex values too.
Your code is in fact C, which is no longer supported by MSVC++. (They stopped doing that back in 1996 or so)