Re: conversions between fixed-point types

[Adam Beneschan <adam@irvine.com>]

On Sep 23, 3:28 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Dirk Herrmann wrote:
>
> > FpB'Image(FpB'(-1.5))                evaluates to -1.2
> > FpB'Image(FpB(FpA'(-1.5)))           evaluates to -1.2
> > FpB'Image(MakeBFromA(FpA'(-1.5)))    evaluates to -1.6
>
> There is no need to qualify these literals.

In the second example, the qualification does make a difference,
semantically; it's the difference between a type conversion from a
fixed-point type to another fixed-point type, and a type conversion
from a universal_real to a fixed-point type.  It doesn't make a
difference in this particular case only because -1.5 is a model number
(machine number?) for an FpA.  But there's a definite difference
between FpB(0.7) and
FpB(FpA'(0.7)), if truncation is used instead of rounding.


> > Thus, even avoiding all floating point operations, the difference is
> > still there.  It appears to be a question of whether the conversion from
> > FpA to FpB or the conversion from Float to FpB is computed statically or
> > dynamically.
>
> I presume you mean Fpa rather than Float.
>
> Your last sentence may be what's happening. I don't know if that would be
> allowed or a compiler error. Any language lawyers want to comment?

The answer is curious (and I'm not sure if it's what the language
designers intended).  4.9(38) says, "For a real static expression that
is not part of a larger static expression ... the implementation shall
round or truncate the value (according to the Machine_Rounds attribute
of the expected type) to the nearest machine number of the expected
type...".  If FpB'Machine_Rounds is TRUE, this means that the result
will be rounded, both for static expressions and when computed at
runtime.  (Also, if a number that is halfway between two machine
numbers is rounded, the result is implementation-defined, but thanks
to AI95-268 there is now Implementation Advice that the rounding of
static expressions should be the same as it would be if computed at
runtime.)

If FpB'Machine_Rounds is FALSE, though, the situation is interesting.
4.9(38) requires that static expressions get *truncated* toward zero,
as I read it.  But there's no similar requirement for expressions
computed at runtime.  A.5.4(3) defines 'Machine_Rounds for a fixed-
point type as "Yields the value True if rounding is performed on
inexact results of every predefined operation that yields a result of
the type T; yields the value False otherwise."  It doesn't say that if
it's FALSE, then inexact results are truncated toward zero; it just
means that it might round or truncate.  It could be that some
predefined operations always round and others always truncate, or even
that the same predefined operation on different operands may sometimes
round upward and sometimes truncate (unlikely, but the language seems
to allow it).  Under this circumstance, it's possible that the type
conversion could produce different results at runtime than for a
static expression.

So I guess whether this is a GNAT bug or not depends on
FpB'Machine_Rounds.  If it's TRUE, the first two expressions are
computed incorrectly, but if it's FALSE, this seemingly anomalous
result is allowed.

Also, it's clear that static expressions need to round or truncate to
a multiple of the 'Small if they're not part of a larger static
expression.  But I'm not sure what this should do:

   FpA'Image (FpA (FpB' (-1.5)))

Here, FpB' (-1.5) *is* part of a larger static expression, so the rule
in 4.9(38) doesn't apply.  But I'm not sure just what does apply---is
the value of FpB'(-1.5) still assumed to be -1.5 (so that the type
conversion to FpA still results in -1.5), or should the type
conversion take place (which could result in -1.0 if truncation is
used for both type conversions), or is the result unspecified by the
language?

                                    -- Adam