fred@brl-smoke.ARPA (Fred Bunn ) (10/30/87)
Hello, world; Cray II CFT77 Fortran amod function appears to give seriously wrong results on certain occasions. It is possible the other Cray Fortran compiler uses the same amod assembly level code; perhaps even the C and Pascal compilers. It sometimes returns -epsilon instead of the Y-epsilon as shown in the following: PROGRAM: 1 format(2z16) 2 format(3z18) 3 format(3e25.17) read 1,a read 1,b r=amod(a,b) print 2,a,b,r print 3,a,b,r end INPUT: 4009f9ffffffffff 4009fa0000000000 OUTPUT: 4009F9FFFFFFFFFF 4009FA0000000000 BFDA800000000000 0.49999999999999818E+03 0.50000000000000000E+03 -0.18189894035458565E-11 FLAME ON. Now, let me say this: I discovered this problem after my 4,000 line program crashed, and learned how to work around it to the extent that it no longer crashes. After a week or so, I thought I'd be a nice guy and isolate the problem to the above short code, and pass it along to our computer support folks so they could notify Cray. Now the guy in support is always pleasant, he's been there working with Fortran for >25 yrs and is head of the section, so he knows the language. But after thoughtfully spending 10-15 min understanding the problem, he's no longer interested and I'm left with comments like "Well, I don't thing you'll get much sympathy about this," "In all my years, you're only the second person I know who uses the amod function," and "Well, when two arguments are close together, you can expect results like this." I am alternating between amusement, bewilderment, and rage about such a cavalier attitude. IF X < Y BY ANY REPRESENTABLE AMOUNT, THE R=AMOD(X,Y) MUST BE NEAR X NOT NEAR 0. I would probably be happier with a sin function that returned 1.+epsilon instead of 1. or a uniform random number generator that returned the same. At least the results would be near reasonable answers instead of being at the opposite end of the true range. FLAME OFF. fred@brl (Fred Bunn x278-6648)