Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 06 Mar 2008 18:51:58 -0800
From:      Colin Percival <cperciva@freebsd.org>
To:        Colin Percival <cperciva@FreeBSD.ORG>, Bruce Evans <bde@FreeBSD.ORG>, src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/i386/include _types.h
Message-ID:  <47D0ADCE.2070405@freebsd.org>
In-Reply-To: <20080307022416.GA53988@zim.MIT.EDU>
References:  <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305182531.GS68971@server.vk2pj.dyndns.org> <20080306021222.GA46783@zim.MIT.EDU> <47CF5D19.3090100@freebsd.org> <20080306033246.GA47280@zim.MIT.EDU> <47CF7EBF.6000009@freebsd.org> <20080306063452.GB48339@zim.MIT.EDU> <47CF9586.70707@freebsd.org> <20080307085031.P10724@delplex.bde.org> <47D089A4.4060208@freebsd.org> <20080307022416.GA53988@zim.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47D0ADCE.2070405>