hey is there an easy way to make the decimals round off?
like 34.2353 gets put out as 34.24?
I know there is setprecision but that does the whole number
right now i have: int(cst)<<'.'<<int((cst-int(cst))*100+.5)
cst is a float variable.
Personal computing discussed
Moderators: renee, SecretSquirrel, just brew it!
#include <stdio.h>
#include <math.h>
main()
{
double sf;
double ans1, ans2, ans;
int est1, est2;
double steps = 10.0;
printf("\nHow many significant figures accuracy is required?\n");
scanf("%lf", &sf);
ans1 = integrate (steps);
est1 = (int)(ans1 * pow(10.0,sf));
printf("est1 = %d\n", est1);
steps = steps * 10;
ans2 = integrate(steps);
est2 = (int)(ans2 * pow(10.0,sf));
printf("est2 = %d\n\n", est2);
while(est1 != est2)
{
est1 = est2;
printf("est1 = %d\n", est1);
steps = steps * 10;
ans2 = integrate(steps);
est2 = (int)(ans2 * pow(10.0,sf));
printf("est2 = %d\n\n", est2);
}
ans2 = (double) est2;
ans = (ans2)/pow(10.0,sf);
printf("The answer is % .9lf\n",ans);
}% .9lf
,
IntelMole wrote:It should also be noted that this only works for up to 9 significant figures of precision for some reason. We speculated that this was due to either the variable resolution of the double precision floating point system, or because 10^10 is simply a pretty big number and was causing some sort of arithmetic overflow error. But we never thought of a better way to do this. Hence thein the code.Code: Select all% .9lf
,
bitvector wrote:Foolio wrote:Have you tried using long variables instead of integer variables?
On the most common 32-bit platforms, a long int is going to be the same width as an unqualified int.
just brew it! wrote:bitvector wrote:Foolio wrote:Have you tried using long variables instead of integer variables?
On the most common 32-bit platforms, a long int is going to be the same width as an unqualified int.
Many 32-bit compilers do support a 64-bit integer type long long (or __int64 in MS-speak).
%d print as decimal integer
%6d print as decimal integer, at least 6 characters wide
%f print as floating point
%6f print as floating point, at least 6 characters wide
%.2f print as floating point, 2 characters wide AFTER decimal point
%6.2f print as floating point, at least 6 characters wide and 2 AFTER decimal point#include <stdio.h>
/* print Fahrenheit-Celsius table */
main()
{
int fahr;
for (fahr = 0; fahr <= 300; fahr = fahr + 20)
printf("%3d %6.1f\n", fahr, (5.0/9.0)*(fahr-32));
} 0 -17.8
20 -6.7
40 4.4
...Flying Fox wrote:I don't think the printf precision does rounding.
paco wrote:oops ya i only wanted it for output not for calculations, sorry my first post was rushed since my battery was almost dead,
paco wrote:can i use print f in c++?
paco wrote:hey is there an easy way to make the decimals round off?
like 34.2353 gets put out as 34.24?
I know there is setprecision but that does the whole number
right now i have: int(cst)<<'.'<<int((cst-int(cst))*100+.5)
cst is a float variable.
Shining Arcanine wrote:Are you using C++ .NET?
just brew it! wrote:Flying Fox wrote:I don't think the printf precision does rounding.
Actually, it does.
But I was under the impression that the original poster wanted the rounded value to be stored in a (numeric) variable for subsequent use. Reading back through this thread, I'm not sure why I thought that.
liquidsquid wrote:I believe rouding is not specified under ANSI for it, so depending on the comipler it may or may not round. You have to be careful! However with that said, I have not come across a compiler yet this did not round by the format specifiers except on very small uC devices where space is critical (<2K of memory).
paco wrote:hey is there an easy way to make the decimals round off?
like 34.2353 gets put out as 34.24?
I know there is setprecision but that does the whole number
right now i have: int(cst)<<'.'<<int((cst-int(cst))*100+.5)
cst is a float variable.
#include <iostream>
#include <iomanip>
using std::cout;
using std::setprecision;
using std::endl;
int main(void){
double a=3.1415;
cout<<setprecision(4)<<a<<endl;
return 0;
}
#include <iostream>
#include <iomanip>
#include <sstream>
#include <cstdlib>
using std::string;
using std::cout;
using std::setprecision;
using std::endl;
using std::ostringstream;
int main(void){
double a=3.1415;
ostringstream ossout;
string temp;
ossout<<setprecision(4)<<a<<endl;
temp=ossout.str();
a=strtod(temp.c_str(),NULL);
cout<<setprecision(9)<<a<<endl;
return 0;
}
bitvector wrote:liquidsquid wrote:I believe rouding is not specified under ANSI for it, so depending on the comipler it may or may not round. You have to be careful! However with that said, I have not come across a compiler yet this did not round by the format specifiers except on very small uC devices where space is critical (<2K of memory).
The C99 standard says that "the result should be correctly rounded" as part of the "recommended practice" subsection of fprintf. I guess this means it's suggested but not strictly necessary. And the issue you cite above is not dependent on the compiler but rather the C runtime library's implementation of fprintf.
Craig P. wrote:bitvector wrote:The C99 standard says that "the result should be correctly rounded" as part of the "recommended practice" subsection of fprintf. I guess this means it's suggested but not strictly necessary. And the issue you cite above is not dependent on the compiler but rather the C runtime library's implementation of fprintf.
That would make it a quality-of-implementation issue -- but one significant enough that I can't imagine it wouldn't be a priority for any compiler developer.
bitvector wrote:Uh, again... as I pointed out in my post this issues has nothing to do with the actual compiler developers. Sometimes the compiler and library developers are the same people, but not always. I mean, gcc is used on targets with a wide variety C runtime libraries. If you file a bug report on gcc because fprintf on uClibc or Sun's libc doesn't round correctly, you're yelling at the wrong people.
bitvector wrote:Craig P. wrote:bitvector wrote:The C99 standard says that "the result should be correctly rounded" as part of the "recommended practice" subsection of fprintf. I guess this means it's suggested but not strictly necessary. And the issue you cite above is not dependent on the compiler but rather the C runtime library's implementation of fprintf.
That would make it a quality-of-implementation issue -- but one significant enough that I can't imagine it wouldn't be a priority for any compiler developer.
Uh, again... as I pointed out in my post this issues has nothing to do with the actual compiler developers. Sometimes the compiler and library developers are the same people, but not always. I mean, gcc is used on targets with a wide variety C runtime libraries. If you file a bug report on gcc because fprintf on uClibc or Sun's libc doesn't round correctly, you're yelling at the wrong people.
