🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.fortran
Article #6527

Re: Precision of floating point multiply

#6527
From: Glen Herrmannsfeldt
Date: Mon, 29 Sep 2003 22:00
40 lines
3290 bytes
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:r%0eb.163529$3o3.11771639@bgtnsc05-news.ops.worldnet.att.net...
> Glen Herrmannsfeldt wrote:
> ...
> > What I was saying is that if conversion from single to double did not
clear
> > those bits you would get whatever was left there, possibly from an
unrelated
> > calculation.   I believe that would be a bad idea, but some posts by
others
> > seem to indicate that it would be legal Fortran.  Someone else posted:
> >
> >> Item (6) listed in Section 1.4 of the Fortran standard explicitly
> >> states that the standard does not specify
> >>
> >>    (6)  The physical properties of the representation of quantities and
> >>         the method of rounding, approximating, or computing numeric
> >>         values on a particular processor.
> >
> > The belief is that this statement could include leaving garbage bits in
for
> > low bits.
>
> That's probably a correct assessment.  In fact, on the system in question,
> where "rounding" results to single precision is done by truncation, it
> could be argued that leaving "garbage bits" simulates the missing data!
> Yes, I have heard appalling reasoning of that kind.

Well, since truncating is systematic at puting in zeros, random bits would,
on the average, be closer.

The process of digitizing analog data, such as converting analog audio into
digital form, works best with a process called dithering.  Random noise of
approximately 1 LSB in amplitude is added before sampling.   The left over
bits in registers might not be very random, though.   Using true random
bits, one might even be able to sum into a single precision register and get
good results!

-- glen
Technical Details
Message-ID: <bY1eb.633341$Ho3.121512@sccrnsc03>
Path: arc1-ca.pugleaf.net!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc03.POSTED!not-for-mail
References: <dG4db.598668$uu5.97984@sccrnsc04> <xrXdb.631209$Ho3.121609@sccrnsc03> <bl9ild$abv$1@pegasus.csx.cam.ac.uk> <Rh0eb.632709$Ho3.121617@sccrnsc03> <bla4k2$nas$1@pegasus.csx.cam.ac.uk> <FR0eb.637973$uu5.101567@sccrnsc04> <r%0eb.163529$3o3.11771639@bgtnsc05-news.ops.worldnet.att.net>

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 15:00:40 PST
Path: arc1-ca.pugleaf.net!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc03.POSTED!not-for-mail
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Newsgroups: comp.lang.fortran,comp.arch,bit.listserv.ibm-main,alt.folklore.computers
References: <dG4db.598668$uu5.97984@sccrnsc04> <xrXdb.631209$Ho3.121609@sccrnsc03> <bl9ild$abv$1@pegasus.csx.cam.ac.uk> <Rh0eb.632709$Ho3.121617@sccrnsc03> <bla4k2$nas$1@pegasus.csx.cam.ac.uk> <FR0eb.637973$uu5.101567@sccrnsc04> <r%0eb.163529$3o3.11771639@bgtnsc05-news.ops.worldnet.att.net>
Subject: Re: Precision of floating point multiply
Lines: 42
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID: <bY1eb.633341$Ho3.121512@sccrnsc03>
NNTP-Posting-Host: 12.207.204.17
X-Complaints-To: abuse@comcast.net
X-Trace: sccrnsc03 1064872839 12.207.204.17 (Mon, 29 Sep 2003 22:00:39 GMT)
NNTP-Posting-Date: Mon, 29 Sep 2003 22:00:39 GMT
Organization: Comcast Online
Date: Mon, 29 Sep 2003 22:00:39 GMT