CVS difference for ais/ai-00268.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00268.txt

--- ais/ai-00268.txt	2001/10/09 00:47:10	1.6
+++ ais/ai-00268.txt	2002/03/13 00:48:28	1.7
@@ -411,3 +411,125 @@
 for (2) dug up (1) :-)
 
 ****************************************************************
+
+From: Brian Wichmann
+Sent: Saturday, March  9, 2002  6:58 AM
+
+I am totally confused by this AI and also what the RM says!
+
+1. Independent of rounding, the RM is clearly wrong for some m/cs.
+
+Take a machine which only has double-length hardware and a round instruction.
+Single length is a type, but by 11.6, the compiler will use double-length
+operations and just does round on assignment. It would be crazy to truncate
+static expressions to single length on such a machine, but the RM seems
+to require that.
+
+2. IEEE is a red-herring. Clearly, the rounding should be appropriate to
+the target. This is not to the target type, as point 1 shows.
+
+3. The static expression model is just right. Hence Pascal's example is
+misleading since for a compiler to replace division by multiplication is
+hardly ever safe (obviously, replacing X/1.0 by X is fine; so some operator
+juggling is possible).
+
+4. Machine_Rounds is False does not imply truncation. The attribute might be
+false just because divide is implemented incorrectly - surely that should not
+mess up static expressions?
+
+5. Rounding is potentially dynamic. As Erhard has pointed out, full IEEE
+systems have the ability to dynamically control rounding. When using the
+facility, perhaps the user might like to recompile his program with an
+option to control the rounding - why not?
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, March 12, 2002  7:13 AM
+
+> 1. Independent of rounding, the RM is clearly wrong for some m/cs.
+>
+> Take a machine which only has double-length hardware and a round instruction.
+> Single length is a type, but by 11.6, the compiler will use double-length
+> operations and just does round on assignment. It would be crazy to truncate
+> static expressions to single length on such a machine, but the RM seems
+> to require that.
+
+I don't think there is a problem here.  This situation is similar to that of
+extended registers.  AARM A.5.3(11.d) makes it clear that we expect
+Machine_Rounds to return True in the presence of extended registers (assuming
+that the arithmetic is otherwise well-behaved) even though multiple rounding
+can sometimes yield results that are not properly rounded.
+
+> 2. IEEE is a red-herring. Clearly, the rounding should be appropriate to
+> the target. This is not to the target type, as point 1 shows.
+
+I think that IEEE is only mentioned as an example in the AI.  Surely it is an
+important case in practice.
+
+> 3. The static expression model is just right. Hence Pascal's example is
+> misleading since for a compiler to replace division by multiplication is
+> hardly ever safe (obviously, replacing X/1.0 by X is fine; so some operator
+> juggling is possible).
+
+Agreed, my comment was misguided.  The only divisions that can be safely
+converted to multiplications are those where the divisor is a power of 2.0.
+
+> 4. Machine_Rounds is False does not imply truncation. The attribute might be
+> false just because divide is implemented incorrectly - surely that should not
+> mess up static expressions?
+
+One possibility would be to say when Machine_Rounds is False, the static
+computation should emulate what the target arithmetic does. However, that looks
+like a slippery slope to me. First, it would significantly complicate those
+cross-compilers that target processors with exotic arithmetic, as emulating the
+target might be complex and error-prone.  Second, it would hamper portability,
+as the static rounding would vary from target to target.  I just don't think
+that the case where Machine_Rounds is False is important enough to warrant all
+this complexity.
+
+> 5. Rounding is potentially dynamic. As Erhard has pointed out, full IEEE
+> systems have the ability to dynamically control rounding. When using the
+> facility, perhaps the user might like to recompile his program with an
+> option to control the rounding - why not?
+
+This is beyond the scope of this AI. If we ever design a mapping to the full
+IEEE capabilities, maybe we'll want to have a configuration pragma to
+specifying the default rounding mode. In the meantime, people who use machine
+code insertions to change the rounding mode should be extra cautious with
+static expressions (and make them dynamic if they need to use the current
+rounding mode).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 12, 2002  2:05 PM
+
+> 1. Independent of rounding, the RM is clearly wrong for some m/cs.
+> Take a machine which only has double-length hardware and a round instruction.
+> Single length is a type, but by 11.6, the compiler will use double-length
+> operations and just does round on assignment. It would be crazy to truncate
+> static expressions to single length on such a machine, but the RM seems
+> to require that.
+
+This of course is the situation on the 8086 family (including the Pentiums).
+I agree that it is crazy that the RM requires rounding to single length
+(Janus/Ada 83 always created static expressions as double length, no matter
+what the type, for 8086 family machines). Why discard accuracy? However,
+this was discussed at the time Ada 95 was designed (I know I objected to
+this rule), and (as I recall) the answer was essentially that "the numeric
+guys want it this way". I certainly don't see any new information which
+would make it valuable to revisit that decision.
+
+On the other questions, I agree with Pascal.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 12, 2002  3:40 PM
+
+I disagree that the rounding of floats should be implementation dependent
+in this sense. I think it is perfectly reasonable to round appropriate
+to the type for static expressions.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent