Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!convex!bleikamp@convex.UUCP From: bleikamp@convex.UUCP (Richard Bleikamp) Newsgroups: comp.lang.fortran Subject: Extended Precision for real constants Summary: who needs extended precision for real constants Message-ID: <1621@convex.UUCP> Date: 29 Aug 89 13:40:04 GMT References: <282@unmvax.unm.edu> <303@unmvax.unm.edu> <1598@convex.UUCP> <123897@sun.Eng.Sun.COM> Sender: usenet@convex.UUCP Reply-To: bleikamp@convex.UUCP (Richard Bleikamp) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 45 In article <123897@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - Advanced Languages - Floating Point Group ) writes: >In article <1598@convex.UUCP> psmith@convex.com (Presley Smith) writes: >> >> stuff about f77 codes not running under f8x compilers ... > >>What about the vote in X3J3 on Document 58, 111-RRR-12, "Extra Precision >>option for DATA statement", that was DEFEATED on a role call vote by 24-13? >>To quote from document 111-RRR-12: >> >> "The committee (X3J3), in a previous action, REMOVED the Fortran 77 >> permission for processor to supply extra precision. >> >My experience in porting many large codes amongst machines from over >20 different vendors is that codes which rely on this feature (and >most of the others brought up in debate) are, in fact, not portable >now. Users who have _never_ moved their code off the first processor >it was coded on _may_ be bitten by this (very rarely, I suspect). >Those that moved vendors, or processors (e.g. cdc 7600 to cyber 180) >or even compilers (cft 114 -> cft77) are likely to have purged their >code of anything similar to this (or simply not care that answers >don't match digit for digit ... in fp codes that is an unreasonable >test anyway). >> What I've experienced (in a previous job) contradicts this. I've helped port programs, originally from a CDC or Cray, where single precision has plenty of significant digits for their application. When it was ported to a VAX, only the variables were re-typed (from REAL to DP). The VAX appears to supply a double precision value for real constants ANYWHERE in the program where they are used in a double precision context. So, when the user was considering buying one of our (Harris') machines, it was necessary to imitate the VAX, or lose the business (arguing about non-portable code is hopeless!). So, imitating common existing practice (VAXen) is appropriate. One of X3J3's charters is to standardize existing practice, and this looks like a good example of where they should. Implementing real constants is this manner is unlikely to break any programs (some answers will get "better"?), some programs will become more portable, but when implemented correctly, the run-time penalty is insignificant (it may actually improve performance). ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation