delorie.com/archives/browse.cgi   search  
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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019