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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,5412c98a3943e746
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.129.169 with SMTP id nx9mr2691976pbb.2.1331733109461;
        Wed, 14 Mar 2012 06:51:49 -0700 (PDT)
Path: 
 h9ni25321pbe.0!nntp.google.com!news1.google.com!goblin3!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: REAL
Date: Wed, 14 Mar 2012 14:51:59 +0100
Organization: cbb software GmbH
Message-ID: <1u0x151ebygpz$.1f4x12uo70ifu$.dlg@40tude.net>
References: <op.v91cleyiule2fv@douda-yannick> <jj3p5v$2tp$1@munin.nbi.dk>
 <9207716.776.1331054644462.JavaMail.geo-discussion-forums@ynaz38>
 <nhzeozam35it$.13mzx8ap4cmdc$.dlg@40tude.net>
 <op.wascesqrule2fv@douda-yannick>
 <4edda5mav3cf$.149pbgyxl1wx5.dlg@40tude.net>
 <9rplcgF5a2U1@mid.individual.net>
 <1psd0g0womgxi.1sle7ol12x3d5.dlg@40tude.net>
 <9rsahhFmr3U1@mid.individual.net> <ezfn0og1qfov.14k34sxoky5ke.dlg@40tude.net>
 <9rvdjvFfa8U1@mid.individual.net> <4pp58h1br5sp$.yylr20e5vzxb.dlg@40tude.net>
 <9s1s7tF6pcU1@mid.individual.net>
 <1oln2mjlozzh5$.1mxrd97lrgndo.dlg@40tude.net>
 <9s4mseFuoaU1@mid.individual.net> <v18znvc2u2sk.aqnplls3016g.dlg@40tude.net>
 <9sb3l3Fs4oU1@mid.individual.net>
 <4f6063b7$0$6642$9b4e6d93@newsspool2.arcor-online.net>
 <Pine.LNX.4.64.1203141202570.28027@medsec1.medien.uni-weimar.de>
 <ou81y5gru8zh$.1xdmyyyolu0u3$.dlg@40tude.net>
 <4f609d6a$0$6628$9b4e6d93@newsspool2.arcor-online.net>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: 2012-03-14T14:51:59+01:00
List-Id: <comp.lang.ada>

On Wed, 14 Mar 2012 14:30:17 +0100, Georg Bauhaus wrote:

> So it is better to keep the current
> types and effects and acquire the asset. Turns hazards into
> sources of achievement.

When you compute anything using conventional floating point arithmetic, the
result of this computation is within the bounds of the equivalent interval
computation, provided, CPU has no bugs in its ALU. This is a mathematical
fact.

Interval arithmetic does not compute anything differently. It just keeps
track of the error bounds.

The disadvantages comparing to normal arithmetic is that you need twice as
much memory (if the implementation is straightforward). This was an issue
when intervals were actively studied (60s-70s). No any problem now.

Comparing to analytical methods of error estimation. Intervals give a
pessimistic one. A manual analysis based on additional knowledge
(especially if variables are dependant) may sufficiently improve the
estimation. It is worth to remember that floating point arithmetic does no
any error estimation, whatsoever. In fact it is guaranteed to be
inaccurate, which is the asset, you wrote about.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de