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: 103376,388fc53f584bd695 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.mixmin.net!aioe.org!not-for-mail From: =?UTF-8?B?TWFya3VzIFNjaMO2cGZsaW4=?= Newsgroups: comp.lang.ada Subject: Re: Fixed point constants issue Date: Mon, 27 Sep 2010 12:33:49 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1f0l0baynq1x7$.phl9cqpwcr37.dlg@40tude.net> <8f7b0nF6hfU1@mid.individual.net> NNTP-Posting-Host: hzAn46cwLozSmDBblnAvDQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 Xref: g2news1.google.com comp.lang.ada:14278 Date: 2010-09-27T12:33:49+02:00 List-Id: Am 25.09.2010 02:16, schrieb Jeffrey Carter: > On 09/24/2010 03:42 PM, Vinzent Hoefler wrote: >> >> 3.5.9 says: >> >> Multiplication and division of fixed point values deliver results of a >> fixed point type with >> an arbitrarily fine accuracy [...] which is referred to [...] as >> /universal_fixed/. > > Yes. But these are not fixed-point values. One is universal_integer and the > other is universal_real. The question is whether "*" is the one defined for > universal_real or for the fixed-point type. In the latter case, the > universal_real value would be converted to the fixed-point type before > calling "*". > > ARM83 4.10 says that static, universal expressions are evaluated exactly. > The question seems to be whether the expression is universal. ARM83 4.4 > seems to be the place to look for that, but I'm not sure which it requires. We have three different overloads for "*" to consider. One is universal_integer * universal_real -> universal_real [4.10] The next is INTEGER * ALTITUDE -> ALTITUDE [4.5.5] The third is ALTITUDE * ALTITUDE -> ALTITUDE [4.5.5] I think the key to the answer is in ARM83 4.6: "Apart from the explicit type conversions, the only allowed form of type conversion is the implicit conversion of a value of the type universal_integer or universal_real into another numeric type. An implicit conversion of an operand of type universal_integer to another integer type, or of an operand of type universal_real to another real type, can only be applied if the operand is either a numeric literal, a named number, or an attribute; such an operand is called a convertible universal operand in this section. An implicit conversion of a convertible universal operand is applied if and only if the innermost complete context (see 8.7) determines a unique (numeric) target type for the implicit conversion, and there is no legal interpretation of this context without this conversion." There is no conversion from universal_integer to ALTITUDE, therefore the third overload cannot be chosen. The implicit conversion from universal_real to ALTITUDE is only done when the operand is either a numeric literal, a named number, or an attribute. This rules out the first overload. Therefore we have only the second overload left which is chosen because of an implicit conversion from universal_integer to INTEGER and from universal_real to ALTITUDE. And the different results we're seeing are due to [3.5.6] which, if I understand the text correctly, allows the result of the conversion from FEET_PER_METER to be either 0 or 0.5. Can someone confirm this reasoning? Markus