From: Paul H. <cfu...@ea...> - 2005-07-08 04:56:01
|
What is wrong with this C++ program? Compiled with the recent MinGW-4.1.0.exe release, I get 1.235e+005 when the program is executed. On the other hand, with an earlier release (MinGW-3.1.0-1.exe), the program outputs 123456.7890. A late 90s edition of Metrowerks C++ also produces that second result. I'm working on an astromomy app with lots of floating point tabular output, so I need to understand why the output format isn't the same with different compilers. It's probably something obvious but I just can't see it. #include <iostream> #include <ostream> #include <iomanip> using namespace std; int main() { cout << fixed << setprecision(4) << 123456.789 << '\n'; return 0; } |
From: Luke D. <cod...@ho...> - 2005-07-08 15:28:48
|
What GCC version? (gcc -v) It works for me with 3.4.4, giving 123456.7890 Luke ----- Original Message ----- From: "Paul Hirose" <cfu...@ea...> To: "MinGW list" <min...@li...> Sent: Friday, July 08, 2005 12:55 PM Subject: [Mingw-users] C++ floating point fixed format > What is wrong with this C++ program? Compiled with the recent > MinGW-4.1.0.exe release, I get 1.235e+005 when the program is executed. > On the other hand, with an earlier release (MinGW-3.1.0-1.exe), the > program outputs 123456.7890. A late 90s edition of Metrowerks C++ also > produces that second result. > > I'm working on an astromomy app with lots of floating point tabular > output, so I need to understand why the output format isn't the same > with different compilers. It's probably something obvious but I just > can't see it. > > > #include <iostream> > #include <ostream> > #include <iomanip> > > using namespace std; > > int main() { > cout << fixed << setprecision(4) << 123456.789 << '\n'; > return 0; > } |
From: Paul H. <cfu...@ea...> - 2005-07-08 17:36:31
|
Luke Dunstan wrote: > > What GCC version? (gcc -v) > > It works for me with 3.4.4, giving 123456.7890 3.2.3 gives 123456.7890 (so does Metrowerks C++) 3.4.2 gives 1.235e+005 Is either result correct? If so, then my understanding of the language is faulty and I need to find some other way to control numeric formatting. (The 10-digit result is what I need.) Brian Kropf wrote: > Here is a page that explains the setprecision manipulator > http://www.cplusplus.com/ref/iostream/iomanip/setprecision.html Something seems to be missing there. In Stroustrup's "The C++ Programming Language" (1997), he says there are three different floating point output formats. In the "general" format, precision has the same meaning as shown on that web page. However, in the "fixed" and "scientific" formats, precision is the number of digits after the decimal point. The web page says nothing about that. On the other hand, my book is 8 years old. Has the meaning of "precision" in floating point output changed since then? #include <iostream> #include <ostream> #include <iomanip> using namespace std; int main() { cout << fixed << setprecision(4) << 123456.789 << '\n'; return 0; } |
From: Michael G. <mg...@te...> - 2005-07-08 19:34:42
|
> > What GCC version? (gcc -v) > >=20 > > It works for me with 3.4.4, giving 123456.7890 >=20 > 3.2.3 gives 123456.7890 (so does Metrowerks C++) > 3.4.2 gives 1.235e+005 gcc 3.3.5 gives 123456.7890 gcc 4.0.1 gives 123456.7890 So it seems as if newer versions of gcc give what you expect. Maybe 3.4.2 had a bug introduced that got fixed ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Snaury <sn...@gm...> - 2005-07-09 10:11:17
|
On 7/8/05, Paul Hirose <cfu...@ea...> wrote: > 3.2.3 gives 123456.7890 (so does Metrowerks C++) > 3.4.2 gives 1.235e+005 Huh? o.O How could that be? Reading specs from D:/Alex/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=3Dmingw32 --target=3Dmingw32 --prefix=3D/mingw --enable-threads --disable-nls --enable-languages=3Dc,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=3Dboehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) Gives 123456.7890 to me However when I *remove* fixed, it gives me 1.235e+005, which is no surprise= ... |
From: Paul H. <cfu...@ea...> - 2005-07-11 05:24:13
|
Snaury wrote: > On 7/8/05, Paul Hirose <cfu...@ea...> wrote: > >>3.2.3 gives 123456.7890 (so does Metrowerks C++) >>3.4.2 gives 1.235e+005 > > > Huh? o.O How could that be? Beats me. I'm a newbie; 2 months ago I'd never touched MinGW. I was hoping someone could give me a clue. My compiler seems to be configured the same as yours: > Reading specs from D:/Alex/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/specs Reading specs from g:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs > Configured with: ../gcc/configure --with-gcc --with-gnu-ld Configured with: ../gcc/configure --with-gcc --with-gnu-ld > --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw > --enable-threads --disable-nls --enable-threads --disable-nls > --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry > --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-shared --enable-sjlj-exceptions --enable-libgcj > --disable-java-awt --without-x --enable-java-gc=boehm --disable-java-awt --without-x --enable-java-gc=boehm > --disable-libgcj-debug --enable-interpreter --disable-libgcj-debug --enable-interpreter > --enable-hash-synchronization --enable-libstdcxx-debug --enable-hash-synchronization --enable-libstdcxx-debug > Thread model: win32 Thread model: win32 > gcc version 3.4.2 (mingw-special) gcc version 3.4.2 (mingw-special) > Gives 123456.7890 to me That's not what I get. Here's a compile and run of the program: G:\My Documents\gcc\test pre>make -f makefile01.txt G:\My Documents\gcc\test pre>mingw32-make -f makefile01.txt g++ -o testpre testpre.cpp G:\My Documents\gcc\test pre>testpre 1.235e+005 Switching to 3.2.3, the result is different: G:\My Documents\gcc\test pre>make -f makefile01.txt G:\My Documents\gcc\test pre>mingw32-make -f makefile01.txt g++ -o testpre testpre.cpp G:\My Documents\gcc\test pre>testpre 123456.7890 I switch compilers by running either of two .bat files. One puts the 3.2.3 bin directory in the command search path, then opens a command line window. The other is identical, except that it puts the 3.4.2 bin directory in the path. The same makefile and source file are used by both compilers. Did you use MinGW-4.1.0.exe to put GCC 3.4.2 on your system? That's how I got it. It did cross my mind to try downloading packages separately to see if that makes a difference, but it's too much bother over a dial-up connection. So I've reverted to 3.2.3. |
From: Brian K. <bk...@em...> - 2005-07-08 15:29:36
|
Well first thing is they are the same number 1.235e+005 is the same as 123456.7890 after it rounds the number to four digits which is what the setprecision does. Here is a page that explains the setprecision manipulator http://www.cplusplus.com/ref/iostream/iomanip/setprecision.html What exactly were you trying to accomplish with the setprcision call? Maybe there is another way to do it. - brian Paul Hirose wrote: > What is wrong with this C++ program? Compiled with the recent > MinGW-4.1.0.exe release, I get 1.235e+005 when the program is executed. > On the other hand, with an earlier release (MinGW-3.1.0-1.exe), the > program outputs 123456.7890. A late 90s edition of Metrowerks C++ also > produces that second result. > > I'm working on an astromomy app with lots of floating point tabular > output, so I need to understand why the output format isn't the same > with different compilers. It's probably something obvious but I just > can't see it. > > > #include <iostream> > #include <ostream> > #include <iomanip> > > using namespace std; > > int main() { > cout << fixed << setprecision(4) << 123456.789 << '\n'; > return 0; > } > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted > by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Greg C. <chi...@co...> - 2005-07-08 16:07:39
|
On 2005-07-08 11:29 AM, Brian Kropf wrote: > Well first thing is they are the same number > 1.235e+005 is the same as 123456.7890 after it rounds the number to four > digits which is what the setprecision does. But he set floatfield to fixed: > Paul Hirose wrote: > >> cout << fixed << setprecision(4) << 123456.789 << '\n'; so shouldn't that give a minimum of four digits to the right of the decimal point? > Here is a page that explains the setprecision manipulator > http://www.cplusplus.com/ref/iostream/iomanip/setprecision.html It says: | The precision determines the maximum number of digits that shall | be output on insertion operations to express floating-point values, | counting both the digits before and after the decimal point. but doesn't C++98 27.4.2.2/9 disagree? |
From: Greg C. <chi...@co...> - 2005-07-11 12:07:12
|
On 2005-07-11 01:23 AM, Paul Hirose wrote: > Snaury wrote: > >> On 7/8/05, Paul Hirose <cfu...@ea...> wrote: >> >>> 3.2.3 gives 123456.7890 (so does Metrowerks C++) >>> 3.4.2 gives 1.235e+005 >> >> Huh? o.O How could that be? > > Beats me. I'm a newbie; 2 months ago I'd never touched MinGW. I > was hoping someone could give me a clue. It could be a problem with the way your program is compiled and linked. Others haven't been able to reproduce the reported problem. I get 123456.7890 with both 3.2.3 and 3.4.2 . >> Gives 123456.7890 to me > > That's not what I get. Here's a compile and run of the program: > > G:\My Documents\gcc\test pre>make -f makefile01.txt > > G:\My Documents\gcc\test pre>mingw32-make > -f makefile01.txt > g++ -o testpre testpre.cpp > > G:\My Documents\gcc\test pre>testpre > 1.235e+005 Try running the compiler directly instead of through a makefile, to eliminate one possible source of error. Here's what I get: C:/tmp[3]$/MinGW/bin/g++ -dumpversion 3.4.2 C:/tmp[0]$/MinGW/bin/g++ paul_hirose.cpp C:/tmp[0]$./a 123456.7890 > I switch compilers by running either of two .bat files. One puts the > 3.2.3 bin directory in the command search path, then opens a command > line window. The other is identical, except that it puts the 3.4.2 bin > directory in the path. Try specifying the absolute path to the compiler explicitly, as above, to eliminate another possible source of error. Try setting an empty system path, too. > Did you use MinGW-4.1.0.exe to put GCC 3.4.2 on your system? That's how > I got it. It did cross my mind to try downloading packages separately to > see if that makes a difference, but it's too much bother over a dial-up > connection. So I've reverted to 3.2.3. If you happen to have 3.2.3 in /MinGW/ and 3.4.2 in /MinGW-3.4.2/, that can cause a problem, too. You can have two versions installed, but if one's in a directory named /MinGW/, then the other might look there for some important components. |
From: Paul H. <cfu...@ea...> - 2006-06-23 19:43:04
|
A year ago I was having trouble after updating MinGW with a later build, and asked for advice. However, I was busy, and my older MinGW was good enough, so I never got around to acting on this suggestion until yesterday. Greg Chicares wrote: > > If you happen to have 3.2.3 in /MinGW/ and 3.4.2 in /MinGW-3.4.2/, > that can cause a problem, too. You can have two versions installed, > but if one's in a directory named /MinGW/, then the other might > look there for some important components. That was *exactly* the problem. My initial MinGW installation was in g:\MinGW. Later, when I installed a later version, I put it in g:\MinGW342 but kept the old version as a backup. But "being careful" can get you into trouble if you don't know what you're doing! In my case, it led to a bizarre assortment of problems, ranging from false errors reported during compile, to a program which compiled OK but crashed on execution, to a program which printed numbers in exponential format instead of fixed point. And some programs worked just fine. After I renamed the old directory from g:\MinGW to g:\MinGW323 my problems went away. The ironic part is that with 3.4.2 now running without a hitch, I think it's safe to delete 3.2.3! Thanks for the help. -- I block messages that contain attachments or HTML. |