David Schultz wrote: > On Thu, Mar 06, 2008, Colin Percival wrote: >> explicit or implicit final destination. When a variable with a declared >> format >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> is a final destination, as in format conversion to a variable, that >> declared >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> format of that variable governs its rounding. The format of an implicit >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> destination, or of an explicit destination without a declared format, is >> defined by language standard expression evaluation rules. > > I think you missed the point about implicit destinations.
No. Another quote: 2.2.14 destination: The location for the result of an operation upon one or more operands. A destination might be either explicitly designated by the user or implicitly supplied by the system (for example, intermediate results in subexpressions or arguments for procedures). [...] Implicit destinations are things like the (x * y) in "x * y - 1.0" or in "sqrt(x * y)". > The register is an implicit destination. IEEE 754R explains this > in more detail. Really? I can't find any such statements... quite the contrary. > All that is guaranteed in this case is that the > wider register value is never substituted for z in subsequent > operations. (This is part of what gcc gets wrong.) If IEEE754R intended that "z = x + y" with x, y, and z all doubles did not guarantee reproducible results across compliant platforms, why does it say exactly the opposite? >> What standard states that those bounds are required (or can be relied upon >> when proving that code is correct)? [...] > > There's no standard requirements, but a max error < 0.50x ulps > implies correct rounding nearly all of the time, and that's what > libm attempts to provide. This is about the best you can do > without resorting to multiprecision arithmetic in the hard cases, > so it seems like a good tradeoff between accuracy and ease of > implementation. When substantially faster and slightly less > accurate MD implementations are available, that changes the > tradeoff. Sure. As I said before, more accurate transcendental functions are always nice to have, but they are not *required* by any standard. Correctly-rounded arithmetic operations *are* required. Colin Percival _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
