Conference turris::decc

  Get the particular compilation command(s) used.

  Split the command out into seperate operations, and see if you
  can determine where things are going weird...

  The most obvious difference is the use of the EV56 CPU on the
  AlphaStation 500/500 (vs EV5 or older CPUs) -- though I do not
  know if this contributes to this problem in any way.

  I had to make a slight change -- the addition of stdio.h -- to get
  this code to compile cleanly on an AlphaStation 255 running OpenVMS
  V7.1 and DEC C V5.5-003:

$ ty x.c
#include <stdio.h>
#include <math.h>

double sum, one;
int i;

main()  {

  sum = 1.0 ; one = 1.0 ;

  for(i=0;i<249999;i++) {
      sum = tan(atan(exp(log(sqrt(sum*sum))))) + one ;
  }
  printf("sum = %20.15f\n", sum);
}
$
$ cc/decc x.c
$ lin x
$ r x
sum = 249999.998237429710000
$

  <<< Note 2196.0 by ANDICE::DALEY "'Course it don't come with @!# wafers!" >>>
     -< rounding of floats way off on alphastation 500/400, libm functio >-

Hi,

Customer is running 4.0b unix on alphastation 500/400.  He runs a test (see
code below), and it comes back with the following results:

        Sum is 244218.00125767540000
        Sum is 244197.22929825756000
        Sum is 244283.97577910629000
        Sum is 244322.91021623151000

...accuracy is uneven.

Every time I run it, on any alpha /dUNIX version I can find, I get this:

        249999.998237429710000

over and over again.  Even on our 500/500.

The customer gets my result on his Alphaserver 1000a.

One big difference in the customer's odd machine:  It has 1GB of memory.  But
this program doesn't touch memory.

I even compiled it on my machine with -non_shared, so he'd run exactly the
same code I had, and sent it to him.  He still gets the way-off results.

Could the problem be in the CPU?  The math functions compile to pretty 
specific floating point instructions, don't they?  Is there something else to
check before I go the "swap the cpu" route?

Any help appreciated.  If this is the wrong conference, 
let me know, and I apologize.

Regards,

John


Here's the code we're dealing with to test rounding:
----------------------------------------------------
#include <math.h>

double sum, one;
int i;

main()  {

  sum = 1.0 ; one = 1.0 ;

  for(i=0;i<249999;i++) {
      sum = tan(atan(exp(log(sqrt(sum*sum))))) + one ;
  }
  printf("sum = %20.15f\n", sum);
}
     

Nothing in that program should vary from run-to-run.
Either you have broken hardware, or the operating system is clobbering
some of your data sometimes.  My guess is broken hardware.

I tried this on V4.0 (EV4 machine) and V4.0B (EV5 machine). I compiled shared
and non_shared. I compiled with and without -ieee. In all of these experiments I
got the same (reproducible) result as you.

I also showed the test case to a resident math/ieee expert and he agreed that
the results should be reproducible on the customer's machine, given what you've
told us. As you suggested, bad memory or hardware could produce flaky results.

Let us know if you determine the cause of the problem.

-Jeff

Thanks all.

The compilation commands were just this:

	cc -o foo foo.c -lm -non_shared

I know that's what the customer ran, because I compiled it here, uuencoded it
and mailed it to him.  He ran it and got his flakey results.

Your responses put me on more solid ground as I call the field and tell them to
swap the cpu.  I'll definitely let you know.

Thanks,

John

....they swapped the motherboard, now all is fine.

Thanks again,

John