Re: Fixed point constants issue

["Markus Schöpflin" <no@spam.spam>]

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