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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d09fa6592c24a21 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-10 21:33:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hub1.nntpserver.com!news-xfer.siscom.net!not-for-mail Message-ID: <3C8C41A8.B5D96800@yahoo.com> Date: Sun, 10 Mar 2002 23:33:28 -0600 From: Anatoly Chernyshev X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: ru,en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: I think - it's a bug... References: <3C8B184D.49214059@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: 206.250.225.5 X-Original-Trace: 10 Mar 2002 22:33:53 -0700, 206.250.225.5 X-COMPLAINTS: Report abuse to abuse@mhogaming.com Organization: Newshosting.com - Highest quality at a great price! www.newshosting.com NNTP-Posting-Date: 11 Mar 2002 05:33:27 GMT NNTP-Posting-Host: 8bc13bf2.news.newshosting.com X-Trace: DXC=>[9FEkh^k1LciF6BbIV4YYbLnHEXCOOR@o]UdHH:F16igM;lF[5C2Pfho5dZhTdOGRmoh3?Aa9Y?3b X-Complaints-To: abuse@newshosting.com Xref: archiver1.google.com comp.lang.ada:21035 Date: 2002-03-11T05:33:27+00:00 List-Id: "David C. Hoos, Sr." wrote: > This is not a bug. The problem comes about by not being aware of > the nature of floating point representation in computers. > > In your example, the value of dz (0.3) is not exactly representable in > binary -- it is an infinitely repeating binary fraction. Hence, all values of > z that you compute are not exactly representable. > > Thus, if the value of dz was rounded upward to the next lsb when > converting from decimal to binary, all values of z will be slightly > larger than their true value. > That's true, but still, why inserting of "put_line (float'image(1.0-(z/b)));" influences the behaviour of the program so much. Beyound that, I've got similar things with z=0.1 and 0.25. They were solved though, by using different optomization levels (-O, -O2...). > > The only solution is to test the values of which you are about to take > the square root, and if the absolute value is less than some very small > threshold, set the value to 0.0. > > Alternatively, if you are sure (given the nature of the problem you > are solving) that z can never be greater than b, you could replace > (z/b) by Float'Min (1.0, z/b). > > Additionally, you might want to consider the following statement > from the GNAT User's Guide: > In particular, if the Ada code will do any floating-point operations, > then the FPU must be setup in an appropriate manner. For the case > of the x86, for example, full precision mode is required. The > procedure GNAT.Float_Control.Reset may be used to ensure that > the FPU is in the right state. > Finally you can obtain greater precision by using Long_Float or Long_Long_Float > instead of Float. Thanks a lot for those suggestions (but you are omitted what is coming from the GNAT UG). >