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.180.83.2 with SMTP id m2mr1369211wiy.0.1359116193382;
        Fri, 25 Jan 2013 04:16:33 -0800 (PST)
Path: 
 o9ni19030wio.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Paul Colin Gloster <Colin_Paul_Gloster@ACM.org>
Newsgroups: comp.lang.ada
Subject: Re: Numerical calculations: Why not use fixed point types for
 everything?
Date: Fri, 25 Jan 2013 12:16:33 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <kdtt31$83d$2@dont-email.me>
References: <db7b4d36-6c49-4501-954e-68ecc55c3d32@googlegroups.com>
 <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>
 <sf8kf8pmgjd69d20pfm3qtahmd2t6nkfrv@invalid.netcom.com>
 <kddeai$f9i$1@dont-email.me> <wccmww5i7k4.fsf@shell01.TheWorld.com>
Mime-Version: 1.0
Injection-Date: Fri, 25 Jan 2013 12:16:33 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
 posting-host="2da593c5dc84c37dabca6edf3693dfa1";
	logging-data="8301"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19fKoegH4/iV1d9M4jvWN9Av6Jmz0iloB5MNuYj5h6xMQ=="
User-Agent: slrn/0.9.9p1 (Linux)
Cancel-Lock: sha1:KK4wGoXaeZ0aWjfIGDlEV8XRUZw=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: 2013-01-25T12:16:33+00:00
List-Id: <comp.lang.ada>

On 2013-01-19, Robert A Duff <bobduff@shell01.TheWorld.com> sent:
|--------------------------------------------------------------|
|"Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:  |
|                                                              |
|> I decided to run a test. My results:                        |
|                                                              |
|Thanks -- it's good to have actual numbers.                   |
|                                                              |
|But the choice between floating- and fixed-point should not   |
|be made primarily on the basis of speed.  It should be based  |
|on the needs of the problem, such as whether you want relative|
|or absolute errors.                                           |
|                                                              |
|Unless you're running on a machine with no hardware support   |
|for floating point.                                           |
|                                                              |
|- Bob"                                                        |
|--------------------------------------------------------------|

We "should" not need these different datatypes. Everything "should"
just be perfect. Therefore there "should" be neither relative nor
absoulte errors.

Unfortunately we live in the real World, so how long we need to wait
for some inaccurate estimations instead of many inaccurate estimations
is often an important factor. For example, from
HTTP://Permalink.Gmane.org/gmane.comp.lib.gmp.general/4212
:
########################################################################
#"[. . .]                                                              #
#                                                                      #
#I am seeing a piece of code that takes about two minutes to execute in#
#double precision taking about two                                     #
#_hours_ in 30-digit precision. Does that sound about right? FWIW, I am#
#using MPFR through the Ada binding.                                   #
#                                                                      #
#[. . .]"                                                              #
########################################################################