From: "Camilo" Newsgroups: comp.os.msdos.djgpp Subject: RoundOffErrors Date: 7 Feb 1999 01:08:35 GMT Organization: AT&T WorldNet Services Lines: 96 Message-ID: <79ip2j$aqq@bgtnsc03.worldnet.att.net> NNTP-Posting-Host: 12.79.11.135 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 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