From:	"Camilo" <CmlLpz AT worldnet DOT att DOT net>
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
>
>
>

- Raw text -