home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / ultrix / 8395 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.2 KB  |  65 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!cs.uiuc.edu!vela!amaranth
  3. From: amaranth@vela.acs.oakland.edu (Paul Amaranth)
  4. Subject: Re: FPU errors on 5000/240 P.Amaranth
  5. Message-ID: <1992Nov18.222729.24477@vela.acs.oakland.edu>
  6. Organization: Oakland University, Rochester MI.
  7. References: <1992Nov17.195628.15041@vela.acs.oakland.edu> <1eeaffINN3tj@nestroy.wu-wien.ac.at> <1eebumINN51i@nestroy.wu-wien.ac.at>
  8. Date: Wed, 18 Nov 1992 22:27:29 GMT
  9. Lines: 54
  10.  
  11. >I am sorry for contradicting. These things are only correct for the right side of the " = " , and only to bracket expressions.
  12. >Change 
  13. >ainv=1.0/i
  14. >to
  15. >ainv=1.0d0/i   or ainv=1.0/dble(i)
  16. >in your program and you will get a different result!
  17. >namely   -86354540.28378928  .
  18. >on a DEC with FPU - bug AND on a DEC 5000/240 without FPU - bug.  
  19. > 
  20.  
  21. The first expression is evaluated in single precision, then widened to
  22. double for the assignment, the second is done in double, maintaining
  23. precision, so of course you will get a different value.  
  24.  
  25. Only 1 of my 4 unfixed 240s was sensitive to this program anyway, so
  26. getting the same different answer running a different program doesn't
  27. seem to mean much.
  28.  
  29. If DEC would send me the tech info on what is wrong, maybe I could look
  30. at the code generated and figure out why that 10 line program shows a
  31. sensitivity to the FPU problem.  Yeah, right.  Like I needed this FPU
  32. problem in the first place. 'Course, if I knew what was going on, maybe
  33. I could tell my users they didn't have to rerun that last three months of
  34. work.  Might help defuse the 'Kill the Messenger' syndrome.
  35.  
  36. OK, so here's the bottom line:  that EXACT 10 line program, when run on
  37. 5000/240s showed a problem on exactly ONE of my four unfixed 240s, all
  38. of which showed serious problems with the Ponder program.  The Smith
  39. program failed on the same 240, and worked correctly on the other
  40. three.  The Ponder program seems to be the definitive test to show if
  41. you have a problem.  Changing various things in the test program would
  42. get it to work on the same 240.  It was the minimal pathological case
  43. that caused it to fail modeled on operations ocurring in the Smith
  44. program.  Why would anyone want to fix it?  
  45.  
  46. You think its lousy Fortran?  I agree, but that wasn't the object of the
  47. exercise.  The object was to get a short program that failed in the
  48. same circumstances as the Smith program.  I did that, thought it was of
  49. sufficient interest to post it and have now spent more time explaining
  50. Fortran semantics that I spent writing the program.
  51.  
  52. Since I'm taking up bandwith, did anyone else see that program fail?  Or
  53. is it just my one wierdo 240?
  54.  
  55. I'm getting tired of Fortran semantics, anyone have any idea of exactly
  56. what's happening in the FPU?  What sequence of operations cause the error?
  57. Something I can look for in the object and determine if my users had
  58. a problem or not?
  59.  
  60. -- 
  61. Paul Amaranth  Manager User Services - office: (313) 370 4541 (also voicemail)
  62. (internet)     amaranth@vela.acs.oakland.edu  |    This space 
  63. (bitnet)       amaranth@oakland               |    temporarily
  64. (uucp)         ...!uunet!umich!vela!amaranth  |      empty
  65.