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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c83229a21d53b2b3 X-Google-Attributes: gid103376,public From: Al Christians Subject: Re: Long Float Error from Gnat Date: 1998/10/31 Message-ID: <363B6EBF.C67DA0DC@easystreet.com>#1/1 X-Deja-AN: 407072083 Content-Transfer-Encoding: 7bit References: <3638F49C.E90A401E@easystreet.com> <363A49F3.DB0A0196@easystreet.com> <71fob8$r2e$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii X-Trace: news14.ispnews.com 909864047 206.103.58.48 (Sat, 31 Oct 1998 15:00:47 EDT) Organization: Trillium Resources Corporation MIME-Version: 1.0 NNTP-Posting-Date: Sat, 31 Oct 1998 15:00:47 EDT Newsgroups: comp.lang.ada Date: 1998-10-31T00:00:00+00:00 List-Id: dewar@gnat.com wrote: > > Remember that CLA may be an interesting place to discuss possible GNAT bugs > but it is not the place to report them. If you think you have found a GNAT > bug, always report it to report@gnat.com, if you want the ACT team to look > at it, Thanks. > Ok. I posted it here first, because I wasn't sure of the source of the anomaly (I've only run it on Pentium Pro's I know have the FP bug), and I figured I would get a richer set of responses than the person who posted something that looked about the same to GNAT chat about a month ago and got no responses that I could find in the archive. Before the other postings came back confirming it on other hardware, I also received by email a copy of what was evidently a bug report to ACT submitted by someone else for this same problem. It's got a bug number, ACT #273, attached, so I trust that I don't have to follow up directly by bug report on it now. Is that correct? BTW, the numbers that triggered the fault, approximately 1E-32 gave me some reason to question what was going on in my application. All my data is within a few orders of magnitude of unity, and I couldn't figure out any scenario by which anything I was dealing with in the program could possible come out non-zero but less than 1E-8. The roundoff error for Long_Float should not come out of a magnitude much less than 1E-16, since they are only good to about that many places. What was happening was that when a number was a summation of almost equal roundoff errors of different signs, the errors (of order 1E-16) would just about cancel, leaving a residual of order 1E-32. The program was not wrong, as the interpretation of the answers in no way distinguishes 1E-32 from zero, but it's curious that an artifact of an artifact (or a phantom of a ghost for Halloween) produced the data that exposed this bug. Al