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 Path: g2news2.google.com!postnews.google.com!f18g2000prf.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: conversions between fixed-point types Date: Wed, 23 Sep 2009 18:05:35 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1253754335 15805 127.0.0.1 (24 Sep 2009 01:05:35 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 24 Sep 2009 01:05:35 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f18g2000prf.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8445 Date: 2009-09-23T18:05:35-07:00 List-Id: On Sep 23, 3:28=A0pm, "Jeffrey R. Carter" wrote: > Dirk Herrmann wrote: > > > FpB'Image(FpB'(-1.5)) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0evaluates to -1.2 > > FpB'Image(FpB(FpA'(-1.5))) =A0 =A0 =A0 =A0 =A0 evaluates to -1.2 > > FpB'Image(MakeBFromA(FpA'(-1.5))) =A0 =A0evaluates to -1.6 > > There is no need to qualify these literals. In the second example, the qualification does make a difference, semantically; it's the difference between a type conversion from a fixed-point type to another fixed-point type, and a type conversion from a universal_real to a fixed-point type. It doesn't make a difference in this particular case only because -1.5 is a model number (machine number?) for an FpA. But there's a definite difference between FpB(0.7) and FpB(FpA'(0.7)), if truncation is used instead of rounding. > > Thus, even avoiding all floating point operations, the difference is > > still there. =A0It appears to be a question of whether the conversion f= rom > > FpA to FpB or the conversion from Float to FpB is computed statically o= r > > dynamically. > > I presume you mean Fpa rather than Float. > > Your last sentence may be what's happening. I don't know if that would be > allowed or a compiler error. Any language lawyers want to comment? The answer is curious (and I'm not sure if it's what the language designers intended). 4.9(38) says, "For a real static expression that is not part of a larger static expression ... the implementation shall round or truncate the value (according to the Machine_Rounds attribute of the expected type) to the nearest machine number of the expected type...". If FpB'Machine_Rounds is TRUE, this means that the result will be rounded, both for static expressions and when computed at runtime. (Also, if a number that is halfway between two machine numbers is rounded, the result is implementation-defined, but thanks to AI95-268 there is now Implementation Advice that the rounding of static expressions should be the same as it would be if computed at runtime.) If FpB'Machine_Rounds is FALSE, though, the situation is interesting. 4.9(38) requires that static expressions get *truncated* toward zero, as I read it. But there's no similar requirement for expressions computed at runtime. A.5.4(3) defines 'Machine_Rounds for a fixed- point type as "Yields the value True if rounding is performed on inexact results of every predefined operation that yields a result of the type T; yields the value False otherwise." It doesn't say that if it's FALSE, then inexact results are truncated toward zero; it just means that it might round or truncate. It could be that some predefined operations always round and others always truncate, or even that the same predefined operation on different operands may sometimes round upward and sometimes truncate (unlikely, but the language seems to allow it). Under this circumstance, it's possible that the type conversion could produce different results at runtime than for a static expression. So I guess whether this is a GNAT bug or not depends on FpB'Machine_Rounds. If it's TRUE, the first two expressions are computed incorrectly, but if it's FALSE, this seemingly anomalous result is allowed. Also, it's clear that static expressions need to round or truncate to a multiple of the 'Small if they're not part of a larger static expression. But I'm not sure what this should do: FpA'Image (FpA (FpB' (-1.5))) Here, FpB' (-1.5) *is* part of a larger static expression, so the rule in 4.9(38) doesn't apply. But I'm not sure just what does apply---is the value of FpB'(-1.5) still assumed to be -1.5 (so that the type conversion to FpA still results in -1.5), or should the type conversion take place (which could result in -1.0 if truncation is used for both type conversions), or is the result unspecified by the language? -- Adam