From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6a8952cbe009f3ed X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII X-Received: by 10.66.78.70 with SMTP id z6mr2016131paw.5.1358640341063; Sat, 19 Jan 2013 16:05:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.150.142 with SMTP id ui14mr1847505igb.9.1358640340860; Sat, 19 Jan 2013 16:05:40 -0800 (PST) Path: s9ni5515pbb.0!nntp.google.com!f6no12638081pbd.1!postnews.google.com!pp8g2000pbb.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 19 Jan 2013 16:05:40 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: pp8g2000pbb.googlegroups.com; posting-host=123.2.70.40; posting-account=S_MdrwoAAAD7T2pxG2e393dk6y0tc0Le NNTP-Posting-Host: 123.2.70.40 References: <4905b963-0036-4129-8050-fb26ef0154d6@googlegroups.com> <32314026-23ae-45b8-a4c5-e589e7d79de2@googlegroups.com> <3l3jf85ae05qgsl2l0avomebmg2ogl17rq@invalid.netcom.com> <13febf5c-4e3c-4275-8ff4-0a3a9e885d31@googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1,gzip(gfe) Message-ID: Subject: Re: Numerical calculations: Why not use fixed point types for everything? From: Robin Vowels Injection-Date: Sun, 20 Jan 2013 00:05:41 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-01-19T16:05:40-08:00 List-Id: On Jan 19, 3:41=A0pm, Dennis Lee Bieber wrote: > On Fri, 18 Jan 2013 10:59:43 -0800 (PST), Adam Beneschan > declaimed the following in comp.lang.ada: > > > On Friday, January 18, 2013 10:15:06 AM UTC-8, Dennis Lee Bieber wrote: > > > > =A0 =A0 =A0 Integer operations may be faster than floating point... B= ut fixed > > > point with a non-zero decimal place add in the overhead of having to > > > track where the point is and shifting results to match the declared d= ata > > > type. > > > > 25 * 25 =3D> 725 > > > > 2.5 * 2.5 =3D> 7.25 -- but if the data type is only one decimal place= this > > > now has to be rounded and shifted to become 7.3. > > > Perhaps. =A0But I tend to assume my computer is going to return correct= arithmetical results, which none of the above are. =A0:( > > =A0 =A0 =A0 =A0 Okay... I carried one extra for the leading digit... > > > In general, of course you're right that if your values aren't represent= ed with enough precision, or with a scale factor that will require rounding= , you're going to run into problems. =A0But of course that's a problem with= floating-point as well as with fixed-point. =A0If the range of values is s= mall enough, you can actually declare fixed-point types that have greater p= recision than the available floating-point types. =A0And how much precision= is necessary depends on the problem domain. =A0And there's no reason to as= sume that all values in your program have to have the same scale factor--in= fact, Ada's definition of fixed-point multiplication and division operatio= ns supports cases where an intermediate result may have more precision than= the operands, and rounding can wait until the final expression result is c= omputed. > > =A0 =A0 =A0 =A0 My emphasis was that, lacking true hardware fixed point o= perations, Virtually every computer has true hardware fixed-point operations. I refer to the set of integer instructions, which are, of course, fixed-point instructions. > the compiler has to track the position of the implied point and insert > operations to (for lack of better term) normalize the results back into > the declared type. Those the negative impact of those normalization > instructions may cancel out any expected gain from using integer > arithmetic operations. You are referring to multiplication and division. What you say doesn't usually apply to addition and subtraction, unless for some reason there is a change of scale factor. Adjusting the scale factor for multiplication doesn't usually involve much work. It's a shift operation. That operation is typically short compared to the time taken for multiplication.