Article View: comp.lang.fortran
Article #6510Re: Precision of floating point multiply
From: Richard Maine
Date: Mon, 29 Sep 2003 17:13
Date: Mon, 29 Sep 2003 17:13
41 lines
3502 bytes
3502 bytes
"GerardS" <GerardS@PrairieTech.Net> writes: > | Richard Maine wrote: > |> Ron Shepard wrote: > |> Are the exponents converted automatically with these instructions? > |> If they aren't, then it seems odd to be able to convert between a > |> double precision floating point value to a single precision value > |> just by loading the value into a register. > | > | Add usual caveat about my memory, but the exponents don't *NEED* > | converting. I recall thinking it sort of strange the first time I saw > | floating point formats where the exponents weren't the same for single > | and double. I've subsequently gotten used to it. Sounds to me like > | you are so used to it that you didn't think of the other possibility. :-) > > What if the number isn't normalized ? ___________________________Gerard S. Why would it make any difference? It doesn't that I know of. Do you have something in specific in mind? Yes, numbers that are not normalized are prone to lose precision if you don't normalize them before operations. In particular, if you convert a nonnormalized double to a single, you'll presumably get a nonnormalized single, which will have worse precision than the horrid IBM single format does anyway. If one goes around doing operations on nonnormalized data, you are likely to lose precision in general. Nothing unique to single-double conversion here that I see. Again, I ackowledge that my memory may be confusing systems. I certainly recall (with much pain) the IBM single precision floating point. I get a little hazy about the details of the machine instruction set, though. I did once do some BAL coding - even took a formal course in it, but it's been a long time (nearly 30 years) and I never did a lot of it. -- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain | experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain
Technical Details
Message-ID:
<uebrt3frgh.fsf@altair.dfrc.nasa.gov>Path:
arc1-ca.pugleaf.net!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!news.dfrc.nasa.gov!not-for-mailReferences:
<dG4db.598668$uu5.97984@sccrnsc04> <iu6fnvch0g09q9f335tt89ogfcj5jm2ovh@4ax.com> <kmRdb.626671$YN5.452649@sccrnsc01> <bl8q1g$iv7$1@pegasus.csx.cam.ac.uk> <xrXdb.631209$Ho3.121609@sccrnsc03> <ron-shepard-609A55.10533829092003@news.comcast.giganews.com> <uefziffu7c.fsf@altair.dfrc.nasa.gov> <vngokjk8nourca@corp.supernews.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fd4af,7830916812112af0 X-Google-Attributes: gidfd4af,public X-Google-Thread: fd705,7830916812112af0 X-Google-Attributes: gidfd705,public X-Google-Thread: 102b75,7830916812112af0 X-Google-Attributes: gid102b75,public X-Google-Thread: 1094ba,7830916812112af0 X-Google-Attributes: gid1094ba,public X-Google-ArrivalTime: 2003-09-29 10:14:03 PST Path: arc1-ca.pugleaf.net!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!news.dfrc.nasa.gov!not-for-mail From: Richard Maine <nospam@see.signature> Newsgroups: comp.lang.fortran,comp.arch,bit.listserv.ibm-main,alt.folklore.computers Subject: Re: Precision of floating point multiply Date: 29 Sep 2003 10:13:34 -0700 Organization: NASA Dryden Lines: 41 Message-ID: <uebrt3frgh.fsf@altair.dfrc.nasa.gov> References: <dG4db.598668$uu5.97984@sccrnsc04> <iu6fnvch0g09q9f335tt89ogfcj5jm2ovh@4ax.com> <kmRdb.626671$YN5.452649@sccrnsc01> <bl8q1g$iv7$1@pegasus.csx.cam.ac.uk> <xrXdb.631209$Ho3.121609@sccrnsc03> <ron-shepard-609A55.10533829092003@news.comcast.giganews.com> <uefziffu7c.fsf@altair.dfrc.nasa.gov> <vngokjk8nourca@corp.supernews.com> NNTP-Posting-Host: altair.dfrc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ftp2.dfrc.nasa.gov 1064855498 21708 130.134.20.211 (29 Sep 2003 17:11:38 GMT) X-Complaints-To: usenet@ftp2.dfrc.nasa.gov NNTP-Posting-Date: 29 Sep 2003 17:11:38 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code)