From: "Camilo" Newsgroups: comp.os.msdos.djgpp Subject: RoundOffErrors Date: 7 Feb 1999 13:18:20 GMT Organization: AT&T WorldNet Services Lines: 103 Message-ID: <79k3qs$37l@bgtnsc03.worldnet.att.net> NNTP-Posting-Host: 12.78.192.162 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Camilo wrote in message ... > Thank you for your input. > I interspersed my answers to your comments. I hope this is your preference. > >Martin Ambuhl: > This cannot be the code you used. The code posted is replete with syntax >errors, which somewhat moot the observation that it is about the ugliest >code I have seen outside the obfuscated C contest. > >Camilo: >Sir, Syntax errors? Well, I am using VC++6 TO CODE PLAIN STANDARD ANSI C++. > I went: >1._ Help.Index.porting, to Standard C++ Library..., then > >2._ making sure that was plain ANSI C++, I compiled exactly the same code >(which I attached) using the djgpp compiler > > gxx -o prm00.exe prm00.cc > >without any compilation problems whatsoever. > > Then I run my problems and got the following strange results. >1._ The first time I run the program, it dumped on me core with the folowing >message: >Exiting due to signal SIGFPE Division by zero at eip=0000256f, x87 >status=0120 >... >Call frame traceback EIPs: > 0X0000256f > 0X00001ee9 > 0X000145ee >2._ Each time thereafter the program run fehlerfrei, and from [2,2^24] the >deviation of the djgpp compiler was 10^6 more accurate than the ANSI C++ >Version of VC++6, meaning that after dividing all prime numbers in this >interval, VC++6 found 164527 Round OFf Errors, whereas djgpp only found >1!!!. Jezz! That is strange or might not simply know where the monkey is, >and I need to. > >Martin Ambuhl: >Start by getting rid of the >1._ unneeded macro (which is written erroneously in any case), >2._ killing the silly typedefs, >3._ making your output statements readable, >4._ and above all indenting your code. >5._ Why the code you really are using produces any specific results is a >pure guess, since this code won't even compile. >6._ When you have compilable, readable code, let's talk. > >Camilo: >1._ I would disagree I used this awkard macro because I need to stop and >jump to differing places in the code, this is something I wouldn't know how >to achieve using a function. ( I don't claim to be a good CPP programmer, >yet) >2._ I did kill the silly typedefs for you, >3._ they are readable to me, and I don't see what is so terrrible about >reading them, >4._ I have indented it to my preference, using only one blank space. >5 and 6._ discussed at the begining > >Thank you >Camilo > >--- INITIAL POSTING ---- >Camilo wrote: >> >> Hi, >> >> First of all, all respects to, and excluding Jack Klein and the other >helping out people; this is for the "topic" lawyers around here: >> I very well know this is not strickly speaking an ANSI C++ issue, but a >computer science in general. However I would appreciate if you can help me >understand the ANSI C++ part of my question, if any. > >> I need to test the roundoff sensitivity of the basic mathematical >functions in C++. I am trying to do it checking the identities operations >expouse (which define them), like 1 = a*(1/a). >> Since basic Arithmetic operations on natural numbers can be reduced to >operations on prime numbers. I am just using prime numbers. >> >> Questions: >> >> 1._ Why am I getting the same difference, namely >> >> 1.110223024625157e-016 >> >> to the identity. Regardless of the prime number I use for the division? >> >> 2._ Is there a way to read or make the compiler produce the assembly code >to >> this source to check if the compiler is optimizing away my code? Maybe >> making use of temporary objects? >> >> Thank you >> Camilo > > >