From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.8 required=3.0 tests=BAYES_50,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:ac8:4e81:: with SMTP id 1mr55441454qtp.364.1594097530525; Mon, 06 Jul 2020 21:52:10 -0700 (PDT) X-Received: by 2002:a4a:49cd:: with SMTP id z196mr43138404ooa.58.1594097530242; Mon, 06 Jul 2020 21:52:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 6 Jul 2020 21:52:09 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=93.41.2.250; posting-account=9fwclgkAAAD6oQ5usUYhee1l39geVY99 NNTP-Posting-Host: 93.41.2.250 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <612a5956-c885-4240-9341-09dbfd49f44eo@googlegroups.com> Subject: Re: Question about best practices with numerical functions From: mockturtle Injection-Date: Tue, 07 Jul 2020 04:52:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59373 List-Id: Also in my case the loss of precision is not due to approximation introduce= d by operations, but to a loss of convergence because (maybe) for that inp= ut value the convergence is too slow and the bound on the number of iterati= ons is not large enough. On Tuesday, July 7, 2020 at 12:23:09 AM UTC+2, Dmitry A. Kazakov wrote: > On 06/07/2020 19:02, Shark8 wrote: >=20 > > One way to do this would be to use fixed-point types: > > (1) Convert your input to the fixed-point that has a "good enough" delt= a for the precision you want. > > (2) Run the algorithm. > > (3) Convert back to your normal value-type. > > This assumes you're using floating-point or integers, but one nice thin= g about fixed-point is that it has a bounded error when dealing with operat= ions, unlike floating-point. -- I remember some years ago seeing a bug repo= rt dealing with floating-point, where the particular error simply couldn't = have happened with fixed-point. >=20 > Rounding error is bounded in both cases. Fixed-point has same error=20 > regardless the values involved in the operations. Floating-point has=20 > error depending on the values. >=20 > I would say that floating-point error would be roughly same for=20 > addition, subtraction and multiplication, provided fixed-point does not= =20 > overflow. It will be hugely better for division. >=20 > Using fixed-point arithmetic has only sense for a few marginal cases of= =20 > rounding. >=20 > Furthermore converting many algorithms to fixed-point might turn quite=20 > non-trivial as you will have to ensure absence of overflows and=20 > underflows. Where floating-point computation just would lose some=20 > precision, fixed-point will catastrophically fail. >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de