comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: How to round to the nearest fixed-point value?
Date: Fri, 24 Jan 2014 16:30:36 -0600
Date: 2014-01-24T16:30:36-06:00	[thread overview]
Message-ID: <lbupic$4pd$1@loke.gir.dk> (raw)
In-Reply-To: slrnle4e9r.1lme.lithiumcat@sigil.instinctive.eu

"Natasha Kerensikova" <lithiumcat@gmail.com> wrote in message 
news:slrnle4e9r.1lme.lithiumcat@sigil.instinctive.eu...
> Hello,
>
> On 2014-01-22, Natasha Kerensikova <lithiumcat@gmail.com> wrote:
>>    function Convert (Value : High) return Low is
>>    begin
>>       return Low'Round (Value);
>>    end Convert;
>
> In case anyone is interested, the following rewrite works around the
> problem:
>
>   function Convert (Value : High) return Low is
>   begin
>      return Low'Round (Value * 1.0);
>   end Convert;

I believe the above should be illegal - but in any case, it's not clear from 
the RM what this means.

The only multiply operations available for fixed point types either have one 
operand that is an integer (not the case above), or produce a 
Universal_Fixed result. 4.5.5(19.1/2) requires that the result be used in a 
context where the result type is identified, and specifically disallows the 
result from being Universal_Fixed.

The type of the operand of 'Round is Universal_Real. This appears to meet 
the letter of the rule, but not the intent (which is that the expected type 
determine the scaling and respresentation for the result).

> I would have thought that the optimizer would have quickly brought both
> version to the same generated code, but from -O0 to -O3 I get the
> correct rounding with the latter but not with the former.

No, the result of the operand here is Universal_Real. I believe the language 
says that runtime universal values are evaluated using the largest possible 
numeric type; in this case, that would be a large float type. It's very 
difficult to optimize out float operations (because of precision issues - 
you have to be very careful that the precision of the result is the same 
after optimization), so it probably can't be changed. So you're getting 
vastly different code.

> I guess that's enough to conclude there is a compiler bug somewhere (or
> a weird bug in the language). I'll have to send that to AdaCore...

I think there might be a bug in the language here (that is, for your 
rewrite, not for your original code), but I'll ask the ARG.

                           Randy.


  reply	other threads:[~2014-01-24 22:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22 16:48 How to round to the nearest fixed-point value? Natasha Kerensikova
2014-01-22 17:53 ` G.B.
2014-01-22 22:26   ` adambeneschan
2014-01-23  9:21     ` Georg Bauhaus
2014-01-22 22:45 ` adambeneschan
2014-01-23  5:29   ` J-P. Rosen
2014-01-23  7:00     ` Natasha Kerensikova
2014-01-23  9:42     ` Georg Bauhaus
2014-01-23  7:02   ` Natasha Kerensikova
2014-01-23 16:41     ` adambeneschan
2014-01-24  9:58 ` Natasha Kerensikova
2014-01-24 22:30   ` Randy Brukardt [this message]
2014-01-24 22:47     ` Randy Brukardt
2014-01-26 14:19     ` Natasha Kerensikova
2014-01-28 23:43       ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox