Post Reply 
rskey's Calculator forensics in Fortran
03-09-2016, 10:08 AM (This post was last modified: 03-09-2016 10:35 AM by Dieter.)
Post: #8
RE: rskey's Calculator forensics in Fortran
(06-30-2014 12:44 PM)HP67 Wrote:  Here are the results with the Fortran compilers I have: Sorry for the bad alignment. For whatever reason code tags don't help much and I can't set the font to a fixed with font so although it looks almost correct in preview/posting mode once it is posted it doesn't.

Correct alignment is no problem. You just have to consider that the message editor always uses a proportional font, while everything within the two "code" tags is formatted with a fixed font. So simply use another (fixed font) editor for such tables and copy/paste them from there:

Code:
g95             8.999999999967708
gfortran        8.9999999998325695
ifort           8.99999999983257
OpenUH          8.99999999983257
Open64          8.99999999983257
Solaris Studio  8.999999999832553
VMS/VAX         8.999999999984616
IBM G&H         8.999999999967723

This leads to the question of the "perfect" forensic result for each compiler, depending on the implemented precision, i.e. the final value if every intermediate result is correctly rounded to working precision. No, it's not 9.000000.... ;-) You should expect to lose at least 5 digits in the final result.

For n-digit BCD calculators the perfect results have been discussed here earlier, but I think it's bit more tricky with n-bit binary arithmetics, once done in software and the other time by calling hardware FPU routines.

BTW... wouldn't a really optimizing compiler replace x=asin(acos(atan(tan(cos(sin(9)))))) with a simple x=9 ? ;-)

Dieter
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: rskey's Calculator forensics in Fortran - Dieter - 03-09-2016 10:08 AM



User(s) browsing this thread: 1 Guest(s)