Re: Fixed point constants issue

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 13 Sep 2010 23:08:08 +0200, Vinzent Hoefler wrote:

> 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.

Yes, because multiplication you have in mind is not the one effectively
implemented for fixed point types. Fixed-point operations are exact, but
inaccurate in terms of real numbers. You seem to expect them inexact, but
accurate.

>> 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.

If there were a way to disallow predefined multiplication, but there is no
one, AFAIK.

And you have this same problem with all other operations. Consider 0.4+0.4
is it 0 or 0.65536?

> 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.

No, fixed point multiplication was intentionally defined that way.

> 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.

Well, I don't disagree, but the part of the problem is a non-intended use.
It is difficult to say how the compiler could detect that.

In your use case, the only solution I see were literals made intervals
rather than universal numbers. That would statically detect that HEIGHT *
FEET_PER_METER has the width greater than Small and warn about implicit
conversion to Altitude possibly raising Precision_Loss_Error.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de