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 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-7-bit X-Received: by 10.66.80.41 with SMTP id o9mr1393777pax.4.1358536175400; Fri, 18 Jan 2013 11:09:35 -0800 (PST) X-Received: by 10.50.13.130 with SMTP id h2mr1063081igc.16.1358536175169; Fri, 18 Jan 2013 11:09:35 -0800 (PST) Path: s9ni24pbb.0!nntp.google.com!ld4no9175117pbb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 18 Jan 2013 11:09:34 -0800 (PST) In-Reply-To: <32314026-23ae-45b8-a4c5-e589e7d79de2@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <4905b963-0036-4129-8050-fb26ef0154d6@googlegroups.com> <32314026-23ae-45b8-a4c5-e589e7d79de2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7aeff757-a038-45e0-93d6-bd1d6e02093e@googlegroups.com> Subject: Re: Numerical calculations: Why not use fixed point types for everything? From: Adam Beneschan Injection-Date: Fri, 18 Jan 2013 19:09:35 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-01-18T11:09:34-08:00 List-Id: On Friday, January 18, 2013 1:17:37 AM UTC-8, Ada novice wrote: > On Thursday, January 17, 2013 5:25:30 PM UTC+1, Adam Beneschan wrote: >=20 >=20 >=20 > > (2) Many processors have built-in support for mathematical functions on= floating-point values (square root, trig functions, log, e**x). If your p= rogram does lots of those, you'll probably want to use floating-point numbe= rs instead of calling library functions to do the computation (slow) or con= stantly converting back and forth between fixed- and floating-point. >=20 > >=20 >=20 > >=20 >=20 > > -- Adam >=20 >=20 >=20 > Thanks to all of you for your inputs. So if I am just writing a program t= hat won't be run on a separate DSP platform but only on my computer, then I= can go for fixed-point representation as long as I am not working with exc= essively large or excessively small values. >=20 >=20 >=20 > I have read (John Mc Cormick: Building parallel...with Ada's book) that f= ixed point arithmetic is faster than floating-point arithmetic since intege= r instructions are faster so I would ask about the second point put by Adam= that mathematical functions are slow with fixed-point numbers. Can you ple= ase elaborate on that? What I mean is that some processors (including the Pentium) have instructio= ns to perform mathematical operations like trig functions, square-root, etc= ., on floating-point numbers, and special hardware to do the computation. = If you were to figure out just what mathematical operations the hardware is= doing to compute the result, you could write code to perform the same oper= ations with fixed-point numbers. But since the processor would have to go = through the instructions and execute them, this takes longer. (In real lif= e, you wouldn't write algorithm to perform these functions on fixed-point n= umbers; you'd just convert a fixed-point number to a floating-point number = and let the hardware do its work. But doing these conversions takes a litt= le extra time. You'd have to determine whether the extra time is made up b= y the time saved by doing the simpler calculations in fixed-point, and that= depends on the application.) On a machine that doesn't have hardware to do these computations, code to d= o the computations on fixed-point numbers might be faster than the equivale= nt code to do it on floating-point numbers, assuming the scale factors of t= he fixed-point numbers are known ahead of time. But even then, this might = not be correct. I agree with J-P that you really can't tell which one will= be faster, on any particular hardware configuration, until you try it out = and measure it. -- Adam