Re: Fixed point constants issue

["Vinzent Hoefler" <nntp-2010-09@t-domaingrabbing.de>]

On Mon, 13 Sep 2010 22:32:05 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> wrote:

> On Mon, 13 Sep 2010 20:25:43 +0200, Vinzent Hoefler wrote:
>
>> Yes, of course. Still, it's not quite intuitive why
>>
>>   TEN_FEET_1 : constant          := HEIGHT * FEET_PER_METER;
>>   TEN_FEET_2 : constant Altitude := HEIGHT * FEET_PER_METER;
>>
>> just because a type is given in the second case.
>
> Different types, different behavior.

Well well. So this subtle difference between using a named number and a
typed constant (where the actual type *may* be a fixed point type) has
lead to quite not so subtle constraint errors.

>> I would expect the compiler to evaluate the expression "HEIGHT *
>> FEET_PER_METER" _before_ converting it to the appropriate fixed point  
>> type.
>
> Why? "*" is defined on Altitude. You should rather wonder why the result  
> is different for TEN_FEET_4.

I did wonder. :) I did a lot of different things trying to understand the
issue to my satisfaction. We now know how to get around it, but knowing a
workaround and actually understanding it are two different things.

> Multiplication is inexact taking rounding this or that way you get
> different results.

Yes, honestly I just wasn't really expecting that the compiler would
actually choose the multiplication operator of the fixed point type in
something that looks like a static expression.

>> And, obviously it does this that when evaluating
>>
>>    TEN_FEET_4 : constant Altitude := Altitude (HEIGHT * FEET_PER_METER);
>
> Well, it does not, because here another type is involved.

Yes. So, the expression HEIGHT * FEET_PER_METER in the one case is
evaluated by using the result type's multiplication operator and if the
conversion is present, it is not, giving the more precise result.

That's still a bit crazy, IMHO.

> But what about:
>
>    X : constant Altitude := 0.3048; -- The result is 0
>
> Does it wonder you?

No. That behavior is crystal-clear and expected.

It's having to add all those conversions just to make sure the values come
out as expected that's disturbing me a bit. It is something I wouldn't
expect from Ada.

As you can probably imagine, there are a lot more packages with appropriate
constants involved than in this shortened test case. And a lot of those
constants are used for fixed point values with totally different ranges
and deltas. So the actual problems do not show immediately.


Vinzent.

-- 
There is no signature.