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-Thread: 103376,37e5589e32d8f03f X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news3.google.com!news.glorb.com!newsfeed.cw.net!cw.net!news-FFM2.ecrc.de!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.de!t-online.de!news.t-online.com!not-for-mail From: Matthias Kretschmer Newsgroups: comp.lang.ada Subject: Re: Floating-Point Numbers and Internal Representation Date: Sun, 4 Dec 2005 16:15:31 +0100 Organization: T-Online Message-ID: References: <1843142.NoXPLYbHQs@linux1.krischik.com> <4fnetd7d1gzw$.6esjklahq38$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.t-online.com 1133709331 01 19114 s7ayJgHvMudZSvuF 051204 15:15:31 X-Complaints-To: usenet-abuse@t-online.de X-ID: EKWuCMZfYeL7v9ly9H5kNxecS38moRFmQzoC44Tr-q8uwpbgtNpNoK User-Agent: slrn/0.9.8.1 (NetBSD) Xref: g2news1.google.com comp.lang.ada:6738 Date: 2005-12-04T16:15:31+01:00 List-Id: On 2005-12-04, Dmitry A. Kazakov wrote: > On Sun, 4 Dec 2005 14:11:49 +0000 (UTC), Martin Dowie wrote: > >> Martin Krischik wrote: >>> Independent of CPU/Language used I would allways suggest to use >>> >>> abs (X - Y) < epsilon >>> >>> with a sufficient but not to small epsilon instead. >> >> Suggested reading: >> >> http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm >> >> There is more than one answer to this problem... as I hope I said in my original posting, I am very well aware of this, but I had this special case where I wanted to use explicitly equality. There are times, when one is sure, that even with rounding errors, the two compared floating point numbers are really equal or not if one is using some good enough precision. So from some defined point on all following digits can be considered garbage, as it was in my case. The best solution would be that I had used Q (or a fixed subset of it) instead an approximation of R for my calculations, but I was too lazy :) Maybe I should take the time and port it to such a solution or implement something like that myself. At least in many circumstances using exact numbers instead of unexact ones causes much less trouble :) -- Matthias Kretschmer