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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,6fabd104d18f3943 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.albasani.net!not-for-mail From: Dirk Herrmann Newsgroups: comp.lang.ada Subject: Re: conversions between fixed-point types Date: Sun, 20 Sep 2009 21:13:40 +0200 Organization: albasani.net Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net Wx/I9x++BGY2dQahq/N+cHYxj5IUcsl6zhsRSLi0U+rJ1A14xTXsA+j91qceNVlGAMvRPvhGj9lvkgT6J3X+cnEg3gtmW+WidRpZcUb40Z69Eez4w/nWf/XJqGCJu9a2 X-Complaints-To: abuse@albasani.net NNTP-Posting-Date: Sun, 20 Sep 2009 19:13:45 +0000 (UTC) X-User-ID: SwIK0Wboi6BwvSFNYqvMuy/neJiTyQoTITT8hJi7GZdP8kjiJkvV3wd9gQYMPERx8+9ADQ0JevX1mvFxIbQtpQ== In-Reply-To: Cancel-Lock: sha1:xgsfq1HqfYa+/OmetGxxtVW79H0= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) X-NNTP-Posting-Host: bvangEZ93z+TY21XG6A4ePbf/kmmxqlo2dMLkRBvuQ8= Xref: g2news2.google.com comp.lang.ada:8408 Date: 2009-09-20T21:13:40+02:00 List-Id: John B. Matthews wrote: > I see what you mean. Here's my understanding: The Ada Reference Manual > [1], section 3.6(32) on numeric type conversion refers to section G.2.1 > and G.2.3 for floating- and fixed-point arithmetic, respectively. The > value -1.5 is exactly representable as type Float, but not as type FpB. > The conversion to FpB is governed by G.2.3(10), so both -1.2 and -1.6 > are in the close result set. Because FpB is an ordinary fixed point > type, rather than a decimal fixed point type, there's no requirement to > prefer one element of the result set over another. Thanks for your detailed analysis. It confirms what I had suspected. The bad thing seems to be that there is no easy approach to achieve a more specific behaviour. > The conversion back > to Float is discussed in G.2.1(10). Because small is not a power of > T'Machine_Radix, the result is implementation defined. I'm not sure if > GNAT fully implements Annex G, and I may be overlooking something > obvious. I see. Probably the conversion back to float itself was not the problem, though. > From another perspective, I'm curious to know why the conversions are > needed. As I said, in my company we are using lots of fixed-point arithmetics. Most of it is in powers of 2, but even then you have to care about rounding when converting between different fixed-point representations. However, some data is represented with different resolutions. For example, when you have some code that is executed cyclically every 100ms and delivers sensor sample values. Then, a gradient of two sensor samples is (value2-value1)/dt. Since dt is known to be 100ms, you can save a division operation if you choose a small of 100ms for dt. At some point during the calculation, however, you will have to make the conversion from the world of types with "physical" representations (like, small of 100ms), to the world of binary representations. This is the moment when conversions between smalls of 0.5 and 0.4 can be interesting. Best regards, Dirk