Mail Archives: djgpp/1999/02/06/20:18:30
From: | "Camilo" <CmlLpz AT worldnet DOT att DOT net>
|
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
- Raw text -